Agent Know-How

MCP is moving from a client-side convenience to production infrastructure. Vendors are shipping official servers — HashiCorp's Terraform MCP server reached GA so agents can drive Terraform Registry APIs, and reference builds wire up SaaS servers (Amazon Quick, Cisco Webex) into working assistants.

The actuation surface is expanding to the browser: WebMCP is in Chrome origin trials, letting a site expose JavaScript functions and HTML forms as tools to an in-page agent. The open-source client side is filling in alongside the browser trial, with MIT, framework-free libraries (Persona.js) that ship native WebMCP so any site can build agentic experiences without a vendor SDK. A second browser vendor is now shipping the same surface as a platform feature rather than a library: Cloudflare previewed automatic WebMCP support that any site turns on from a dashboard toggle, no code change required, letting an in-browser agent interact with an unmodified page — the origin-trial pattern moving from "a team opts in" to "an operator flips a switch."

MCP is also becoming the assumed plug for hosted runtimes — Azure Functions' agents runtime gives every agent MCP server access (alongside 1,400+ connectors) out of the box — and the long tail keeps filling in with small task servers (e.g. a "coding tools" MCP that hands any agent file/shell coding primitives, and an AGPL-licensed search MCP built on Cloudflare AI Search so an agent can look up project-specific reference material instead of relying on what's already in its context).

Crucially, the protocol's growth is forcing the governance layer — Claude's enterprise managed authorization provisions MCP connectors org-wide through an identity provider (Okta first), so connector access and authorization are configured centrally rather than per user. That move from "connect a tool" to "govern a fleet of connectors" is the sign of a maturing standard.

A parallel control targets the server side of the connection rather than who connects: Cloudflare's WriteGuard (private beta) adds fine-grained security controls to MCP servers themselves — governing what actions a connected agent's tool calls are allowed to take, not just which servers it may reach — sharpening the auth story above (who connects) with a permissions story (what the connection is then allowed to do) at the layer MCP servers themselves control (see agent sandboxing for the same write-scoping instinct applied to sandboxes rather than servers).

The same maturation is landing in the client tooling: Claude Code added claude mcp login / logout to authenticate servers from the CLI without the interactive menu, and practitioners increasingly argue MCP's *core* value is exactly this — isolating the auth flow outside the agent's context window (and ideally out of the harness entirely) rather than the tool-description format itself. Read that way, the durable win of MCP is credential handling, not schema standardization.

That governance push is now backed at the protocol level: the MCP project promoted its Enterprise-Managed Authorization extension to stable status, replacing per-server consent prompts with a single sign-on flow through an org's identity provider. It generalizes what Claude's enterprise auth already did for one vendor into a spec any MCP client or server can implement.

The auth maturation is also spreading to a second client: OpenAI's Codex CLI 0.144.0 lets MCP tools request interactive authentication without an experimental opt-in flag, the same "auth flow isolated from the harness" pattern Claude Code's mcp login/logout already shipped, now landing outside Anthropic's own tooling.

The protocol itself just crossed a bigger threshold than any single vendor feature: the MCP 2026-07-28 specification is the largest revision since launch, making the protocol stateless and adding a governed extensions system alongside hardened authorization — a foundational rewrite of how clients and servers interoperate, not another connector. AWS's AgentCore Gateway already supports the new spec, giving platform teams a concrete reference implementation for what adopting it looks like in a managed gateway rather than a bespoke client patch.

Production security guidance is maturing alongside the spec: an InfoQ field guide lays out defense-in-depth for MCP in production across four architectural layers — safe execution, management infrastructure, outbound network calls, and the gateway itself — treating "securing MCP" as a layered architecture decision rather than a single gateway config toggle. It is the production-hardening counterpart to the governance and auth work below (see prompt injection and agent sandboxing for the attack surface this defends against).

The statelessness change is also drawing developer skepticism, not just adoption: dropping the initialize handshake and session header in favor of required method and tool-name headers reads to some practitioners as MCP converging back toward "just an API." That reaction sharpens what the protocol's durable value actually is: the shared tool-description and discovery layer this page tracks, not the stateful session the new spec just removed — a distinction worth stating plainly now that statelessness has made the two easy to conflate.

Two further signs of maturation:

• Tool discovery is becoming a scaling problem — as a single agent faces dozens of connectors, listing every tool schema blows the context budget, so clients are shifting to *search* over the registry; OpenAI's Codex now uses MCP tool search by default, treating "find the right tool" as a retrieval step rather than dumping the full catalog.
• What MCP carries is widening beyond tools: reference data and memory now ride the same protocol — Mozilla's MDN MCP service (and community spinoffs that repackage browser-compat data as a queryable SQLite-backed server) expose knowledge, while Elastic's Atlas serves *agent memory* over MCP — so MCP is becoming the generic plug for tools, data, and state alike.

MCP's governance thread picks up a matching org-wide provisioning control on the client side: Claude Code's managedMcpServers setting lets an organization push HTTP/SSE MCP servers to every user with the same entry shape as a project's own .mcp.json, extending connector governance from "who may connect" (identity-provider auth) to "which servers are available at all," configured centrally rather than per developer.

