What is MCP and how it gives AI access to tools

MCP in simple terms

A standard chat with a model only knows what is in its context. It cannot independently open your project folder, read a task in a tracker, or create a record in a CRM. Each such scenario requires a connection to an external system.

MCP standardizes this exact connection. Instead of a separate non-standard "adapter" for every combination of AI application and service, the server describes its capabilities using common rules. The client learns which tools are available, what arguments they accept, and what they return. Official documentation compares MCP to USB-C for AI: the analogy is simplified, but it conveys the idea of a compatible connector well.

Who really needs MCP

MCP is useful not because it's a trendy acronym, but when AI needs to work with the actual external world. For example, a code editor assistant reads allowed files and Sentry issues; an internal agent searches for company policy; an assistant analyzes a table; a support system creates a ticket after operator approval.

MCP does not replace APIs. Most often, an MCP server internally still calls an API, a database, or a file system. It adds an AI-oriented layer of description and exchange. Similarly, MCP does not make the model smarter and does not guarantee the correct tool selection — it only provides it with structured capabilities.

How host, client, and server work

The specification has three roles. Host — the application the user is working in: an editor, a desktop client, or a custom AI product. Inside the host, a separate client is created for each connected server. Server — the program that provides data or actions.

1. Connection. The Host starts a local server via STDIO or connects to a remote one via Streamable HTTP.
2. Discovery. The client receives the protocol version, capabilities, and a description of available functions.
3. Selection. The model sees the tool name, description, and argument schema and decides if a call is needed.
4. Confirmation. The client can show the human the upcoming action and the data that will be passed.
5. Execution. The server performs the operation and returns a structured result, which enters the model's context.

A local server is not necessarily safer just because of the word "local": it can execute code with your user permissions. A remote server, in turn, receives the data passed to it and lives under another provider's policy.

Three basic capabilities: tools, resources, and prompts

The specification version from July 28, 2026, also describes optional extensions: long asynchronous tasks, structured skills, and MCP Apps with interactive forms or charts inside a compatible client. This is no longer just "function calling," but support for more complex workflows.

MCP and function calling are not the same thing

Function calling usually means: a developer pre-passes function schemas to the model, and their program executes the chosen call. MCP standardizes how a separate server publishes and executes such capabilities for different clients. In other words, function calling is the mechanism of function selection by the model, while MCP is an integration protocol around tools, resources, prompts, transport, and authorization.

This explains the practical advantage: one MCP server can be connected to several compatible host applications. However, "works everywhere" should not be taken literally. Clients support different parts of the specification, and a new version may outpace an SDK or a specific product.

What changed in MCP 2026-07-28

Many 2025 guides already describe the previous architecture. The current specification has made the protocol stateless: sessions, headers Mcp-Session-Id and the initial handshake initializeremove from the core. The protocol version and client capabilities are now passed in the metadata of every request.

• the server is required to support server/discover for declaring versions, capabilities, and identity;
• changes to tools, prompts, and resources lists may come through the new subscriptions/listen;
• long tasks have been moved from the core to an official extension;
• Roots, Sampling, and Logging are marked as deprecated for new implementations;
• the old HTTP+SSE is finally marked as deprecated — new servers should aim for Streamable HTTP;
• list results received caching hints to reduce latency and redundant requests.

Secure MCP connection route

1. Formulate a single task. Don't connect "all of GitHub" just for an experiment. Start, for example, by reading issues from a single test repository.
2. Find an official server. Prefer a server published by the service owner themselves. Check the domain, repository, documentation, and update date.
3. Grant minimal permissions. A separate test account or a read-only token is better than a main key with full access.
4. Limit tools. If the client allows an allowlist, keep only the necessary tools. Fewer tools mean lower cost, lower latency, and a smaller attack surface.
5. Don't disable confirmations. For creation, deletion, payments, publishing, and sending messages, a person must see and approve the action.
6. Check the log. Look at the actual server arguments and responses. Do not test on personal data, secrets, or a production database.

This prompt is not a system defense: a malicious instruction in the data may attempt to bypass it. Real control must reside in permissions, tool allowlists, confirmations, and client code.

Common mistakes

• Installing a random package via a single command. A command can download and execute third-party code. Verify the owner and source.
• Giving full disk access. For a file server, allow a separate test folder instead of the home directory.
• Storing a secret in a repository's JSON configuration. Use environment variables or a secret manager and never commit a real token.
• Trusting a tool description. The description comes from the server and does not, in itself, prove that the function behaves exactly as described.
• Automatically approve the request. Prompt injection in a page, issue, or document can nudge the agent into an undesired action.
• Confusing MCP with the model. Response quality, context window, and token cost depend on the model; MCP only connects it to external capabilities.

For general token storage rules, read our separate guide on API key security in Vibe Coding. And if you are just choosing an environment, start with an overview of AI programming tools.

Short checklist

• There is a specific task for which MCP is better than a direct API.
• The server comes from a known owner or a verified repository.
• Permissions are limited to test data and a minimal scope.
• Available models only need the required tools.
• Actions with a request require explicit confirmation.
• Arguments and responses are logged without saving secrets.
• The scenario is tested for prompt injection and incorrect tool selection.
• The SDK version is compatible with the specification you are following.

FAQ

Do you need to program to use MCP?

Not always. Some AI applications connect to remote servers via an interface. But for a local server, you often have to set up an environment, change the configuration, and understand the permissions.

Can the MCP server directory be trusted?

The directory helps find options but does not replace verification. The owner, repository, remote server domain, requested permissions, and data policy are important.

Does the need for API keys disappear?

No. A remote service still requires authorization, and a local server can use its own API keys. MCP defines the integration method but does not override access control.

Where to start practically?

From a secure read-only scenario on test data: one official server, one folder or one project, minimal permissions, and confirmation of every call.