What Is MCP: Model Context Protocol Explained Simply

An AI assistant knows almost everything about the world, but it does not know what you agreed on with a client yesterday. To get a meaningful answer, you have to paste the meeting transcript into the chat, copy data from the CRM, attach files. Every time, manually.

MCP (Model Context Protocol) removes this routine. It is an open standard that lets AI agents access external data directly: meetings, files, databases, email. In this article, we will look at how the protocol works, how it differs from an API, which apps support it, and how to connect your first server without writing any code.

What is MCP

MCP (Model Context Protocol) is an open standard for connecting AI agents to external data sources and tools. Published by Anthropic in November 2024 as an open specification: any service can implement support for the protocol once, and any agent will be able to work with it.

The protocol is evolving quickly:

• March 2025 — OpenAI announced MCP support;
• April 2025 — Google joined the standard;
• December 9, 2025 — Anthropic transferred MCP to the Linux Foundation (the Agentic AI Foundation) together with Block’s goose agent and OpenAI’s AGENTS.md specification. By that point, the ecosystem had grown to over 10,000 active servers and 97 million SDK downloads per month;
• July 28, 2026 — the current version of the specification was released: the protocol moved to a stateless core, and an extensions framework appeared, including support for asynchronous tasks.

Sources for dates and figures: Anthropic (2024, 2025), OpenAI (2025), Google (2025), the official MCP blog (2026).

The standard is often compared to USB-C. Before USB-C, every device had its own port and its own cable. USB-C replaced them with a single universal port. MCP does the same for AI integrations: one “port” for connecting agents to data.

What problem the protocol solves

Before MCP, every pair of “AI tool plus data source” required a separate integration. Want to give Claude access to files — one development project. Connect ChatGPT to a database — another. A company’s corporate agent — a third. With N tools and M sources, you get N × M integrations, each of which has to be built and maintained.

MCP changes the formula to N + M. A data source implements an MCP server once. An AI tool learns to work with MCP once. After that, any agent connects to any server without additional development.

For businesses, the shift to the standard means data stops being held hostage by a single tool. Meetings, documents, and tasks become available to any agent that speaks MCP — and the choice of tool is dictated by the job, not by the set of ready-made integrations a particular vendor happens to offer.

How MCP works: three components

The protocol’s architecture consists of three elements.

MCP Host — the application where the AI agent runs: Claude, ChatGPT, Cursor, or another client. The Host initiates connections to servers and manages them.

MCP Client — a component inside the Host that maintains the connection with a specific server. One Host keeps several clients: one for each connected data source. For the user, this is an invisible architectural detail.

MCP Server — a program on the data source side. It receives the agent’s requests and returns data or performs actions. There can be many servers: a separate one for files, one for email, one for a meeting service.

A server gives the agent three types of capabilities:

• Resources — data the agent can read: documents, database records, emails, meetings;
• Tools — actions the agent can perform: create a task, send an email, start a recording;
• Prompts — ready-made instructions for typical scenarios.

What this looks like in practice: you ask an agent “what did we decide about the budget at Tuesday’s meeting?”. The agent contacts the MCP server of the meeting service, finds the right recording on its own, reads the summary or searches the transcript, and returns the answer. No copying text, no switching between windows.

How MCP differs from an API

Both MCP and APIs connect programs to data. The difference is who uses them.

Important: MCP does not replace APIs — it is built on top of them. The MCP server itself calls the data source’s API, packages the response into a standard format, and passes it to the agent. The API remains the internal machinery of the service.

What you can do with MCP: scenarios by role

The value of the protocol shows on concrete tasks. Typical examples for working teams:

Sales. The agent is connected to the meeting service and the CRM. A manager asks: “What objections came up on calls with this client this quarter?” — and gets a summary across all conversations instead of re-reading dozens of recordings.

Product. The results of user interviews are scattered across months. The request “collect all integration requests from the last two months of interviews” turns disjointed transcripts into a single list.

HR. A recruiter asks: “Quick summary of the interview with candidate Smirnov: strengths, risks, agreements” — the agent finds the right meeting in the archive on its own.

Managers. “What tasks did we set at this week’s planning meetings, and who owns them?” — the answer is assembled across all of the team’s meetings at once, instead of relying on participants’ memory.

The common pattern: instead of manually searching the archive, a person asks a question in natural language, and the agent reaches the right data by itself.

Types of MCP servers

The server ecosystem is growing quickly. The main categories:

• files and local data — access to documents on your computer;
• databases — PostgreSQL, SQLite, MongoDB, and others;
• development tools — GitHub, GitLab, Jira, Linear;
• communications — email, messengers, calendar;
• meeting and document services — call recordings, summaries, tasks from meetings.

