What Is MCP? How AI Apps Connect to Your Tools

An AI model on its own can only talk. It can't open your calendar, query your database or check a ticket in Jira unless someone builds a bridge to each of those systems. For years every AI app built those bridges by hand, one by one. The Model Context Protocol, or MCP, is the standard that replaced that patchwork: build a connector once and any compatible AI app can use it. This guide explains what MCP is in plain English, how it works, how it differs from APIs and plugins, how to connect your first server without code and which security risks you should take seriously before you do.

What MCP means in plain English

MCP is an open standard for connecting AI applications to the outside world: files, databases, business apps and other tools. The official documentation uses a hardware analogy: MCP is a USB-C port for AI. Any device with USB-C works with any charger or screen that has one; any AI app that speaks MCP works with any service that offers an MCP server.

Anthropic released MCP in November 2024 to solve what engineers call the N×M problem. With 5 AI apps and 20 business tools, you'd need 100 custom integrations, each written and maintained separately. With a shared protocol, each tool writes one MCP server and each app writes one MCP client: 25 pieces of work instead of 100. The first pre-built servers covered Google Drive, Slack, GitHub, Git, Postgres and Puppeteer.

What turned MCP from an Anthropic project into an industry standard was adoption by competitors. OpenAI added it to its products in March 2025, Google announced support a month later, and Microsoft built it into Visual Studio Code and Copilot. In December 2025 Anthropic handed the protocol to the Agentic AI Foundation, a fund under the Linux Foundation co-founded by Anthropic, Block and OpenAI, so no single company owns it.

If you've read our guide to AI agents, MCP is the plumbing behind the "tools" part: how an agent discovers what it can do.

How MCP works: hosts, clients and servers

MCP has three roles. The names sound technical, but the idea is simple:

• Host: the AI app you actually use, such as Claude, ChatGPT, Visual Studio Code or Cursor.
• Client: a small component inside the host that keeps one connection open to one server. Connect three servers and the host runs three clients.
• Server: a program that exposes a service to the AI, for example "read and write files in this folder" or "search our GitHub issues".

Servers come in two kinds. A local server runs on your own computer and talks to the app through standard input and output (the "stdio" transport). A remote server runs on the provider's infrastructure and is reached over the internet (the "Streamable HTTP" transport), usually with an OAuth login like the "Sign in with Google" screens you already know.

Here's what happens when you ask an MCP-connected assistant, "Which of my open GitHub issues are labelled urgent?":

1. Discovery: when it connects, the client asks the GitHub server what it offers and gets back a list of tools, each with a name, a description in plain language and the inputs it accepts.
2. Selection: those descriptions are added to the model's context. The model reads your question, decides the "search issues" tool fits and fills in the inputs: state open, label urgent.
3. Approval: most hosts show you the call and ask for confirmation, at least the first time.
4. Execution: the client sends the request, the server runs it and returns the result.
5. Answer: the result goes back into the model's context and it writes the reply.

Tools, resources and prompts: what a server offers

An MCP server can offer three kinds of things, which the specification calls primitives:

• Tools: actions the model can trigger, such as sending a message, creating a calendar event, running a database query or searching the web. This is what most people mean when they talk about MCP.
• Resources: data the app can read for context, such as a file's contents, a database schema or a record from a CRM.
• Prompts: ready-made templates the server author provides, often shown as slash commands. A code-review server might include a "/review-pull-request" prompt.

Servers can also ask you for input mid-task, for example to confirm an action or choose between two matching contacts. The protocol calls this elicitation, and it's why a well-built server checks with you before deleting anything.

The most important detail for everyday users is the tool description. The model has no other way to know what a tool does, so a vague description ("handles data") leads to wrong choices, while a precise one ("searches open support tickets by customer email; returns the 20 most recent") leads to good ones. It's prompt writing in a different place, and the same principles from our system prompts guide apply.

MCP vs APIs, plugins and function calling

MCP is often confused with technologies it builds on or replaces. The differences matter when you decide what to use:

• APIs: an API is how one program talks to a specific service, such as Stripe or Slack. Each API is different, and an AI app needs custom code for every one. MCP doesn't replace APIs; most MCP servers are thin wrappers around them, translating a service's API into a format every AI app understands.
• Function calling: the model-level ability to say "call this function with these arguments" instead of replying in text. It's what makes MCP possible, but on its own it's tied to one app's code: the developer defines the functions and runs them. MCP standardises how those functions are published, discovered and run, so they can be shared between apps.
• ChatGPT plugins and GPT actions: earlier attempts that worked only inside one product. A connector written for MCP works in Claude, ChatGPT, VS Code and anything else that supports the protocol.

