MCP Servers Explained: What They Are and Why Devs Should Care

If you have watched Claude talk about "connectors," ChatGPT list "plugins," or a Copilot agent call into Linear, you have already brushed against MCP. The Model Context Protocol is the open standard underneath a lot of those hooks. This post is for developers who want the mechanics, not the pitch deck.

Disclosure: This piece is from the ToolPotion Media Team. ToolPotion is our product. The numbers and product details below come from our MCP explainer and from the public MCP docs.

The short version

MCP is a shared menu format between an AI app and the tools around it. Each app you connect runs a "kitchen." Its MCP server publishes a menu: tools like "search pages," "create task," "read calendar," each described in plain language. Your AI app is the waiter. It can read any kitchen's menu, decide what fits the request, and (ideally) ask before anything that changes data.

Anthropic started MCP in 2024. By 2026 it lives under a Linux Foundation effort co-founded with OpenAI and Block. Maintainers have reported on the order of half a billion SDK downloads a month (MCP explained). The USB-C metaphor on modelcontextprotocol.io is useful for the plug. The restaurant metaphor is better for the risk: menus are written by the kitchen, and the waiter reads every word, including fine print you never see.

Connecting AI apps before and after MCP

Hosts, clients, servers

Three roles do the work:

  1. Host: the AI app you type into (Claude Desktop, Cursor, a custom agent UI).
  2. Client: the piece inside the host that speaks MCP.
  3. Server: the process that exposes tools and resources for one system (Notion, Postgres, your internal API).

Before MCP, five AI apps times twenty services meant up to a hundred custom integrations. With MCP, each AI app learns the format once and each service publishes one server. Notion's hosted server, for example, documents setup for Claude Code, OpenAI's Codex, and Cursor from the same address. Portability is the point.

When you sketch an architecture diagram, draw the host as the process your developer lives in, and draw each server as a small sidecar or remote process with its own credentials. That mental model stops people from treating MCP like a single SaaS product.

What people actually use it for

Real setups we see in the wild:

  • Pull context from Notion or Confluence into a coding session without copy-paste.
  • Open a Linear or Jira ticket from a chat that already has the stack trace.
  • Query a Postgres or SQLite database with a human confirming the SQL shape first.
  • Wire Slack notifications only after a review step in the host.

That last bit matters. An assistant that proposes a patch inside an IDE is different from an agent that can write to production systems. We covered that split in more depth in coding assistants vs agent builders. MCP sits under both patterns; the review policy is still yours.

A useful team exercise: list every tool your proposed server would expose, then mark each one R (read), W (write), or X (execute / side effect). Anything marked W or X needs an approval story before you ship the server to a shared host config.

Where it goes wrong

An AI with tool access can be tricked or over-trusted. Prompt injection against tool descriptions is not theoretical. A malicious or sloppy server can expose destructive tools with friendly names. A host that auto-approves write actions turns a menu into a blank check.

Before you click Connect on anything:

  • Prefer servers you or your org maintain, or well-known vendors with a dated security page.
  • Read the tool list. If a "search" tool can also delete, treat it as write access.
  • Keep write tools behind explicit approval in the host.
  • Log tool calls the same way you log admin API use.
  • Apply the same privacy questions you would to any AI vendor: training opt-out, retention windows, residency. Our privacy framework is the checklist we use internally.

Also watch for "helpful" servers that pull broad OAuth scopes. A docs-search connector that requests full drive write is not a search connector. Scope the token to the job.

Connecting a first server without drama

A safe first pass for most teams:

  1. Pick a read-only server (docs search, calendar read, issue list).
  2. Run it locally or in a locked-down network path.
  3. Confirm the host shows each tool call before execution.
  4. Exercise one happy path and one refusal path (ask it to do something the server cannot).
  5. Only then add a write tool, still with approval.

If you are building your own server, keep the tool surface small. One job per tool. Descriptions that say what happens to data, not just what the marketing name is. Version the schema so hosts do not silently pick up new write capabilities.

For local development, treat the server process like any other sidecar: pin versions, store secrets outside the repo, and document the exact host config snippet in the team wiki. When someone clones the repo six months later, they should not have to reverse-engineer which MCP endpoints were trusted.

Why this matters for your roadmap in 2026

MCP will not replace your internal APIs. It standardizes how assistants discover and call them. That changes hiring and architecture conversations:

  • Platform teams can publish one server instead of N plugins.
  • Security can review a tool catalog instead of a pile of one-off OAuth apps.
  • Product can switch AI hosts without rewriting every connector.

It also means your threat model expands. Every new server is a new trust boundary. Treat it like adding a service account, not like installing a browser extension.

If your org is already deep into agent builders, MCP is the glue layer that keeps those agents from becoming a pile of brittle, vendor-specific plugins. If you are still mostly on coding assistants, MCP is how those assistants stop living only inside the editor buffer and start reading the systems your tickets already mention.

Practical takeaways

  • MCP is a protocol and menu format, not a single product.
  • Use it first for read paths with human approval on writes.
  • Portability is real when vendors publish one server for many hosts.
  • Security review the tool list, not the logo.
  • Pair MCP adoption with a written privacy and retention check.

If you want the longer walkthrough with the restaurant metaphor, incident notes, and a connect checklist, start here: What Is MCP? The Model Context Protocol Explained.

ToolPotion Media Team