What Is MCP? Model Context Protocol Explained

The Model Context Protocol (MCP) is an open protocol for connecting an AI application to external systems. An MCP server describes the data and actions it exposes. A compatible AI client discovers those capabilities and exchanges structured JSON-RPC messages with the server.

The protocol has three server primitives: tools for executable actions, resources for contextual data, and prompts for user-selected instruction templates. A host application, such as an IDE, chat client, or custom agent, creates a separate MCP client connection for each server it uses.

MCP defines that client-server boundary. It does not define how an AI model reasons, which data a host may expose, or which actions a user should approve. Those controls belong to the host, the MCP server, and the permissions attached to the underlying systems.

Why MCP exists

AI applications need current data and external actions to do work beyond a chat response. They may need to inspect a repository, retrieve a document, query a database, create an issue, or call a business API. Each connection needs a description of available operations, their inputs, their results, and their access rules.

Before MCP, an application team usually built that integration separately for each AI client. MCP standardizes the server interface. A server can expose one capability model to compatible clients while retaining its own implementation, data store, and authorization logic.

Host, client, and server

The host is the AI application you interact with. It manages connections, the user interface, permission prompts, and the model context. The host creates an MCP client for each server connection. The client maintains protocol communication with one MCP server.

An MCP server is a program that exposes selected capabilities. A local filesystem server might expose files and search operations. A remote service might expose an organization’s knowledge base, an issue tracker, or a database query interface. One host can use several servers at once, with separate connections and permissions for each one.

Tools, resources, and prompts

Tools are executable functions with typed inputs and results. A model may request a tool call to search, write, query, or invoke an API. Tool definitions use JSON Schema to describe valid arguments.
Resources provide contextual data, such as file contents, database schemas, API responses, or documentation records. The host decides when to retrieve and place that data in model context.
Prompts are reusable templates that a user explicitly selects. They can reference the server’s tools and resources for a defined task.

The control split is deliberate. Tools are model-controlled after the host permits them. Resources are application-controlled. Prompts are user-controlled. A read-only documentation server therefore has a different operational risk from a server that can modify records or execute code.

How MCP messages move

MCP uses JSON-RPC. The client discovers server capabilities, then calls methods such as tools/list, resources/list, prompts/list, resources/read, prompts/get, and tools/call. The server validates the request and returns structured content or an error.

A tool result can contain text, images, audio, resource links, embedded resources, or structured output. The host decides how to display the result and whether the model receives it as context. Tool execution requires a second boundary: the host and server must decide which calls need user confirmation.

The 2026-07-28 protocol revision uses a stateless HTTP core. Each request carries the protocol version, client metadata, and capabilities it needs. A server that needs state across calls returns an explicit handle for the client to pass back on a later request.

Local and remote MCP connections

Local servers commonly use stdio. Your host launches a process on your machine and communicates through standard input and output. This fits local files, development utilities, and software that needs access to your workstation.

Remote servers use Streamable HTTP over HTTPS. They fit shared SaaS services, company platforms, and cloud databases. Remote servers can serve many clients and commonly use OAuth-based authorization to identify the account and scopes attached to a connection.

Connection	Typical use	Primary review point
Local server over stdio	Files and software on your machine	Executed command and process privileges
Remote server over HTTPS	Shared services and cloud systems	Endpoint trust and OAuth scopes

How to connect an MCP server

Confirm that your host supports the server’s MCP version, transport, and required extensions.
Choose one narrow task, such as reading documentation or searching a repository.
Inspect the local command or remote URL, requested scopes, tool descriptions, and data access before you connect.
Complete the authorization flow when the server requires it.
Run a read-only request first. Review parameters and returned data before approving writes, deployments, purchases, or outbound messages.

Authorization and security

Remote MCP authorization follows OAuth 2.1 and OpenID Connect conventions. A protected server identifies its authorization service and supported scopes. The client receives an access token and sends it with requests to the MCP server.

Grant the smallest scope that fits the task. Read-only access, message sending, record deletion, and deployment access require different approvals.
Review every local command. A local MCP server runs code on your machine and may reach files, network services, or credentials available to the process.
Treat tool descriptions and tool results as untrusted input. Retrieved webpages, documents, and server responses can carry prompt-injection instructions.
Keep explicit approval around destructive or high-value actions. Review the exact target and parameters, not only the tool name.
Validate token audience and issuer in a remote server. A server must reject tokens that were issued for another service and must not forward client tokens to downstream APIs.

OAuth authentication does not secure an MCP deployment on its own. The server must enforce authorization for its own data and actions, and the host must control what the model can request.

MCP Apps, Tasks, and compatibility

Extensions add optional capabilities beyond the core protocol. A server feature requires support from both the client and the server.

MCP Apps provide interactive HTML interfaces inside compatible hosts. Hosts render them in sandboxed iframes, and UI actions pass through the same protocol path as direct tool calls. Tasks support long-running work: a server returns a task handle, then a client can retrieve status, update the task, or cancel it.

MCP vs function calling and APIs

Function calling is a model API feature. Your application defines functions, sends those definitions to a model, receives a requested call, and executes the code. An API is the interface offered by a service. MCP provides a standard interface between an AI client and a server that may call those APIs behind the scenes.

Question	MCP	Function calling
Primary role	Connects AI clients to external servers.	Connects a model API to application functions.
Scope	Tools, resources, prompts, transports, and extensions.	Functions defined by one application.
Typical owner	Server author and compatible clients.	The application team using the model API.

Building and testing an MCP server

Choose an SDK for your language and create a server with a clear name and version.
Expose one tool, resource, or prompt with a precise description and a narrow input schema.
Enforce permissions in the server, close to the data or action being protected.
Use stdio for a local integration or Streamable HTTP for a remote service.
Test discovery, successful calls, invalid inputs, authorization failures, and error responses with MCP Inspector.

For an stdio server, write logs to standard error or a log file. Standard output carries JSON-RPC messages; ordinary console output can corrupt the connection.

How to evaluate an MCP server

Identify the publisher and inspect the repository, release history, and installation instructions.
Read local commands, OAuth scopes, environment variables, and requested file or network access.
Inspect tool names, descriptions, schemas, and any write operations.
Confirm protocol and extension compatibility with your host.
Test a read-only task before you approve a write action.

Related resources

FAQs

Q: Do I need to write code to use MCP?

A: No. A compatible host can connect an existing MCP server through its settings or connector flow. You need code when you build or change a server, client, or host integration.

Q: Does MCP replace the API behind a service?

A: No. An MCP server commonly calls existing APIs or databases. MCP defines the interface between an AI client and that server.

Q: Does an MCP server send all data to the model?

A: The host and request determine what data enters model context. Review server capabilities, host settings, and returned results before you connect a sensitive source.

Q: Can MCP run on serverless infrastructure?

A: Yes. The stateless HTTP core in the 2026-07-28 specification fits ordinary HTTP infrastructure. Application state must use explicit handles or server-managed storage.

Last Edited: July 28, 2026