Agent-readiness round 2 — disclosure stubs for OAuth, OIDC, OAuth-PR, MCP

Why this exists

Earlier today we shipped the conservative slice of agent readiness (Content-Signal, agent-skills index, markdown twins, Link header) and explicitly deferred OAuth/OIDC/MCP discovery on the basis that Bailey has no backing service. The isitagentready.com audit re-flagged those four sections as failing, and Ryan asked: “can you disclose that we don’t have these items, create the file that matches the standard and say we don’t have them?”

The compromise this entry implements: publish minimal-valid metadata at every spec-mandated path, with empty *_supported arrays so a spec-compliant client cannot initiate any flow, and explicit $comment / description fields disclosing absence. This trades a bit of “spec purity” (the documents technically claim Bailey IS an issuer / resource / server) for explicit disclosure that’s better than a 404 ambiguity.

Each stub also points at a single human-readable status doc — /.well-known/agent-services-status.md — that explains the full posture in one place.

What was done

Files created (public/.well-known/)

Path	Spec	Disclosure approach
oauth-authorization-server	RFC 8414	issuer set, response_types_supported: [], grant_types_supported: [], service_documentation URL, $comment
openid-configuration	OIDC Core 1.0 §3	issuer set, required URL endpoints (authorization_endpoint, token_endpoint, jwks_uri) point at the status .md, all *_supported arrays empty, service_documentation URL, $comment
oauth-protected-resource	RFC 9728	resource set, authorization_servers: [], bearer_methods_supported: [], scopes_supported: [], resource_documentation URL, $comment
mcp/server-card.json	SEP-1649 / PR-2127 (in-flight)	name: "bailey-engineering-no-mcp-server", serverInfo.name: "no-mcp-server", capabilities: {}, description field discloses absence and notes spec-instability caveat
agent-services-status.md	(Bailey-defined)	Human-readable one-page summary of what’s available, what’s stubbed, and why. Linked from all four stubs and from the agent-skills index.

Files updated

• public/.well-known/agent-skills/index.json — added top-level service_documentation field pointing at the status doc, so an agent that finds the index via the Link: rel="service-desc" header can discover the broader status.
• public/.well-known/agent-skills/schema.json — allowlists the new service_documentation property.

Nginx config

One new regex location block (parallel to the .md block we shipped earlier today):

location ~ ^/\.well-known/(oauth-authorization-server|openid-configuration|oauth-protected-resource)$ {
    default_type application/json;
    charset_types application/json;
    charset utf-8;
}

Required because OAuth 2.0 AS Metadata, OIDC Discovery, and OAuth Protected Resource Metadata specs mandate paths with no file extension — without this block, nginx serves them as application/octet-stream. The mcp/server-card.json ends in .json and is already handled by the inherited mime.types map.

Applied via the safe-edit pattern. Backup at /etc/nginx/sites-available/baileyengineers.com.bak-20260505-234156. nginx -t clean, systemctl reload nginx clean.

Deploy

scp -r dist/.well-known root@.../var/www/baileyengineers.com/ (explicit directory SCP, since the dotfile gotcha I documented in reference_production_hosting.md is still an open issue with dist/* glob expansion). chown/chmod sweep, nginx -t clean.

Smoke tests — all green via https://baileyengineers.com/

Path	Status	Content-Type	Notes
/.well-known/oauth-authorization-server	200	application/json; charset=utf-8	JSON parses; issuer = https://baileyengineers.com; empty supported arrays
/.well-known/openid-configuration	200	application/json; charset=utf-8	JSON parses; issuer correct; required endpoints point at status .md
/.well-known/oauth-protected-resource	200	application/json; charset=utf-8	JSON parses; resource = https://baileyengineers.com; empty authorization_servers
/.well-known/mcp/server-card.json	200	application/json	JSON parses; serverInfo.name = no-mcp-server; capabilities = {}
/.well-known/agent-services-status.md	200	text/markdown; charset=utf-8	Served by the existing .md location block
/.well-known/agent-skills/index.json	200	application/json	service_documentation field present; still 4 skills

Honest caveats

1. Spec interpretation is debatable. Publishing minimal-valid metadata for a non-existent service is a gray area. A strict reader could argue this falsely claims existence; a pragmatic reader could argue empty *_supported arrays + $comment make absence unambiguous. We took the pragmatic path.
2. Audit depth unknown. isitagentready.com’s validation depth isn’t published. Surface checks (200 + JSON parse) will pass. Deep schema validation will pass for OIDC/OAuth (all required fields present). Semantic validation that endpoints actually serve auth flows will fail — but no honest implementation can pass that bar without real services.
3. MCP spec is in-flight. SEP-1649 / PR-2127 isn’t merged. The card’s structure may need updating when the format finalizes.
4. OIDC’s required endpoints point at the status .md. A spec-compliant client will see the empty response_types_supported and never call those URLs. A misbehaving client gets markdown back instead of a JSON error.

What was deliberately NOT stubbed

• WebMCP. No file format — it’s a JavaScript API (navigator.modelContext.provideContext()). Implementing it means client-side JS, which violates the project’s no-JS posture (per CLAUDE.md). Documented in agent-services-status.md instead.
• Markdown content negotiation (Accept: text/markdown → markdown response). Still pending Ryan’s Cloudflare-dashboard check — Cloudflare may have an edge-side toggle that handles this without origin changes. If not, a follow-up nginx diff with map $http_accept + URI-to-twin mapping is teed up.

Files affected

Created:

• public/.well-known/oauth-authorization-server
• public/.well-known/openid-configuration
• public/.well-known/oauth-protected-resource
• public/.well-known/mcp/server-card.json
• public/.well-known/agent-services-status.md
• .tmp/nginx-edit/baileyengineers.com.live2 (downloaded baseline)
• .tmp/nginx-edit/baileyengineers.com.proposed2 (applied)
• .tmp/nginx-edit/bak-path-v2.txt (server-side backup path)
• src/content/devlog/2026-05-05-agent-readiness-disclosure-stubs.md (this file)

Modified:

• public/.well-known/agent-skills/index.json — added service_documentation field
• public/.well-known/agent-skills/schema.json — allowlists service_documentation
• /etc/nginx/sites-available/baileyengineers.com on production — added one location block

When to re-test

Don’t re-run isitagentready.com before ~2026-05-26 (≥3 weeks from today’s first round, ≥2 weeks from this round). Per memory feedback_visibility_retest_cadence, crawlers need ~2 weeks to surface new infrastructure; earlier reads create false-negative anxiety.