If you are building AI agents, you have likely encountered the integration challenge: connecting your agent to external tools and data sources requires custom code for every new API. The Model Context Protocol (MCP) solves this problem by providing a universal, open standard for connecting AI applications to external systems.

Introduced by Anthropic in late 2024 and now donated to the Agentic AI Foundation, MCP has become the industry standard for connecting AI agents to tools and data. MCP's TypeScript and Python SDKs reached 97 million monthly downloads in March 2026, up from approximately 2 million at launch. This guide explains the key concepts and architecture you need to understand to build an AI agent using MCP.

 

What Is the Model Context Protocol?

The Model Context Protocol (MCP) is an open protocol that enables seamless integration between LLM applications and external data sources and tools. Whether you are building an AI-powered IDE, enhancing a chat interface, or creating custom AI workflows, MCP provides a standardized way to connect LLMs with the context they need.

MCP takes inspiration from the Language Server Protocol (LSP), which standardized how development tools add support for programming languages. In a similar way, MCP standardizes how to integrate additional context and tools into the ecosystem of AI applications.

The protocol uses JSON-RPC 2.0 messages to establish communication between hosts, clients, and servers.

 

MCP Architecture: Hosts, Clients, and Servers

MCP follows a client-server architecture where an MCP host—an AI application like Claude Code or Claude Desktop—establishes connections to one or more MCP servers. The host accomplishes this by creating one MCP client for each MCP server.

The key participants are:

  • MCP Host: The AI application that coordinates and manages one or multiple MCP clients
  • MCP Client: A component that maintains a connection to an MCP server and obtains context from it for the host to use
  • MCP Server: A program that provides context to MCP clients

Each MCP client maintains a dedicated connection with its corresponding MCP server. Local MCP servers that use the STDIO transport typically serve a single MCP client, whereas remote MCP servers that use the Streamable HTTP transport typically serve many MCP clients.

For example, when Visual Studio Code connects to an MCP server like the Sentry MCP server, the runtime instantiates an MCP client object that maintains the connection. When it connects to another server, such as a local filesystem server, it instantiates an additional client.

 

MCP Layers: Data and Transport

MCP consists of two layers:

  • Data layer: Defines the JSON-RPC-based protocol for client-server communication, including lifecycle management and core primitives such as tools, resources, prompts, and notifications
  • Transport layer: Defines the communication mechanisms and channels that enable data exchange between clients and servers, including transport-specific connection establishment, message framing, and authorization

The data layer implements a JSON-RPC 2.0-based exchange protocol that defines the message structure and semantics. All messages between MCP clients and servers must follow the JSON-RPC 2.0 specification.

 

The Three Core Primitives: Tools, Resources, and Prompts

MCP servers expose functionality through three building blocks, each serving a distinct role in how LLMs interact with external systems.

 

Primitive Explanation Examples Who Controls It
Tools Functions that your LLM can actively call, deciding when to use them based on user requests. Tools can write to databases, call external APIs, modify files, or trigger other logic. Search flights, send messages, create calendar events Model
Resources Passive data sources that provide read-only access to information for context, such as file contents, database schemas, or API documentation. Retrieve documents, access knowledge bases, read calendars Application
Prompts Pre-built instruction templates that tell the model to work with specific tools and resources. Plan a vacation, summarize meetings, draft an email User

 

Tools: Model-Controlled Actions

Tools enable AI models to perform actions. Each tool defines a specific operation with typed inputs and outputs. The model requests tool execution based on context.

Tools are schema-defined interfaces that LLMs can invoke. MCP uses JSON Schema for validation. Each tool performs a single operation with clearly defined inputs and outputs.

Tools may require user consent prior to execution, helping to ensure users maintain control over actions taken by a model.

Protocol operations for tools include:

  • tools/list: Discover available tools—returns an array of tool definitions with schemas
  • tools/call: Execute a specific tool—returns the tool execution result

Example tool definition:

{
  name: "searchFlights",
  description: "Search for available flights",
  inputSchema: {
    type: "object",
    properties: {
      origin: { type: "string", description: "Departure city" },
      destination: { type: "string", description: "Arrival city" },
      date: { type: "string", format: "date", description: "Travel date" }
    },
    required: ["origin", "destination", "date"]
  }
}

 

In a travel planning scenario, the AI application might use several tools: a flight search tool that queries airlines and returns structured flight options, a calendar tool that marks travel dates, and an email tool that sends automated out-of-office messages.

Resources: Application-Controlled Data

Resources provide structured access to information that the AI application can retrieve and provide to models as context. Unlike tools, which are model-controlled, resources are application-controlled—the application decides which resources to make available and when.

Resources are passive data sources that provide read-only access to information such as file contents, database schemas, or API documentation.

Prompts: User-Controlled Templates

Prompts are pre-built instruction templates that tell the model to work with specific tools and resources. They are user-controlled, meaning users can select or customize prompts to guide the model's behavior.

 

How to build an AI agent using MCP

 

How an MCP-Powered AI Agent Works: Conceptual Workflow

When building an AI agent that uses MCP, the conceptual workflow follows these steps:

 

  1. User provides a request: The user gives the AI agent a high-level goal or question.
  2. Model processes the request: The LLM within the host application receives the request and determines what information or actions are needed.
  3. Model discovers available tools: Through the MCP client, the model can call tools/list to discover what tools are available from connected MCP servers.
  4. Model selects and calls a tool: Based on the user's request and the available tools, the model selects an appropriate tool and calls it via tools/call with the required parameters.
  5. MCP client forwards the request: The MCP client sends the JSON-RPC request to the MCP server over the configured transport (STDIO or Streamable HTTP).
  6. MCP server executes the tool: The server receives the request, executes the tool (e.g., queries a database, calls an external API, modifies a file), and returns the result.
  7. Result is returned to the model: The MCP client receives the result from the server and passes it back to the model.
  8. Model generates a response: The model incorporates the tool result into its response to the user.

