What Is MCP (Model Context Protocol)? How It Works and How to Set It Up

In short: MCP (Model Context Protocol) is an open-source standard that connects AI applications to files, databases and business tools. The application (the host) opens one client per server, and each server offers tools, resources and prompt templates. Claude, ChatGPT, VS Code and Cursor support MCP, and the current specification version is 2026-07-28.

An AI assistant needs a connection layer before it can reach your calendar, your code repository or your company database. MCP (Model Context Protocol) defines a shared standard for that layer. Before you roll it out at work, you need to know three things: how the protocol works, how to set up a server, and which permissions to give it.

MCP (Model Context Protocol) is an open-source standard for connecting AI applications to external systems, as defined on the MCP introduction page. Through MCP, a chat assistant or a code editor can reach local files, databases, search engines and internal company applications in the same way. The large language model (LLM) behind the assistant only produces text on its own, and it reaches outside systems through a connection layer like this one.

The project's own analogy is USB-C. Just as USB-C joins different devices with one kind of connector, MCP defines one kind of connection between AI applications and external systems. You write an integration once as an MCP server, and every application that supports MCP can use it.

Anthropic released the protocol as open source on 25 November 2024 with the announcement Introducing the Model Context Protocol. The specification is now developed in the modelcontextprotocol organization on GitHub, together with the SDKs and reference servers.

As of 2 November 2026, the current version is 2026-07-28. According to the MCP versioning page, versions are named by date, and the date marks the day of the last backward-incompatible change. Backward-compatible improvements do not change the version name. The earlier versions are 2025-11-25, 2025-06-18, 2025-03-26 and the first one, 2024-11-05.

The 2026-07-28 version brought a major change: the protocol is now stateless. According to the 2026-07-28 changelog, the initialize handshake of earlier versions is gone, and every request carries its own protocol version and client capabilities in the _meta field. Servers must report the versions and capabilities they support through a server/discover call. A separate backward-compatibility section covers servers and clients that still speak older versions. If a tutorial video or blog post dates from 2025 and describes the handshake, read that as a version difference.

MCP uses JSON-RPC 2.0 as its message format and is built on a client-server architecture. The 2026-07-28 specification says it takes inspiration from the Language Server Protocol, which gave editors shared support for programming languages.

The MCP architecture overview describes three roles.

• MCP host: the AI application the user works in, such as Claude Desktop, Claude Code or Visual Studio Code.
• MCP client: the component inside the host that manages the connection to a single server. The host opens a separate client for every server it connects to.
• MCP server: the program that provides context and capabilities. It can be a file system, a database, Sentry or one of your own internal applications.

The official documentation gives this example: when VS Code connects to a Sentry MCP server it creates one client, and when it then connects to the local file system server it creates a second client. A server that runs on your own machine is called a local MCP server, and one hosted on the internet is a remote MCP server.

Servers can offer three basic building blocks, called primitives.

• Tools: functions the model can call, such as writing a file, calling an API or running a database query. According to the Tools section of the specification, tools are model-controlled, which means the model looks at the context and decides which tool to call.
• Resources: data given to the model or the user as context, such as file contents, a database record or schema information.
• Prompts: ready-made prompt templates and workflows that the user can pick and use.

The client learns what a server offers through the tools/list, resources/list and prompts/list calls, and runs a tool with tools/call. A database server, for example, could offer a tool for queries, a resource for the schema and a prompt template with sample queries.

The client side has a building block too. Elicitation lets a server ask the user for more information or for approval in the middle of an operation. Sampling (a server asking the client for a model response), roots and logging, which earlier versions described, were deprecated in the 2026-07-28 version. According to the changelog, they keep working during the deprecation period, but new implementations should not rely on them.

Outside the core protocol there are also optional extensions. Two of them are Tasks, for long-running work, and MCP Apps, which shows interactive interfaces inside the chat. An extension takes effect when both the client and the server support it.

The Transports section of the specification defines two standard transports.

