This was generated by AI during triage.

Summary

Production MCP get_world_brief intermittently fails its second internal fetch to POST /api/news/v1/summarize-article. Sentry has split the same tool failure into two groups:

• WORLDMONITOR-WZ: summarize-article HTTP 401 — 8 events / 6 users, firstSeen 2026-07-21 14:42 UTC, lastSeen 2026-07-22 15:13 UTC.
• WORLDMONITOR-XF: summarize-article HTTP 405 — 5 events / 3 users, firstSeen 2026-07-22 12:55 UTC, lastSeen 2026-07-23 04:00 UTC.

Both are tagged environment:production, runtime:edge, route:api/mcp, step:tool-execution, and tool:get_world_brief. The failures span multiple releases rather than one deploy:

• 401: six events on a54bc76e..., one on 09d4f88a..., one on 2051db45....
• 405: four events on 09d4f88a..., one on 2051db45....

The dispatch catch converts both into JSON-RPC -32603 with Internal error: data fetch failed, so callers receive no world brief.

Code-path evidence

On current origin/main:

1. api/mcp/dispatch.ts derives baseUrl from the inbound MCP request: new URL(req.url).origin.
2. api/mcp/registry/rpc-tools.ts builds ${base}/api/news/v1/summarize-article, signs that exact URL/body through buildAuthHeaders, and explicitly sends method: POST.
3. The generated news-service route accepts POST only for /api/news/v1/summarize-article.

Therefore, HTTP 405 is not explained by the intended handler contract. It suggests that some supported inbound MCP origin/alias resolves the sibling fetch through a different routing surface, rewrites the method, or reaches a stale/mismatched deployment. This is an inference to verify, not a confirmed root cause.

HTTP 401 can come from a different seam: raw env/user-key propagation, internal-HMAC validation, entitlement re-check, or a mismatched origin/signature target. Current Sentry capture records only route/step/tool and the status string; it omits the inbound base host, auth kind, bounded upstream error code, and downstream response markers needed to distinguish those paths.

Reproduction and acceptance contract

1. Exercise get_world_brief through every supported production MCP host/alias and auth kind (env_key, user_key, pro). Record the resolved downstream origin and status without logging credentials, cookies, query strings, or response bodies containing user data.
2. Prove whether the sibling request reaches the canonical generated POST route. If inbound-origin derivation is the cause, route internal tool fetches through the canonical API origin while preserving exact HMAC method/URL/body binding.
3. For 401, distinguish invalid/missing internal signature, entitlement denial, invalid raw key, and other gateway auth outcomes. Preserve the existing billing-verification response contract where applicable rather than flattening it into -32603.
4. Add bounded telemetry tags for auth_kind, normalized inbound host class, downstream operation, status, and safe error code/marker. Do not add secrets or personal identifiers.
5. Add regression tests covering the reproduced 401 and 405 paths, including at least one non-canonical supported MCP origin.
6. Verify a valid caller receives a successful world brief and that a genuine billing/auth denial remains typed and actionable.

Duplicate check

Public full-text search found no open issue or PR for summarize-article HTTP 405, and no open PR for get_world_brief. The two open issues mentioning get_world_brief (#4925 and #4277) concern story identity and free-tier teaser scope, not this production failure.

Priority

P1: a data-bearing MCP tool hard-fails for valid production calls across multiple releases, and the current error envelope hides the actionable auth/routing cause.