Workflow diagrams

MCP Complete Explanation

Aishwarya Srinivasan Six diagrams · article order The USB-C for AI

How the Model Context Protocol connects AI to tools and data — the drawer-of-chargers problem it solves, the host–client–server anatomy, where it sits in the agent loop, the stack it complements, the safe way to plug a server in, and the fifteen-minute path to building your own.

Illustrates Sections 1–2 of the article

1. From Point-to-Point Chaos to One Standard Plug

Why MCP exists — the drawer-of-chargers problem of AI integrations — and the USB-C-style fix the protocol introduces.

Stage 1 of 4

Before MCP — the drawer of chargers

App 1 → DatabaseApp 1 → CRM App 2 → DatabaseApp 2 → Slack App 3 → CRMApp 3 → Files

Ten applications × a hundred tools ≈ a thousand bespoke, brittle point-to-point integrations — each one written, tested, and maintained by hand.

→ one plug

After MCP — one standard cable

Any AI app Claude ChatGPT Cursor
→
MCP — one common language
→
Server: database Server: CRM Server: Slack Server: files
November 2024Anthropic releases MCP as an open standard.
December 2025Donated to the Linux Foundation — vendor-neutral and community-governed.
≈ 100,000 → 97 millionDownloads a month in about eighteen months.
✓
Write the connector once. Any MCP-compatible application — Claude, ChatGPT, Cursor, or your own agent — can use it with no rewrites and no special casing per platform.
Illustrates Section 3 of the article

2. Host, Client, Server: The Three Pieces

The USB-C analogy maps almost perfectly: the host is the phone, the in-host MCP client is the port, and the MCP server is the accessory you plug in.

Stage 1 of 5
Host — the AI app · like your phone The application you talk to — Claude Desktop, Cursor, VS Code, ChatGPT, or your own agent.
↓
MCP client — the USB-C port inside the host Speaks the protocol and manages each connection. You never need to see it: invisible plumbing to you, the endpoint doing the talking to the protocol.
stdio or HTTP↓
MCP server — the accessory you plug in A small program that wraps tools and data sources (your database, calendar, GitHub…) and exposes them in the standard MCP format. Do not let the name intimidate you — it can literally be a hundred lines of Python running on your laptop.

Tools

What the model can do — like giving a new hire software access so they can take actions.

Resources

What the model can read — like handing the new hire the company wiki.

Prompts

Reusable templates for common tasks — like your standard operating procedures.
?
Discovery at runtime. When a client connects it simply asks “What do you have?” — the server advertises its tools, resources, and prompts with descriptions and typed inputs. Nothing is hardcoded into the client or the model, which is why adding a server feels like magic.

Example from the article: a filesystem server exposes read and write operations as tools, and lets the model open files as resources.

Illustrates Section 4 of the article

3. Where MCP Sits: The Agent Loop

MCP alone is not an agent. An agent is a harness — a loop around the model: the model reasons, the harness manages memory, state, and real-world actions, and MCP is the company badge that gets the agent into every system it may touch.

Stage 1 of 8
Model — the brain Harness — the workstation + workflow MCP — the company badge
1Userasks a question in plain language
↓
2Model · the braindecides it needs something external — say, pulling rows from a database
↓
3Harness · workstationroutes that intent through an MCP client to the right server
↓
4MCP clientcalls the matching tool on the server
↓
5MCP serverdoes the actual work and returns the rows
↓
6Harnesshands the result back — it joins the model’s context
↓
7Model · the brainkeeps reasoning with the new information
↓
↺
Until the task is complete. Model decides, harness executes, MCP connects — that is the whole dance.

This is why MCP took off together with agents: before MCP, every tool meant teaching the agent a one-off interface; with MCP, any agent that speaks the protocol can use any server.

Illustrates Section 5 of the article

4. MCP Below Function Calling, Above Your APIs

MCP replaces nothing you already use — it sits underneath the layers you already have and standardizes the connection between them. That is also why the plugin era quietly ended.

Stage 1 of 6

The stack MCP complements

