MCP standardized the connector, not what a server exposes through it

The conversation

On 25 November 2024, Anthropic published the Model Context Protocol, describing it in its own announcement as 'an open standard that enables developers to build secure, two-way connections between their data sources and AI-powered tools.' The announcement names the problem it addresses directly: 'Every new data source requires its own custom implementation, making truly connected systems difficult to scale.' Anthropic released a specification and software development kits on GitHub, added local server support to its Claude Desktop application, and published an open-source repository of prebuilt servers for sources including Google Drive, Slack, GitHub and Postgres.

What the documents show

The announcement describes a client-server architecture: a developer can expose data and tools through an MCP server, or build an AI application that acts as an MCP client connecting to those servers. The protocol's own current documentation, at modelcontextprotocol.io and retrieved 16 September 2026, describes MCP as 'an open-source standard for connecting AI applications to external systems,' comparing it to a USB-C port: a single standardized connector in place of a bespoke one for every combination of application and data source. Both documents state the same underlying claim in different words, that a common interface replaces one-off integrations built separately for each pairing of assistant and system.

The system boundary

The architecture separates the AI application from the systems it reaches: an MCP client, embedded in a host application, opens a connection to an MCP server, and the server is what actually holds or fetches the data and executes the tool. Neither document describes the protocol as giving a model unmediated access to a data source; access runs through the server's own implementation, which is free to apply its own authentication and scope limits before a request reaches the underlying system.

Where it fails

Because MCP standardizes the connection rather than the judgment of what to expose through it, the protocol's documentation places the responsibility for what a server exposes, and under what permissions, on whoever builds that server. A standard interface does not by itself guarantee a server is scoped narrowly or audited; it only guarantees that a compliant client can speak to it. A builder connecting an assistant to a new server through MCP is still reviewing that specific server's own access design, not relying on the protocol to have done so.

• What data and actions does a given MCP server expose, and who defined that scope?
• Does the host application show a user which server a tool call is being routed to before it runs?
• How are credentials scoped for a server the application does not control?

Anthropic's announcement and the protocol's own documentation establish what problem MCP was built to solve and how its architecture is structured; they do not themselves certify any particular server built against it.