Vibe Coding for Production
Model Context Protocol (MCP)

What is MCP?

The Model Context Protocol connects Claude and other clients to your tools, data, and systems through small servers, not one-off custom glue per integration.

MCP (Model Context Protocol) is an open standard for how an AI client (for example Claude Code, Claude Desktop, or other hosts) talks to external capabilities: databases, ticket systems, internal HTTP APIs, Git hosting, files on disk, and more.

Instead of every product inventing its own plugin wire format, MCP defines a shared shape: the host discovers tools (things the model can call), resources (things the model can read or attach), and sometimes prompts (reusable templates). A server implements one domain (for example "our CRM"). The host creates multiple MCP clients, with each client maintaining a one-to-one connection to one server.

Why it matters for coding agents

  • Live data: The model can query current issues, schema, or metrics, not only what was pasted into chat.
  • Controlled access: You choose which servers run, which tools are allowed, and often which accounts or tokens they use.
  • Reuse: The same MCP server can serve multiple clients that speak MCP, not only one vendor's extension format.

In Claude Code, MCP shows up as extra tools in the tool list and as @ resources you can attach (see References with @). Managing connections is typically done through /mcp (or your host's equivalent).

Mental model: host, client, server, capability

PieceRole
HostClaude Code (or another app) manages the UX, calls the model, and creates MCP clients.
MCP clientOne protocol connection inside the host that communicates with one MCP server.
MCP serverA small process or service that knows how to talk to one backend (Postgres, Jira, your REST API).
ToolA named action the model can request, with parameters (for example search_issues, run_query).
ResourceA readable URI-like thing (often protocol://path) you can @-mention so its data is fetched into model context. Access control and sensitive-data handling remain the host and server’s responsibility.

The model does not magically get unlimited access: it only gets what the server exposes and what you approved in the host.

Concrete examples

1. Git / code hosting An MCP server might expose tools like "get file from repo", "open pull request", or "list issues". The model can ground answers in real branches and diffs instead of guessing.

2. Database or data warehouse Tools such as "run read-only SQL" (with strict limits) let the model explore schema and sample rows for debugging or migration planning, often safer than pasting full dumps into context.

3. Internal HTTP API Your company wraps a documented internal API: tools like fetch_customer or create_ticket map to HTTP calls with your auth. The model uses structured arguments instead of inventing URLs.

4. Filesystem or docs root A server exposes resources under a base path so @ can pull runbooks, OpenAPI specs, or architecture markdown from a known tree.

5. Productivity / ticketing Tools to search Slack-like messages (where supported), create Jira issues, or update Linear, useful for "file a bug from this stack trace" workflows.

Each example is one server (or one product's server package); you enable what you trust.

MCP vs a random script or curl

One-off scriptMCP server
DiscoveryYou paste instructions every sessionHost lists tools and schemas for the model
SafetyWhatever the script doesNarrow tool surface; host can gate invocations
ReuseCopy-paste between projectsSame server across repos and teammates

MCP is not a replacement for good permissions in the agent host: combine it with Permissions and Secure execution habits.

See also

On this page