Function calling — a model capability The model looks at the task, decides a tool is needed, and produces a structured request with the right arguments. “Should I make a call, and what should I say?”
↓
MCP — the transport Carries that request to the tool and brings the result back. “How does that call actually reach the other end?” Function calling is deciding to call and dialing; MCP is the telephone network.
↓
Your API — does the actual work A point-to-point connection to one service. APIs do not go anywhere on their own — MCP sits on top of them so every model can discover and call them the same way.

Why plugins lost (2023)

A ChatGPT plugin was proprietary: built for one platform, and wanting the same capability anywhere else meant building it again. The old proprietary charger — one cable per brand.

How MCP flips it

One open protocol; every platform implements the same port. Build your server once and it works on Claude, ChatGPT, Cursor, VS Code, and whatever agent framework you run.
→
Nothing gets replaced. If someone tells you MCP replaces your APIs, they have misunderstood the stack: function calling is a model capability, MCP is the protocol, and the API still does all the work. When you build with MCP you are giving function calling somewhere standardized to land.
Illustrates Sections 7–8 of the article

5. Local vs Remote — and the Gate Before You Plug In

The two flavors of server, the security gate most tutorials skip, and how a server actually gets used once you have passed it.

Stage 1 of 8
Start Found a server to use. Search first — the integration you need probably already exists.
↓
Security gate Verified publisher — or have you read the code yourself? Server code is usually small enough that you actually can.
✕ no
Do not run it An MCP server is code with a direct line into your AI’s context — and often your real accounts and data. Like plugging a USB stick you found in a parking lot into your laptop.
✓ yes
Local or remote? Two flavors of server — pick by what you are connecting.

Local — over stdio

Runs on your machine and talks to the client over stdio (standard input and output between processes). What you want for local files and experimentation.
Config: add the launch command to the app config

Remote — over HTTP

Hosted elsewhere; connect over HTTP and typically authenticate with OAuth, like signing in with your Google account. How most companies expose their products.
Config: add the server URL to the app config
either path↓
Restart the app Claude Desktop, Cursor, or VS Code picks up the new configuration entry.
↓
Handshake + discovery The client handles the handshake and discovers the tools automatically — nothing hardcoded. After that you simply talk to your AI and it uses the tools when needed.
↓
Use it Recommended start: local and low-stakes — a filesystem server — and watch how the model calls its tools.
!
Practitioner’s checklist. Prefer verified or code-reviewed servers · least privilege always — read-only credentials if it only reads · keep a human in the loop for writes, deletes, and messages · at team scale, route servers through a central gateway or internal registry.

The numbers behind the gate: independent assessments found only about 13% of public MCP servers meet high trust thresholds, and early 2026 produced real incidents — dozens of CVEs, tool-poisoning attacks hiding instructions inside tool descriptions, and a path-traversal flaw that exposed thousands of apps.

Illustrates Section 9 of the article

6. The Fifteen-Minute Server: From Function to Live Tool

With FastMCP in the official Python SDK, your first working MCP server is genuinely a fifteen-minute project: write a typed, documented function, add a decorator, and your code becomes a tool.

Stage 1 of 7
1Pickone API or data source you use daily — Notion, a weather API, a read-only view of your own database
↓
2Writea normal Python function with type hints and a docstring
↓
3Decorateadd the FastMCP decorator — the SDK turns it into a fully described MCP tool automatically, no protocol plumbing by hand
↓
4Verifytrigger it in the MCP Inspector — a local web interface — before any model touches it
↓
5Registeradd the server to your Claude Desktop or Cursor configuration file
↓
6Liveyour AI calls your code over stdio — a real first server in about fifteen minutes
scale later↓
Graduate only when needed Move to HTTP with OAuth once more than one person needs it. Most people overbuild their first server — do not.
✓
The one-liner to remember: MCP is not the intelligence part — it is the plumbing part. The teams winning with AI are exactly the ones doing that plumbing well. (TypeScript developers: the official TypeScript SDK is just as solid.)

Python is the shortest path — but validate in the Inspector first, connect to your client second, and only graduate to HTTP with OAuth once more than one person needs the server.