Elie Habib 9c3c7e8657 fix(agent-readiness): align OAuth resource with public MCP origin (#3345) ...

* 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).

2026-04-23 19:42:13 +04:00

9.6 KiB

Raw Permalink Blame History

View Raw