• stdio: the client starts the server as a subprocess on its own machine, and messages flow line by line over standard input and output. Local servers usually work this way and serve a single client. Under the stdio rules, the server must not write anything to stdout except MCP messages, and logging goes to stderr.
• Streamable HTTP: under the Streamable HTTP rules, every message goes to a single MCP endpoint as an HTTP POST, and the response comes back as JSON or as an optional SSE stream. Remote servers use this transport and can serve many clients. OAuth is recommended for authentication.

The older HTTP+SSE transport is deprecated. New servers are advised to move to Streamable HTTP.

These three are not rivals: they work at different layers.

An API is the interface a service exposes to the outside world. A weather service or your CRM offers an API. MCP does not replace an API. In the official Build an MCP server guide, the server defines two tools that call the API of the US National Weather Service. In other words, an MCP server is often an existing API wrapped in a form the model can understand.

Function calling (tool calling) is the model producing structured output that says "call this tool with these parameters". The application writes the tool definitions into the model provider's API in that provider's own format, and the application itself runs the tool. This works well for one application and one provider, but if you want the same integration in another application, you have to write it again.

MCP instead standardizes where tools live and how they are discovered and called. The host fetches the MCP server's tool list and passes it to the model. The model still uses its own tool calling ability to decide which tool to use, and the client runs the chosen tool through the MCP server. The MCP documentation also says the protocol only defines how context is exchanged, not how an application uses the model.

Put simply, function calling is how the model decides, the API is the service's front door, and MCP is the standard that connects those doors to different AI applications with the same plug. RuneLab's LLM Tool Use and Function Calling course follows the same order: first the function calling loop and tool schemas, then publishing the same internal service as an MCP server.

The MCP introduction page lists Claude, ChatGPT, Visual Studio Code, Cursor and MCPJam among the applications that support it. The table below is based on each vendor's own documentation and holds as of 2 November 2026. Features change often, so check the vendor's documentation again before you set anything up.

On the Microsoft side, MCP support is available in VS Code, GitHub Copilot and Copilot Studio.

There are two separate jobs: connecting an existing server to your application, or writing your own server.

To add a remote server in the Claude app, go to Settings > Connectors > Add > Add custom connector and enter the server URL. According to the Connect to remote MCP servers guide, once you have authenticated, you can switch individual tools on or off in the connector settings.

In Claude Code, one command is enough to add a remote server. The example below comes from the Claude Code MCP documentation.

claude mcp add --transport http notion https://mcp.notion.com/mcp

For a local server in Claude Desktop, you write the command that starts the server under the mcpServers key of the claude_desktop_config.json file. The example is the weather server from the Build an MCP server guide.

{
  "mcpServers": {
    "weather": {
      "command": "uv",
      "args": ["--directory", "/ABSOLUTE/PATH/weather", "run", "weather.py"]
    }
  }
}

In VS Code, choose "MCP: Add Server" from the Command Palette and add the server with an HTTP URL or a local command. According to the VS Code MCP documentation, VS Code's own format uses the servers key, while Claude Desktop uses the mcpServers key shown above. Check the format before you copy a configuration from one application to another.

In ChatGPT, open the Plugins section, click the plus button, choose Add custom MCP server and enter the server URL and the authentication details. The OpenAI MCP documentation states plainly that custom MCP servers are not developed or verified by OpenAI.

To find existing servers, there is the official MCP Registry. The Registry is currently in preview, and it stores metadata about where a server lives and how to install it, not the code itself. The official organization's reference servers are in the modelcontextprotocol/servers repository on GitHub. Being on a list does not make a server safe: see the security section below.

The official SDKs handle the protocol side of the work. According to the MCP SDK page, as of 2 November 2026 the Tier 1 SDKs are TypeScript, Python, C#, Go, Rust and Ruby. Java is Tier 2, and Swift, PHP and Kotlin are Tier 3. Each SDK adopts new protocol versions on its own schedule, so check your SDK's documentation to see whether it supports 2026-07-28.