That "more than tools" widening now includes work distribution: TaskPeace is a task queue that coding agents pull work *from* over MCP, using the protocol as the plug for a job queue rather than a single tool call or a data/memory fetch — a third payload type alongside tools and knowledge/state.

The widening reaches symbolic computation too: Euclid-MCP puts a full SWI-Prolog engine behind the protocol, so an LLM client delegates deterministic logical inference instead of reasoning it out itself. It introduces Euclid-IR, an engine-agnostic intermediate representation for Horn-clause logic that's LLM-generatable and compiles to Prolog (or other backends), and exposes a translate-run-inspect-repair tool loop so the client keeps full access to proof traces and derivation logs rather than a black-box answer. On a compliance-sensitive IT security use case, LLMs alone hold up on small knowledge bases but hallucinate systematically as they grow, while Euclid-MCP returns exact answers with lower latency and more compact output — the authors argue semantic RAG is structurally unsuited to rule enforcement, positioning an MCP server, not the model, as the shared reasoning substrate for both RAG assistants and agentic systems.

Tool definition design is now a subject in its own right, separate from the auth/governance work above. AWS's field guide names two failure modes — bloated context (every tool schema loads on every call, whether used or not, contributing to context rot) and confusion (vague parameter names and oversized result payloads make the model call the wrong tool or the right tool wrong) — and walks a concrete progression from V1 (raw API exposed as-is) through richer descriptions, Literal-typed schema constraints, and lazy-loaded taxonomies (a separate discovery tool fetched only when needed) to a leanest-baseline design that cut per-turn context usage from 4% to 2%. The same guide cites Anthropic's own lazy-loading work reaching up to 85% token reduction, and recommends capping tool parameter counts at roughly eight. This is the tool-schema-quality half of the context-compaction problem: cutting the tokens a tool *definition* burns, not the tokens a conversation accumulates.

Two production deployments show the protocol carrying non-tool payloads into everyday enterprise workflows rather than just connecting an API. Dropbox wired MCP into its internal knowledge platform, Dash, so an AI-assisted code review can pull the threat model and security requirements for a pull request and check the implementation against design intent — security context riding the same protocol as a tool call (see prompt injection). Amazon Bedrock AgentCore uses pre-built MCP server connectors, plus fine-grained access control and persistent memory, to let an agent query multiple business data sources in natural language while automatically enforcing role-based boundaries — cross-system business intelligence assembled from configuration rather than custom integration code.

A cloud-vs-local gap gets a concrete bridge: AWS built a secure MCP bridge that lets a cloud-hosted Bedrock AgentCore agent call MCP servers running on a user's own laptop, tunneling signed messages over an existing WebSocket connection through a browser extension and Chrome native messaging — no open inbound ports or VPN required. It is the reverse direction of the usual MCP story (a cloud agent reaching local tools and files rather than a local agent reaching a cloud API), addressing the "AgentCore runs in the cloud, but the user's tools live on their laptop" gap directly.

Governance is also consolidating at the cloud gateway layer, not just inside the protocol's own auth extensions: Azure API Management shipped a dedicated AI Gateway tier whose control plane is organized around models, MCP servers, and tools — not REST APIs — fronting Foundry, Bedrock, Vertex AI, and OpenAI behind one policy surface. It puts MCP server governance next to model governance in the same managed product, the tool-fleet counterpart to AWS's Claude Apps Gateway spend-and-telemetry control plane.

Client-side version interop widens too: the Claude Agent SDK for Python added support for MCP 2.x alongside 1.x for in-process SDK MCP servers, loosening the coupling between a harness's own dependency version and the protocol version its in-process servers speak. And a platform-native GA doesn't yet guarantee cross-client support: Microsoft's Azure DevOps Remote MCP Server reached general availability with a hosted endpoint into work items, repos, and pipelines, but shipped without Claude Desktop, Claude Code, ChatGPT, or Cursor support at launch — a reminder that "GA" and "works with every major MCP client" are still two separate milestones.

Claude Code's new managedMcpServers setting lets an organization push MCP servers to every user, extending connector governance from "who may connect" (identity-provider auth) to "which servers exist at all" (see State of the art above).

Prior update: The Claude Agent SDK for Python widened its in-process MCP server support to 2.x alongside 1.x, and Microsoft's Azure DevOps Remote MCP Server reached GA without Claude Desktop, Claude Code, ChatGPT, or Cursor support at launch — two data points that protocol-version and client-interop maturity aren't moving in lockstep (see State of the art above).

A shared protocol buys interoperability and reuse, but every connector you expose is a new permission and a new attack surface — MCP standardizes *access*, which makes authorization and blast-radius the hard part (see prompt injection). It also adds a moving dependency: server quality, versioning, and uptime become yours to manage, and a misbehaving or malicious server is now reachable by every agent that speaks the protocol. Best when you have many tools and many agents; overkill for a single hardcoded integration.

MCP is the integration layer you adopt instead of writing API wrappers — it turns tool connectivity into a fleet you provision and govern (identity-provider auth, per-connector permissions) rather than scattered glue code. The platform job shifts accordingly: from building connectors to running a connector registry safely, which is squarely an infra-and-security responsibility.