Model Context Protocol: The Standard That's Rewiring AI Tool Use

Six months after Anthropic open-sourced the Model Context Protocol, the adoption curve has passed the tipping point. MCP servers are shipping for databases, cloud platforms, development tools, and enterprise applications. The standard is becoming what HTTP was for web pages — the common protocol that lets AI models interact with external systems without bespoke integration code.

Why does a tool-use standard matter?

Before MCP, every AI application that needed to interact with external tools required custom integration code. Want your agent to query a database? Write a function, define the schema, handle the serialisation. Want it to also read files, call APIs, and manage cloud resources? Write separate integrations for each, in each framework you use, for each model provider.

This created three problems:

• Duplication. The same Postgres integration was being written thousands of times across different projects.
• Fragility. Each custom integration had its own error handling, authentication, and schema definition approach.
• Lock-in. Tools built for LangChain did not work in CrewAI. Tools built for Claude did not work with GPT.

MCP solves this by defining a standard protocol for tool servers. An MCP server exposes tools with typed schemas, handles its own authentication and state, and communicates over a standard transport layer (stdio for local tools, HTTP with Server-Sent Events for remote). Any MCP client — regardless of the AI framework or model behind it — can discover and use these tools.

According to the MCP specification, the protocol supports three core primitives: tools (functions the model can call), resources (data the model can read), and prompts (templates the model can use).

What does the server ecosystem look like?

The ecosystem has grown rapidly. Notable MCP servers now available include:

• Databases: PostgreSQL, MySQL, SQLite, MongoDB, with read/write capabilities and schema introspection
• Cloud platforms: AWS, Google Cloud, and Azure resource management
• Development tools: Git operations, file system access, Docker management, browser automation via Playwright
• Communication: Slack, email, calendar integration
• Knowledge: Web search, document retrieval, vector database queries

The MCP server registry lists over 50 community-maintained servers, with new ones appearing weekly. Enterprise vendors including Stripe, Notion, and Linear have shipped official MCP servers for their platforms.

How do you set up MCP in practice?

The practical setup follows a client-server pattern:

1. Install or build MCP servers for the tools your agent needs. Most are available as npm or pip packages. Configuration typically involves a JSON file that specifies which servers to run and how to connect to them.

2. Configure your MCP client. Claude Desktop, Claude Code, Cursor, and other MCP-compatible applications read a configuration file that lists available servers. The client handles server lifecycle — starting, monitoring, and restarting servers as needed.

3. The model discovers tools at runtime. When a conversation starts, the client queries each server for its available tools and schemas. The model sees these as callable functions with typed parameters and descriptions. No prompt engineering required — the model understands the tool interfaces from their schemas.

4. Execution flows through the server. When the model decides to use a tool, the client sends the request to the appropriate server, which executes the operation and returns the result. The model incorporates the result into its reasoning.

The key architectural decision is server placement. Local MCP servers (running on the same machine as the client) suit development tools and file access. Remote MCP servers (running on a server, accessed over HTTP) suit shared resources like databases and cloud APIs. The transport layer handles both transparently.

What are the security considerations?

MCP introduces a significant attack surface that practitioners need to understand:

• Tool permissions. An MCP server that exposes database write access gives the model the ability to modify production data. Scope server capabilities to the minimum required. Read-only servers are safer defaults.
• Prompt injection via tool results. Data returned by MCP tools can contain adversarial content. If a model reads a web page via an MCP server, that page can contain instructions that attempt to hijack the model's behavior. Output sanitisation at the server level is essential.
• Credential management. MCP servers often need API keys and database credentials. These must be managed through environment variables or secret stores, never embedded in configuration files committed to version control.

The OWASP Foundation's guidelines on LLM security apply directly to MCP deployments. Treat every tool invocation as a privilege boundary.

Where is MCP heading?

The protocol is evolving toward a more capable standard. Upcoming features in the specification include:

• Streaming responses for long-running tool operations
• Authentication standards for remote server access
• Capability negotiation so clients can discover what features a server supports
• Sampling — allowing servers to request LLM completions, enabling recursive agent architectures

For teams building agent systems today, adopting MCP is a defensible bet. The protocol is open, the ecosystem is growing, and the major AI frameworks are converging on it as the standard integration layer. Build your tools as MCP servers, and they work everywhere. Build them as framework-specific integrations, and you are locked in.