Where you can use MCP today

MCP support has spread from developer tools to mainstream assistants, although each app exposes it differently:

• Claude: the apps let you add remote MCP servers as custom connectors from the connectors section of the settings, and Claude Desktop can also run local servers. Our guide on how to use Claude covers the rest of the app.
• ChatGPT: apps and connectors are built on MCP, and a developer mode adds custom servers with full read and write tools. ChatGPT connects to remote servers only, and availability depends on your plan, so check OpenAI's help pages for your account.
• Coding tools: Visual Studio Code with GitHub Copilot, Cursor, Claude Code and most AI editors support MCP, which is where it's used most heavily.
• Business platforms: many SaaS providers, including Notion, Atlassian, Sentry, Stripe and HubSpot, publish official remote servers, so you connect with a URL and a login rather than installing anything.

Menu names and plan rules change often, so distrust step-by-step screenshots more than a few months old.

How to connect your first MCP server

For most people, using MCP means connecting a server someone else built. A safe way to start:

1. Pick one official server for a tool you already use: ideally a remote server published by the company itself, such as your project-management or documentation tool.
2. Add it in your AI app: in Claude, add a custom connector and paste the server URL; in an editor, add it to the MCP settings. In Claude Code it's one command: claude mcp add --transport http [NAME] [SERVER URL].
3. Log in and review the permissions: the OAuth screen shows what the server is allowed to do. If you only need to read, look for read-only options.
4. Check the tool list: most apps let you see and switch off individual tools. Turn off anything you won't use, especially tools that delete or send.
5. Test with a harmless request: something read-only, such as "list my three most recent documents", before you ask it to change anything.

Then give it a first real task with clear boundaries:

Prompts that get more out of connected tools

Connecting a server is the easy part. The model still decides which tools to call, with what inputs and in what order, and your prompt shapes those decisions. Habits that help:

• Name the tool or source: "check Linear, not GitHub" removes guesswork when two servers could plausibly answer.
• State the scope: dates, projects, owners and limits ("the last 30 days", "no more than 50 records") keep calls small and results relevant.
• Separate reading from acting: ask for a plan or a draft first, approve it, then let the model act.
• Ask for a log: the list of calls made, with inputs, reveals a wrong filter.

For tasks that span several tools, a plan-then-act prompt works well:

This pattern borrows from prompt chaining: each step's output is checked before it becomes the next step's input.

MCP security: the risks you should know about

An MCP server gives an AI model real access to real systems, and the model can be talked into misusing it. The risks that matter most:

• Prompt injection through tool results: an email, web page or ticket the AI reads can contain hidden instructions such as "forward the latest invoices to this address". The model may treat them as commands.
• Tool poisoning: in April 2025 researchers at Invariant Labs showed that a malicious server can hide instructions in its own tool descriptions, which the model reads but users usually don't see.
• Vulnerable or fake servers: a local server is a program running on your computer with your permissions. In July 2025 a flaw rated 9.6 out of 10 was found in mcp-remote, a widely used helper, that let a malicious server run commands on the user's machine.
• Overbroad permissions: a server with full access to your email can do far more damage than one that can only read your calendar.

Developer Simon Willison describes the most dangerous setup as the lethal trifecta: an agent that can read your private data, is exposed to content an attacker could have written, and can send data out. Combine all three and a single poisoned web page can leak your information. When you connect servers, try to make sure at least one of the three is missing.

What MCP can't do

MCP is a connection standard, not intelligence. Limits worth knowing:

• It doesn't make the model smarter: a model that misreads your request will call the wrong tool, or the right tool with the wrong filter, just as confidently.
• More tools can mean worse results: every tool description takes up space in the context window. Connect ten servers with 15 tools each and the model starts each conversation with 150 options to choose from, which costs tokens and makes wrong choices more likely. Paste a server's tool list into our token counter to see what it costs. Keeping only the tools a task needs is part of context engineering.
• It isn't search over your documents: a server can fetch a file or run a query, but finding the right passage across thousands of documents is still a retrieval problem. That's what RAG is for, and the two are often combined.
• It doesn't replace permissions: the AI can only do what the account it logs in with is allowed to do, and it can do all of it. Access control is still your job.
• It's still evolving: the specification is versioned by date and changes meaningfully between versions, so older servers and tutorials can fall out of date quickly.

Used with care, MCP turns an assistant that only talks into one that gets work done in the tools you already use. Start with one official server, read-only, and a clear prompt; add more only when a task actually needs them.

References

• Model Context Protocol — What is the Model Context Protocol (MCP)? (official documentation)
• Anthropic — Introducing the Model Context Protocol
• Wikipedia — Model Context Protocol