MCP and Tools for Coding Agents
Tools give an agent capabilities. MCP can standardize how capabilities and context are exposed. Neither removes the need for permissions and verification.
Separate the agent, the tool and the protocol
These terms are easy to collapse into one idea:
- An agent decides what action to attempt next in pursuit of a goal.
- A tool is a capability the host allows the agent to invoke.
- A protocol defines how systems communicate about capabilities and data.
An agent can use tools without MCP, and an application can use MCP without becoming an autonomous coding agent. Keeping the concepts separate makes architecture and security discussions much clearer.
What tools enable
A text-only model can propose a shell command. A tool-enabled agent may be able to execute one and observe the result. Other tools can expose file reads, patches, code search, browser automation, issue trackers, databases or deployment systems.
Every added tool expands both usefulness and blast radius. Read-only repository search is a different capability from arbitrary shell execution; reading an issue is different from closing it; inspecting a database schema is different from modifying production data.
Where MCP fits
The Model Context Protocol (MCP) is an open protocol for connecting AI applications to external systems. In MCP terminology, servers can expose capabilities such as tools, resources and prompts to a client/host environment.
For coding workflows, this can make integrations more reusable: instead of every agent host inventing a bespoke connector for the same service, an MCP-compatible integration can expose a defined interface. That is an interoperability benefit, not a guarantee that the exposed operation is safe or appropriate for a particular task.
Start from permissions, not convenience
Before connecting a capability, ask what the agent actually needs. Prefer the narrowest useful scope: read before write, project before organization, development before production, and explicit approval before irreversible actions.
Credentials should remain in the host or integration layer rather than being pasted into prompts or repository instructions. The model needs permission to request an action; it usually does not need to see the underlying secret.
“The tool supports this action” and “the agent should be allowed to perform this action automatically” are different decisions.
A five-question check before adding a tool
Ask: What new action becomes possible? What data becomes visible? Can the capability write or delete? What approval boundary exists? What evidence will confirm the action succeeded?
If those answers are unclear, adding the integration first and designing controls later reverses the safe order of work.