What Is MCP? Model Context Protocol for Developers

MCP (Model Context Protocol) is an open standard for connecting AI apps to tools and data through one interface. Instead of every editor inventing a private plugin format, a server can expose capabilities once and any compatible host can call them.

That sentence is the whole product pitch. Everything difficult follows from the same fact that makes agents useful: tools have consequences. Reading a file is not the same as posting to production Slack with your bot token.

This article explains why MCP exists, how client and server roles split, what security actually requires, how coding hosts like Cursor and Claude Code fit the picture, and when you should ignore MCP entirely. For the broader agent problem (compounding failure, human gates), see the complete AI agents guide. For coding-specific tooling without connectors, start with the complete AI coding guide.

Concepts here track the public MCP specification’s architecture and security posture as read for PromptHive coverage (verifiedAt 2026-08-05). Product UIs and marketplace catalogues change; the decision shape does not.

The short answer

• MCP standardises how hosts talk to tool servers — not how smart the model is.
• You need it when building or installing connectors; you do not need it to type code with Tab or run a repo-local agent.
• Servers are power with a blast radius — credentials, side effects, prompt injection via tool descriptions and returned data.
• The protocol does not enforce safety. Hosts must ask consent; operators must scope credentials; humans must staff approvals for irreversible actions.

Why MCP exists

Before shared protocols, each assistant integration was a one-off:

• one plugin for IDE A,
• a different function-calling schema for chat product B,
• a third webhook story for automation platform C.

That does not scale if you want one “create Jira issue” implementation to work everywhere your team already works.

MCP’s bet:

1. Servers expose tools/resources in a standard way.
2. Hosts (IDEs, desktop agents, chat apps with tool use) discover and invoke them.
3. Models propose tool calls; hosts decide what runs.

Function calling / tool use already existed inside single products. MCP is the interoperability layer so the ecosystem is not N×M bespoke adapters. Our AI glossary defines it in one line; this page is the developer-depth version.

Core pieces (without the mystique)

You will also hear JSON-RPC: the message shape for requests and responses. You do not need to hand-write RPC to use a server someone else built; you do need to care when you implement one.

Client vs server in one concrete picture

Imagine Cursor or Claude Code as the host. You enable a GitHub MCP server. The client inside the host connects to that server. When you ask “open a PR for this branch,” the model may emit a tool call; the host shows a permission UI (if implemented correctly); the server performs the API call with whatever token you configured; the result returns into the model context.

The model never held your token in a well-designed setup — the server process and host policy did. Bad setups blur that line. Do not blur it.

What MCP is not

• Not a model. It does not replace Claude, GPT, or anyone’s weights.
• Not automatic security. See below.
• Not required for “AI coding.” Repo read/write and shell in Claude Code or Agent mode in Cursor are already agent capabilities. MCP extends the tool perimeter.
• Not a guarantee of multi-agent reliability. Long tool chains still fail by multiplication — the arithmetic in our agents guide still applies.

Security: the part of the spec people skip

The MCP security guidance is unusually blunt for an industry that sells demos. In substance it says:

1. Hosts must obtain explicit user consent before invoking tools.
2. Tool descriptions should be treated as untrusted unless they come from a trusted server — because descriptions are prompt surface area.
3. The protocol cannot enforce these rules at the wire level. Implementations choose whether to honour them.

Read that again. A standard can recommend consent; your editor can still auto-run a destructive tool if someone ships it that way. You choose hosts with real permission UX, and you choose which servers to install.

Threats that matter in practice

Prompt injection deserves special weight: once an agent reads untrusted content and can act, attackers write instructions into the content. There is no complete fix. Shorten tool lists, require approval for side effects, and never give an agent prod-admin by default.

We run this philosophy in production on PromptHive’s own MCP path: agents may propose catalogue changes; only a human publishes. An approval queue that nobody staffs looks like a broken integration — staffing the boundary is part of the design. Details and lessons sit in the agents guide.

How developers actually encounter MCP

1. Consumer of connectors (most people)

You open Cursor or Claude Code settings, add a server (marketplace, docs sample, or internal URL), authenticate, and suddenly Agent can see a new tool list.

Good practice:

• Enable one server for a real job, not twelve “just in case.”
• Read the tool list. If a “docs helper” can also delete_everything, remove it.
• Prefer read-only tools until a workflow proves it needs writes.
• Log or watch the first week of invocations like you would a new CI bot.

Workflow articles:

• How to use Claude Code
• How to use Cursor AI

2. Author of an MCP server (platform / internal tools)

You expose a thin, auditable tool surface over systems you already operate:

• internal search,
• feature-flag read,
• ticket create with fixed project IDs,
• “staging only” deploy preview.

Design rules that age well:

