A protocol for capabilities, not intelligence
Model Context Protocol describes a way for an AI application to discover and use external capabilities. A host connects to a server, inspects the tools and resources it exposes, and decides what to make available to an agent. The protocol does not choose the model, make the model correct, or make a server trustworthy. It solves a narrower integration problem: how to describe a capability and exchange requests and results across a consistent boundary.
For coding, that boundary is useful because useful evidence lives outside source files. A project issue, package documentation, error dashboard or design record may explain a bug. Without a common protocol, each editor or agent would need a bespoke connector for every source. MCP lets a server expose a documented interface while the host presents it to its model-driven workflow.
Tools, resources and prompts serve different jobs
A tool is callable: it accepts arguments and returns a result. It might search an issue tracker, run a database query or create a ticket. A resource provides content for reading, such as documentation or a file. A prompt can supply a reusable interaction template. In practice, servers vary widely, and a single server may expose several kinds of capability. The names are descriptive, not a security rating.
Read each tool signature before approving a server. A function named search may send your query to an external service; a function named fetch may retrieve a private document; a function named update can alter durable data. Parameter schemas help an agent call a tool, but they do not explain every operational consequence. The server implementation and its credentials define what is actually possible.
A coding example from question to answer
Suppose a test fails after an API migration. The agent can inspect local code first, then ask a documentation server for the current method signature. It compares that result with the installed package version and patches the call site. Finally it runs the test and reports the result. MCP contributed a route to documentation; the important engineering work was checking that the returned documentation matched the version in the lockfile.
An external result should be treated as evidence with provenance, not an instruction that overrides the user or repository. Documentation can be outdated, issues can contain malicious text, and server responses can be wrong. The agent should tie its edit to local source and test output. A plausible tool response alone is insufficient justification for a code change.
The server is another trust boundary
An MCP server can run locally, be reached over a network, or proxy another account. Its location and authorization matter. A local server with a cloud API credential still sends data to that cloud. A remote server can receive query text and return content that enters a model prompt. Before connecting it, identify the operator, the data it sees, its logging policy and the scope of its credentials.
Least privilege is practical here. Give an issue lookup server read access if all the agent needs is context. Keep production write credentials out of exploratory sessions. If a tool changes an external system, make its proposed arguments visible for human review. Removing a server from the host later does not undo an earlier write or disclosure, so permission decisions belong at the time of use.
Host approval is part of the design
The host decides which servers to expose and how to present tool calls. One product may prompt before each call; another may allow a class of calls automatically. The protocol itself does not enforce a universal approval policy. Review the actual behavior in the client you use: does it show the command, parameters and destination? Can you reject a call and continue? Are read and write operations distinguished?
A broad permission can be convenient during a low-risk personal project, yet dangerous in a shared organization. A server that sees repository text might also see a secret if the agent passes the wrong file. The safest setup combines narrowly scoped credentials, a sensible host policy and ordinary human review of consequential actions.
MCP and other agent interfaces
MCP is often confused with agent-to-editor protocols. ACP addresses how an external coding agent communicates with an editor client. MCP addresses how an AI application connects to tools or data. The same external agent can be hosted in an editor through ACP and use MCP servers internally. Neither relationship implies that the editor's privacy controls govern all connected services.
When evaluating a coding setup, draw the data path: editor, agent runtime, model provider, MCP servers and external accounts. Mark where prompts, code excerpts and tool results travel. That map is more useful than saying the workflow is simply local or cloud. A local workspace can still send selected content to a model and a connected tool.
When to add a server
Add an MCP server when it supplies evidence or an action that materially improves a real task. Start with a narrow read-only use case, run a representative query and inspect the returned data. Confirm the agent can cite the result and still validate its conclusion against the repository. Do not install ten servers because they are available; every additional capability expands configuration and potential data flow.
For high-impact tools, test failure paths as well as the happy path. What happens when authentication expires, the server returns a partial answer or the target API rate-limits a call? The agent should explain uncertainty and stop before guessing at a destructive retry. MCP makes integrations portable, but responsible use still depends on the client, server and operator.
MCP standardizes access to capabilities; the host and user still own permission decisions.
Sources & further reading
References support the concepts and product descriptions discussed above. Features, prices and account eligibility can change; check the live documentation. Inclusion here is not a hands-on test or vendor endorsement.