MCP: Extending Agents with Tools

How Model Context Protocol standardizes tool integration — servers, transports, and when it beats writing your own glue.

The integration problem it solves

Before MCP, every agent needed bespoke glue per data source: N agents × M tools connectors. Each integration re-invented discovery, auth, and result formatting.

MCP standardizes the last mile: servers expose tools, resources, and prompts over one protocol; clients consume them uniformly. Tool authors implement once.

Host (agent app) → MCP Client → MCP Server → your data/API

A server can be local (stdio) or remote (HTTP). The client does not care — same protocol either way.

Three things a server exposes

The distinction matters: tools are model-invoked, prompts are user-invoked. Confusing them produces servers where the model triggers workflows the user intended to trigger manually.

Writing good tool definitions

Same discipline as any function-calling schema, with protocol-specific stakes — badly described tools get used across every client that connects.

• Name with a verb: search_repositories, not repo_thing
• One tool, one action. Do not build manage_user(create|update|delete).
• Descriptions carry the whole burden of discovery. State inputs, outputs, and limits.
• Return structured content plus a human-readable text form; some surfaces render only one.

Transports: stdio vs HTTP

stdio — server runs as a subprocess alongside the host. Simple, no network, inherits local permissions. Ideal for local file/system access and single-user dev tooling.

HTTP (streamable) — server is a shared remote service. Needed for multi-user, centralized credentials, and SaaS APIs. Requires real auth (OAuth), rate limiting, and per-user tenant isolation.

Choosing stdio for something that later needs shared credentials forces a rewrite. Decide early.

Security reality check

Connecting an MCP server grants it the permissions of whichever machine it runs on. Treat third-party servers as executable code you are choosing to run — because that is exactly what they are.

• Read the source, or use a vendor you trust
• Scope credentials narrowly; do not hand over a master API key
• Sandbox local servers (restricted FS paths, no blanket network)
• Audit what an unusual server actually sends back before trusting its outputs broadly

When MCP is overkill

If you have exactly one agent and one data source, just write the function. The protocol pays off with reuse across clients or many integrations. Adding MCP to a single-purpose script is ceremony with no return.

Adopt it when any of these hold: the tool should work across multiple agent apps; you maintain several integrations that keep drifting apart; you want others to consume your tool without custom docs.