Your agent can write code and reason about a prompt. It cannot see your ticket system, your bookmarks file, or a private API unless something plugs those in. Copy-pasting context into chat works once. It does not scale.
MCP — the Model Context Protocol — is a standard plug for tools and data. Hosts like Cursor connect to MCP servers; those servers expose actions and context the model can use.
This post is the series glossary: terms, a mental model and when not to reach for MCP. Wiring Cursor comes next; building a server comes after that.
Definitions here track protocol version 2026-07-28. Later posts link back here instead of re-lecturing.
Note: MCP is not a replacement for Agent Skills. Skills are playbooks (what Skills are and how to use them). MCP is the tools-and-data plug. You often want both.
Warm-up: mental model
Think of three layers:
- The model decides it needs an action (function calling / tool use).
- The host (in this case - Cursor) owns the chat UI and creates an MCP client for each connected server.
- The server talks to real systems — files, APIs, databases — and returns results over MCP.
[Host: Cursor]
|
+-- MCP Client 1 ---- MCP Server A (e.g. filesystem)
| |
| files / dirs
|
+-- MCP Client 2 ---- MCP Server B (e.g. tickets API)
|
external API
JSON-RPC messages ride on a transport (local stdio, or remote HTTP). You do not need the wire format on day one — only the roles and what a server can expose.
The three roles
| Role | Job | Notes |
|---|---|---|
| Host | AI application that coordinates MCP: creates clients, shows tool approvals, decides what the model sees | Cursor in this series; Claude Desktop and other MCP-capable apps too |
| Client | Host-side connector for one server | One host can run many clients. You configure servers; the host creates the clients |
| Server | Program that provides context and capabilities to clients | Local (Cursor starts a process) or remote (a URL). Means the integration program, not a public website you must host first |
What a server can expose
Servers advertise three core primitives. Who typically drives each one:
| Primitive | Who drives it | Role in one line |
|---|---|---|
| Tools | Model (with your approval in the host) | Executable actions |
| Resources | Application / host | Contextual data to read |
| Prompts | User | Reusable templates / workflows |
Tool
A tool is an executable function the model can invoke — list files, add a bookmark, create a ticket. Tools have names, descriptions, and input schemas. Most day-one MCP value is tools.
Resource
A resource is contextual data the host can read — a file URI, a document snapshot, structured records. Resources feed context; they are not the same as “run this action.”
Prompt
A prompt (MCP prompt) is a reusable template the user can invoke — a guided workflow or slash-style starter. Hosts vary in how they surface prompts; tools are the most consistently supported.
How the plug talks
How MCP Talks: Discovery, Capability Negotiation, and Transports covers discovery and transports in depth. Here are the terms you will see everywhere else.
JSON-RPC
JSON-RPC is the message style MCP uses: structured requests and responses (and notifications). SDKs hide most of it; you care when debugging broken messages.
Transport
A transport is how client and server exchange those messages. Same protocol ideas; different pipes.
stdio
stdio means the host starts a local process and talks over standard input/output. Typical for “run this npx command on my machine.” Best starting point for learning.
Streamable HTTP
Streamable HTTP means the client talks to a server over HTTP (optionally with streaming). Typical for remote or shared servers. Do not start by hosting a public URL — connect locally first; remote hosting is Host an MCP Server for Public Use.
Capability negotiation
Capability negotiation is how clients and servers advertise what they support (tools, resources, prompts, and related features). Protocol 2026-07-28 makes requests more self-describing; you do not need the _meta field layout to use Cursor.
Schema
A schema describes tool (or other) inputs so the host and model know which arguments are valid — often JSON Schema, commonly authored with helpers like Zod in TypeScript servers.
MCP vs Skills vs function calling
| Agent Skills | Function calling | MCP | |
|---|---|---|---|
| What it is | On-demand playbooks (SKILL.md) | Model emits a structured tool request | Standard plug for tools / resources / prompts |
| Best for | “How we commit / review / deploy” | The model choosing an action | Sharing and wiring integrations across hosts |
| You write | Instructions | Usually nothing (host + tools) | An MCP server, or you connect one someone else wrote |
Skills tell the agent how to work. Function calling is how the model asks for an action. MCP is how tools and data arrive in a portable way. See AI Agent Skills for the playbook side.
When not to use MCP
Skip MCP when:
- A one-off chat instruction is enough.
- An always-on rule already covers the behavior.
- You only need a Skill playbook, not a live integration.
- You could run the script yourself faster than wiring a server.
- You are tempted to build a custom host / agent loop — that is out of scope for this series (and usually unnecessary if Cursor already hosts MCP).
Reach for MCP when the agent needs repeatable access to tools or data outside the chat — especially if you want the same server in Cursor today and another MCP host later.
What plugging in looks like
Hosts read a config file that names servers. In Cursor, a local stdio entry looks roughly like this:
{
"mcpServers": {
"example": {
"command": "npx",
"args": ["-y", "some-mcp-server"]
}
}
}
Field-by-field Cursor setup, project vs global files, and a working lab are in Plug In an MCP Server in Cursor.
MCP Registry
The MCP Registry is a public catalog where people find servers (and later, where you can publish). Discovery belongs early in the vocabulary; shipping your own package is a later post.
Official architecture overview: MCP docs (2026-07-28). Spec entry point: architecture.
This series
Recommended path (each post is self-contained for its title):
Parts 5–8 link here for term refreshers. Advanced posts open with a short “Before you start” gate instead of a second glossary.
Terms at a glance
| Term | One-liner |
|---|---|
| Host | AI app that coordinates MCP (e.g. Cursor) |
| Client | Host-side connector to one server |
| Server | Program that exposes tools / resources / prompts |
| Tool | Model-invoked action |
| Resource | Contextual data to read |
| Prompt | User-invoked template / workflow |
| Transport | Pipe for messages (stdio or Streamable HTTP) |
| stdio | Local process over stdin/stdout |
| Streamable HTTP | Remote-style HTTP transport |
| Capability negotiation | Advertising what each side supports |
| Schema | Description of valid tool inputs |
| MCP Registry | Public catalog for finding (and later publishing) servers |
Wrap-up
MCP is the standard plug between an agent host and the tools or data the model needs. Learn the three roles, the three primitives, and when Skills or a plain rule are enough. Then connect a real server in Cursor — that is the whole next step.