• Narrow tools beat god-tools with twenty optional flags.
• Idempotent writes where possible.
• Human-readable errors — models and humans both read them.
• Auth outside the model — OAuth device flows, host secret storage, short-lived tokens.
• Document side effects in the tool description honestly — but remember descriptions are also attack surface; keep them clear, not novel-length.

3. Host implementer (rare for app developers)

If you build an agent product, you are on the hook for consent UI, server lifecycle, sandboxing, and audit logs. The protocol will not save a host that auto-executes every tool call.

Cursor, Claude Code, and the coding stack

Coding hosts are where MCP shows up for many teams first, because the agent is already allowed to touch files and shell — adding issue trackers or browsers feels like a small step. It is not small; it is a new trust domain.

We are not claiming a frozen list of “official MCP logos inside each settings panel.” Vendors ship fast. The durable advice: if the UI says it can call a tool, supervise it like production access.

Compare agent products on capability and price without confusing that with MCP literacy:

• Claude Code vs Cursor
• Cursor vs GitHub Copilot
• Cline vs Claude Code
• OpenAI Codex vs Claude Code
• Best AI coding tools

GitHub Copilot remains primarily an assistant/agent inside Microsoft’s packaging; it is not “the MCP product.” You can be excellent at Copilot and never touch MCP.

When you need MCP

You are in MCP territory if any of these are true:

• You are building an internal connector so several AI hosts can share it.
• You need the agent to reach a system the repo does not contain (ticketing, CRM read, design tokens service, browser).
• You are standardising tool access across Cursor and CLI agents and something else.
• You must audit tool inventory centrally (enterprise allowlists).

When you do not

Skip MCP — for now — if:

• Tab/complete and repo-local Agent already clear your backlog.
• You cannot explain what each tool does to a security reviewer.
• The only “integration” you wanted was better prompts (write CLAUDE.md / Cursor rules instead — see how to use Claude Code).
• You are evaluating AI coding tools on price and editor fit — do that on the coding hub and free-tier guide first: best free AI coding tools.
• You need a non-engineer app demo — Lovable / Replit problems are product-shaped, not protocol-shaped.

Adding MCP early is a common form of architecture cosplay: impressive diagram, empty productivity delta, larger attack surface.

A sane adoption ladder

1. No agent tools — chat and Tab only.
2. Repo + tests only — Claude Code / Cursor Agent on a git branch.
3. Read-only MCP — docs, ticket fetch, schema read.
4. Write tools with approval — create draft PR, draft ticket, staging preview.
5. Automation — only after logs, budgets, and an on-call human exist.

Climb one rung per month of clean operation, not per exciting blog post.

Implementation checklist (operators)

• Named owner for each server in production use
• Credentials stored in host secret storage, not in the prompt
• Least-privilege scopes documented
• Sensitive tools require interactive approval
• Egress and data-handling reviewed for customer PII
• Version pin and upgrade process for server packages
• Kill switch (disable server org-wide) tested once
• Incident path: “model did X via tool Y” is reconstructable from logs

If you cannot tick half of these, you are not ready for write tools.

MCP vs “just use the API from a script”

Sometimes a plain script or CI job is better than an agent with MCP:

Agents shine when the path is not fixed. MCP shines when many hosts should share the same guarded tools. Neither is a virtue by itself.

Worked example: ticket fetch vs ticket create

Read-only. An MCP server that fetches a ticket by ID and returns title, description and acceptance criteria is usually low drama. The agent still sees untrusted text (injection risk), but side effects are limited. Good first connector.

Write. An MCP server that creates or closes tickets, posts comments, or changes assignees is a workflow bot with a natural-language front end. Require approval, scope the bot to one project, and log every call. If your team would not hand a junior a personal admin token, do not hand the model one either.

Wrong use. “Connect everything we have and let the agent figure out the process.” That is how you get silent spam, duplicate tickets, and a security review you will not enjoy. Encode the process in tools and prompts; do not hope the model invents your ITIL policy.

The same gradient applies to browsers, databases and cloud consoles. Start read-only, graduate to approved writes, automate only what you can staff.

The short version

1. MCP connects AI hosts to tool servers over an open protocol.
2. Client in the host, server exposes tools/resources — model proposes, host disposes.
3. Safety is consent, scope, trust, and supervision — not a protocol flag.
4. Cursor and Claude-class coding agents are common hosts; learn git-scoped agents before production connectors.
5. Skip MCP until a real external system must enter the loop.

Where to go next

• Complete AI agents guide — failure arithmetic, human gates
• AI glossary — MCP one-liner and adjacent terms
• How to use Claude Code · How to use Cursor AI
• Complete AI coding guide · Best coding tools
• Claude Code review · Cursor review · Claude Code vs Cursor

For production multi-server setups, secrets and approval gates, continue to the MCP advanced guide.