The Python example in the Build an MCP server guide looks roughly like this. The function's type hints and docstring become the tool definition.

from mcp.server import MCPServer

mcp = MCPServer("weather")

@mcp.tool()
async def get_alerts(state: str) -> str:
    """Get weather alerts for a US state."""
    ...

if __name__ == "__main__":
    mcp.run(transport="stdio")

Test the server with MCP Inspector before you connect it to a model. According to the Local Server Security guide, Inspector lists every tool the server offers without a model in the loop. If you plan to open a remote server to many users, follow MCP's authorization specification. According to the changelog, the 2026-07-28 version recommends Client ID Metadata Documents for client registration, and OAuth Dynamic Client Registration is deprecated.

This path is also the flow of the Building MCP Servers and Clients (Model Context Protocol) course: the first server is written with the Python SDK and tested in MCP Inspector, then moved to a remote server with Streamable HTTP and OAuth. Turning the internal REST APIs and SQL sources you already have into MCP tools is the subject of the Enterprise System Integration with Model Context Protocol (MCP) course.

MCP can give a model the power to read files, run code and take actions in other systems. The 2026-07-28 specification says so openly, and it states that the protocol cannot enforce its security principles on its own: that responsibility lies with implementers. These are the risks that stand out in enterprise use.

While reading a web page, an email or a document that comes from an MCP server, the model may follow instructions hidden inside it. This is called indirect prompt injection. OWASP puts prompt injection, including the indirect kind, at the top of its LLM Top 10 as LLM01:2025 Prompt Injection. In the example in the OpenAI MCP documentation, a user wants the model to find a restaurant by checking their calendar and email, the model runs into a malicious comment, and it is steered into sending a password reset code from Gmail to a malicious site. In the Indirect Prompt Injection in RAG and Agent Systems course, we build this kind of chain end to end in an email assistant and close it with architectural defenses such as plan-then-execute.

We cover direct and indirect prompt injection examples and the layered defenses OWASP and the NCSC recommend in What is prompt injection?

Tool names and descriptions are instructions the model reads. A malicious server can hide directives in those descriptions. According to the Local Server Security guide, these directives can steer the model even if the tool is never called, and can even change how it uses the tools of other servers (tool shadowing). A server can also change its tool definitions quietly after you have approved them, which is called a rug pull. OWASP's MCP Security Cheat Sheet recommends pinning approved tool definitions with a cryptographic hash and reviewing them again when they change. Tool poisoning is also third on the OWASP MCP Top 10, which is in beta. The Agentic AI Supply Chain and Model Context Protocol (MCP) Security course demonstrates these three attacks in a lab, and you practice closing them with version pinning, schema hashing and container isolation.

In LLM06:2025 Excessive Agency, OWASP traces excessive agency to three roots: excessive functionality, excessive permissions and excessive autonomy. The MCP documentation answers this risk with the following points.

• Human approval: according to the Tools section of the specification, there should always be a human in the loop who can deny tool calls. Applications should show which tools are enabled and ask for confirmation before sensitive operations.
• Narrow scopes: according to the MCP Security Best Practices document, remote servers should first ask only for low-risk discovery and read scopes, and raise them as needed.
• No token passthrough: an MCP server must not accept an access token that was not issued for it, and must not pass such a token on unchanged to the API behind it. Doing so opens the door to confused deputy attacks.
• Care with local servers: a local server can read everything your user account can read, including SSH keys, cloud credentials and environment variables. The Local Server Security guide recommends running third-party servers in a container that mounts only the folder they need, pinning the version and verifying the publisher.

1. Keep an inventory of the MCP servers in use, and remove the ones nobody uses.
2. Verify each server's publisher and package name, and pin the version.
3. Read the tool descriptions once, and prefer clients that ask for approval again when a tool definition changes.
4. Never turn off human approval for tools that write, delete, pay or send data outside the company.
5. Use OAuth for remote servers, keep scopes narrow and log tool calls.
6. Route your agents' model requests through a single endpoint. An LLM gateway such as RuneGate logs every request and stops it before a team's budget is exceeded.