You can find ready-made servers in Anthropic’s official repository on GitHub, in the connector directories of clients (Claude’s connector directory already includes servers for working with meetings), and in the built-in marketplaces of individual agents, such as Devin (Cognition, 2025).

A separate category is corporate and local servers: companies deploy MCP servers inside their own perimeter so that agents work with data that must not leave the building. Such servers connect like regular ones but live on the company’s infrastructure.

For teams in CIS countries, there are local entry points as well: the MCP Hub in Yandex Cloud AI Studio lets you connect external servers by URL and bind them to agents.

Which clients support MCP in 2026

The list keeps growing. As of mid-2026, the protocol is supported by:

• Claude — web version, desktop app, and Claude Code;
• ChatGPT — web version and app;
• code editors — Cursor, Windsurf, Zed, the Cline and Continue extensions for VS Code;
• console agents — Gemini CLI, Codex CLI, Kimi CLI;
• platforms — Yandex Cloud AI Studio (MCP Hub), OpenClaw.

In major clients, protocol support extends beyond a single app: OAuth authorization carries over between the web version, desktop, and mobile. Connect a server once — use it everywhere.

Myth: “MCP only works on desktop”

At the start, in late 2024, this was true: only local applications supported the protocol. That is why articles from that period (and fresh reprints of them) still claim that MCP necessarily requires Claude Desktop or desktop ChatGPT.

In 2025 the situation changed. The web versions of Claude and ChatGPT received connectors with OAuth authorization: a server is added by URL, access is confirmed with a “Sign in” button, with no configuration files. Desktop remains a working option, especially for local servers, but it is no longer a requirement.

How to connect an MCP server: the general principle

The process is similar across most clients and takes a few minutes:

1. Get access: create an API key in the service’s settings or add the server via OAuth.
2. Copy the server address and configuration from the documentation.
3. Paste the configuration into the client’s settings.
4. Restart the app or reload the page.

Two authorization methods:

• OAuth, the recommended one. An OAuth-capable client shows a “Sign in” button: you confirm access on the service’s page, and you are done. The key is never copied anywhere, and access can be revoked per application.
• API key. The key is created in the service’s settings and specified in the client’s configuration. Suitable for scripts, CI builds, and clients without OAuth support.

Three problems people most often hit when connecting:

• Outdated transport. Modern servers run on Streamable HTTP. A client configured for the old HTTP+SSE transport from early versions of the protocol will return a 405 error. The fix is switching the transport in the client’s settings.
• Clients without custom headers. Some web connectors do not accept HTTP headers, so services allow passing the key directly in the server address. This is convenient, but remember: the key is visible in the configuration — do not publish it or commit it to public repositories.
• Limits. Servers have daily limits on tool calls, which depend on the plan. When exceeded, the client returns a 429 error with a waiting time. This is not a breakdown — it is a signal to check the limits of your plan.

After connecting, the agent sees the server in its list of tools and contacts it as the conversation unfolds.

Security: what to check

When connecting an agent to work data, it is worth checking three things.

Where keys are stored. When connecting via API key, it is saved in the configuration on your device. With OAuth, the token lives with the client, while the data service keeps the ability to revoke access for a specific application.

Which actions are allowed. Servers usually split tools into reading data (read) and modifying it (write). A sensible minimum: connect the agent with read permissions, and enable write only where it is genuinely needed.

What happens to the data next. An important nuance that is often missed: the data provider’s zero data retention (ZDR) policy does not extend to the external AI client. When a meeting transcript reaches Claude or ChatGPT, from that point it is processed under that platform’s rules: storage periods, model training, and access are now governed by the platform. A short checklist for the security team before connecting:

• which data the agent will see and what it can do with it: read only, or also modify;
• whether request history is stored on the client side and for how long;
• whether access for one application can be revoked without touching the others;
• whether the processing complies with personal data regulations.

For data from Russia, Federal Law 152-FZ serves as an additional reference point: personal data of citizens cannot be transferred to services without consent for cross-border transfer, and this requirement does not disappear when connecting via MCP.

Summary

MCP solved a long-standing problem of AI tools: agents stopped being “chatbots with a limited context window” and gained access to real work data. The standard appeared in November 2024, within two years it was adopted by all major players, and its governance moved to the Linux Foundation. The protocol is young and keeps evolving, but it has already become the de facto standard for connecting agents to data. The sooner you set up the servers you need, the faster agents will start working with your meetings, documents, and tasks — instead of whatever was pasted into the chat.

What’s next

If you want to see how the protocol works on a specific category of data, the logical next step is a breakdown of MCP for meetings: how recording and summary services connect to agents and what you can ask about your own calls. That article also compares the available meeting servers.

And you can try the protocol in action on a service that already holds your meetings: resalt.app transcribes meetings for free and gives AI agents access to them via MCP.