* fix(agent-readiness): align OAuth resource with actual public MCP origin
isitagentready.com's OAuth Protected Resource check enforces an
origin match between the scanned host and the metadata's `resource`
field (per the spirit of RFC 9728 §3). Our metadata declared
`resource: "https://api.worldmonitor.app"` while the MCP endpoint is
publicly served at `https://worldmonitor.app/mcp` (per vercel.json's
/mcp → /api/mcp rewrite and the MCP card's transport.endpoint).
Flip `resource` to `https://worldmonitor.app` across the three
places that declare it:
- public/.well-known/oauth-protected-resource
- public/.well-known/mcp/server-card.json (authentication block)
- api/mcp.ts (two WWW-Authenticate resource_metadata pointers)
`authorization_servers` intentionally stays on api.worldmonitor.app
— that's where /oauth/{authorize,token,register} actually live.
RFC 9728 permits AS and resource to be at different origins.
No server-side validation breaks: api/oauth/*.js and api/mcp.ts
do not bind tokens to the old resource value.
* fix(agent-readiness): align docs/tests + add MCP origin guardrail
Addresses P1/P2 review on this PR. The resource-origin flip in the
previous commit only moved the mismatch from apex to api unless the
repo also documents apex as the canonical MCP origin.
- docs/mcp.mdx: swap api.worldmonitor.app/mcp -> worldmonitor.app/mcp
(OAuth endpoints stay on api.*, only the resource URL changes)
- tests/mcp.test.mjs: same fixture update
- tests/deploy-config.test.mjs: new guardrail block asserting that
MCP transport.endpoint origin, OAuth metadata resource, MCP card
authentication.resource, and api/mcp.ts resource_metadata
pointers all share the same origin. Includes a regression guard
that authorization_servers stays on api.worldmonitor.app (the
intentional resource/AS split).
9c3c7e8657