The Model Context Protocol (MCP) is an open protocol for connecting AI applications to external context and capabilities. For a coding agent, an MCP server might expose repository data, issue trackers, documentation, databases, or narrow operational tools through one shared protocol.
MCP standardizes the connection. It does not make a tool safe, authorize an action, or remove the need to implement the underlying integration.
The architecture
The current MCP specification uses a host-client-server architecture built on JSON-RPC:
- The host is the AI application. It coordinates model access, user consent, authorization decisions, context aggregation, and client lifecycle.
- A client is created by the host and communicates with exactly one server. The separation helps preserve boundaries between servers.
- A server exposes focused capabilities. It may run locally or remotely.
Servers can expose three primary kinds of surface:
- Resources provide context the application can read.
- Prompts provide reusable interaction templates.
- Tools are callable operations with described inputs.
Clients and servers declare supported capabilities. Discovery tells the host what is available; it does not grant blanket permission to invoke it.
Why it helps a coding agent
Without a protocol, every connection needs a custom discovery format, transport, schema, and lifecycle. MCP gives hosts a common way to discover and call capabilities while leaving domain behavior inside the server.
A coding host could connect separate servers for:
- read-only repository search;
- issue and pull-request context;
- build or test execution;
- database schema inspection; and
- deployment status.
The host remains responsible for deciding which server receives which context. A focused server should not receive the whole conversation merely because it provides one tool.
Tool contracts are not policy
An MCP tool definition describes a name, purpose, and input schema. That improves discoverability and validation, but it is not a complete security model.
Before exposing a mutating tool, define:
- who may invoke it;
- which repositories, tenants, paths, or environments it may affect;
- whether each call requires human approval;
- what credentials the server receives;
- what the audit log records; and
- how retries and duplicate requests are handled.
Prefer narrow tools over shell-shaped escape hatches. run_tests scoped to a checked-out workspace is easier to reason about than unrestricted command execution. Read operations and write operations should be distinguishable in both naming and authorization.
Treat tool descriptions and returned content as untrusted input. A repository file, issue body, or remote document can contain instructions aimed at the model. The host must keep those instructions subordinate to its own policy.
Local and remote servers
A local server can use standard input/output and operate near a developer's files. A remote server can use the protocol's supported HTTP transport and authorization flow. Deployment choices such as containers, service discovery, or message queues are infrastructure decisions, not requirements of MCP.
Remote access adds ordinary web-security concerns: token handling, redirect validation, audience restriction, least privilege, rate limits, and server-side authorization on every request. The host should show the user which server will act and what data or action is involved.
A practical adoption sequence
Start with one read-only server and a small capability set. Record discovery results and calls. Add schema validation, timeouts, output-size limits, and explicit errors. Evaluate whether the protocol actually reduces integration work before adding more servers.
Introduce writes only after approvals and auditability are working. MCP makes capabilities composable; the host must keep that composition bounded.