An AI agent is a system that calls tools to reach a goal and chooses its next step based on the result. MCP standardizes how those tools connect to the agent, and it does not decide how the agent plans. We covered architectures where several agents work together in one agent or many.

Whether tools get called correctly also depends on the model behind the agent. According to the Hati Glint SQL model card, RuneLab's open-weight Hati Glint SQL model raises the rate of fully correct calls from the base model's 76.9% to 78.9% across 1,000 Turkish tool calls from tool families it did not see in training. When the model runs on your own server, the data the agent reads and the tool results stay inside the company too. We described that kind of setup in our guide to offline AI.

MCP gives an AI application a standard way to connect to files, databases, business applications and internal systems. You write an integration once as an MCP server, and applications that support MCP, such as Claude, ChatGPT, VS Code and Cursor, can use it.

In AI, MCP stands for Model Context Protocol. In medicine, MCP refers to the metacarpophalangeal joint, and in Microsoft certifications it means Microsoft Certified Professional. Neither has anything to do with MCP in AI.

An MCP server is a program that offers tools, resources and prompt templates to an AI application. It can be a local process on your own computer that talks over stdio, or a remote service on the internet that uses Streamable HTTP.

In the Claude app, add the remote server's URL under Settings > Connectors > Add custom connector. In Claude Code, run the claude mcp add command with the --transport http option, a server name and the URL. In Claude Desktop, local servers go in the claude_desktop_config.json file.

Yes. As of 2 November 2026, you can add a custom MCP server in ChatGPT from the Plugins section, and the OpenAI Responses API accepts remote MCP servers as a tool type. OpenAI states that custom servers are not developed or verified by OpenAI.

An API is the interface a service exposes to the outside world. An MCP server often wraps an API and turns it into tools that AI applications can discover and call. MCP does not replace the API, it opens it up to models in a standard way.

RAG is a technique that fetches relevant passages from your documents before the model writes its answer. MCP is a connection protocol. The two can work together: the example MCP server in OpenAI's documentation offers tools that search a vector store.

The protocol defines security principles but cannot enforce them on its own. Security depends on which servers you install, which permissions you grant and whether you keep human approval switched on. The risks named most often are prompt injection, tool poisoning and excessive agency.

• Model Context Protocol, MCP introduction page: the definition, the USB-C analogy and the applications that support MCP
• Model Context Protocol, MCP versioning page, 2026-07-28 specification and 2026-07-28 changelog: versions, the stateless protocol and deprecated features
• Model Context Protocol, MCP architecture overview, Tools section of the specification, Transports section of the specification, stdio rules and Streamable HTTP rules
• Model Context Protocol, Build an MCP server guide, Connect to remote MCP servers guide, MCP SDK page and MCP Registry
• Model Context Protocol, MCP Security Best Practices and Local Server Security guide
• Anthropic, Introducing the Model Context Protocol, Claude connector documentation, Claude Code MCP documentation and Claude API MCP connector documentation
• OpenAI, OpenAI MCP documentation: ChatGPT setup, the Responses API and the prompt injection example
• Microsoft, GitHub, Cursor and Google: VS Code MCP documentation, Copilot Studio MCP documentation, GitHub Docs MCP page, Cursor MCP documentation and Gemini CLI MCP documentation
• RuneLab, Hati Glint SQL model card: the Turkish tool calling result
• GitHub, modelcontextprotocol organization and modelcontextprotocol/servers repository
• OWASP, LLM01:2025 Prompt Injection, LLM06:2025 Excessive Agency, MCP Security Cheat Sheet and OWASP MCP Top 10 (beta)

• What is an LLM?
• One agent or many?
• How RAG finds answers
• Courses: Enterprise System Integration with Model Context Protocol (MCP), Building MCP Servers and Clients (Model Context Protocol), Agentic AI Supply Chain and Model Context Protocol (MCP) Security