This workflow can involve multiple tool calls in sequence, with the model deciding which tools to call based on intermediate results.

 

Capability Negotiation

MCP uses a capability-based negotiation system where clients and servers explicitly declare their supported features during initialization.

Servers declare capabilities like resource subscriptions, tool support, and prompt templates. Clients declare capabilities like sampling support and notification handling. Both parties must respect declared capabilities throughout the session.

Each capability unlocks specific protocol features for use during the session. For example, tool invocation requires the server to declare tool capabilities.

Error Handling

MCP defines standard error handling through JSON-RPC 2.0 error responses. When a tool call fails—for example, due to invalid parameters, authentication issues, or server errors—the MCP server returns a JSON-RPC error response with an appropriate error code and message.

Common error scenarios include:

  • Invalid parameters: The tool's input schema validation fails
  • Authentication errors: The client lacks valid credentials or permissions
  • Tool execution errors: The tool encounters an error during execution (e.g., API timeout, database connection failure)
  • Server errors: The MCP server itself encounters an internal error

 

The MCP client should handle these errors gracefully, potentially retrying with corrected parameters or informing the user.

Security and Authorization

Security is a critical consideration when building MCP-powered AI agents. MCP uses standardized authorization flows to build trust between MCP clients and MCP servers.

OAuth 2.1 Authorization

MCP follows the conventions outlined for OAuth 2.1. Authorization is strongly recommended when your server accesses user-specific data, needs to audit actions, grants access requiring user consent, or operates in enterprise environments.

The authorization flow works as follows:

  1. Initial handshake: When the client first tries to connect, the server responds with a 401 Unauthorized and provides a Protected Resource Metadata (PRM) document location.
  2. PRM discovery: The client fetches the PRM document to learn about the authorization server, supported scopes, and other resource information.
  3. Authorization server discovery: The client discovers what the authorization server can do by fetching its metadata.
  4. User authorization: The client opens a browser to the authorize endpoint, where the user logs in and grants required permissions.
  5. Token exchange: The client receives an access token and uses it for subsequent requests.

Local Server Considerations

For MCP servers using the STDIO transport, you can use environment-based credentials or credentials provided by third-party libraries embedded directly in the MCP server. Because a STDIO-built MCP server runs locally, it has access to a range of flexible options for acquiring user credentials.

Permissions and Least Privilege

Security experts recommend user-scoped OAuth 2.1 authentication with PKCE over broad service-scoped credentials to reduce the risk of AI agents acting with excessive privileges. Tool-level RBAC provides granular access control that server-level permissions cannot achieve, enabling least-privilege enforcement where analysts can read databases but not write.

The MCP server receives the token, validates it against the upstream provider, and uses the user's identity to determine what permissions the user actually has.

Human Oversight

MCP emphasizes human oversight through several mechanisms. Applications can implement user control through:

  • Displaying available tools in the UI, enabling users to define whether a tool should be made available
  • Approval dialogs for individual tool executions
  • Permission settings for pre-approving certain safe operations
  • Activity logs that show all tool executions with their results

 

Getting Started with MCP Development

To start building with MCP, you will need:

  1. An MCP host: Your AI application (e.g., Claude Desktop, Claude Code, or a custom application)
  2. An MCP client: The SDK handles client implementation—official SDKs are available for multiple languages
  3. An MCP server: You can build a custom server or use existing reference implementations

The official documentation at modelcontextprotocol.io provides comprehensive guides for building both servers and clients. The MCP Inspector is an interactive developer tool for testing and debugging MCP servers.

 

Frequently Asked Questions

What is the Model Context Protocol (MCP)?

MCP is an open protocol that enables seamless integration between LLM applications and external data sources and tools. It provides a standardized way to connect AI agents with the context and capabilities they need.

How does MCP differ from traditional API integrations?

Traditional API integrations require custom code for each new API. MCP provides a universal protocol—developers implement MCP once in their agent and it unlocks an entire ecosystem of integrations.

What are the three core primitives in MCP?

The three core primitives are tools (model-controlled functions), resources (application-controlled passive data), and prompts (user-controlled instruction templates).

Is MCP secure?

MCP supports OAuth 2.1 authorization and provides mechanisms for human oversight, tool-level permissions, and activity logging. Security best practices include user-scoped credentials and least-privilege access controls.

Do I need to build both a client and a server?

Most developers building AI agents will implement an MCP client within their host application and may build custom MCP servers to expose their own tools and data. You can also use existing MCP servers from the ecosystem.

What SDKs are available for MCP?

Official MCP SDKs are available for multiple programming languages, including TypeScript and Python. The SDKs abstract away many protocol details, making it easier to build clients and servers.

What is the current version of MCP?

The current specification version is 2026-07-28. MCP has seen rapid adoption, surpassing 400 million monthly SDK downloads.

 

Conclusion

The Model Context Protocol represents a significant step forward for AI agent development. By providing a universal, open standard for connecting AI applications to external tools and data sources, MCP eliminates the need for custom integrations and enables a thriving ecosystem of interoperable components.

Understanding MCP's architecture—hosts, clients, and servers—and its three core primitives—tools, resources, and prompts—is essential for any developer building agentic AI applications. The protocol's support for OAuth 2.1 authorization, capability negotiation, and human oversight mechanisms provides the foundation for building secure, trustworthy AI agents.

With official SDKs, comprehensive documentation, and a rapidly growing ecosystem, MCP makes it easier than ever to build AI agents that can securely interact with the systems and data they need to be truly useful.