Most discussions about agentic development revolve around models. The practically harder question is a different one: what may the agent access – and who decides that? Without an answer you get either an assistant that knows too little to help, or a process in which a tool is allowed more than most employees.

1. What MCP is – and is not

The Model Context Protocol (MCP) is an open protocol describing how an AI application talks to external systems: data sources, tools, services. It was published by Anthropic and is maintained as an open specification; its messages follow JSON-RPC 2.0.

The benefit is initially very unspectacular: standardisation. Without such a protocol, every combination of AI tool and system gets its own integration – and with it its own permission handling, its own failure modes and its own maintenance. With MCP a system describes its capabilities once, and different clients can use them.

Equally important is what MCP is not:

Not a security model for your systems. The protocol governs the communication, not the question of which permissions an access should carry. That decision stays with you.
No guarantee of sensible behaviour. An agent can call an offered capability wrongly, too early or in the wrong context.
No substitute for an API. An MCP server is usually an additional facade in front of an existing interface, tailored for agents – not a replacement for it.

In short

MCP solves the integration problem. It does not solve the permission problem – it merely makes it visible at last, and therefore decidable.

2. Tools, resources, prompts

An MCP server offers its capabilities in clearly separated categories. The distinction looks formal but decides who triggers an action – which makes it the most important part of the protocol for architecture:

The server primitives of the Model Context Protocol
Primitive	Who triggers it	Typical use
Tools	the model, within the client’s approval	actions with effects: create a record, change a model, trigger a build
Resources	the application or the user	context to read: schemas, configuration, documentation, project definition
Prompts	the user, usually selected explicitly	prepared workflows, such as “derive a model from a requirement”

The practical consequence: whatever only needs reading does not belong in a tool. A schema provided as a resource is context. The same schema behind a tool is an action the model can trigger by itself – with everything that implies in terms of review and logging.

The protocol also defines client-side capabilities, among them the ability to tell the server about a limited workspace and to relay server requests back to the model or the user. Which of these a specific client supports differs – something to settle early when designing a server.

3. Host, client, server: how the roles divide

The architecture is deliberately simple:

Host – the AI application you work in: a coding environment, an editor plugin, a terminal agent.
Client – contained in the host, holds one connection to exactly one server and manages its state.
Server – exposes a system's capabilities: repository, ticket system, database, development platform.

The host's position matters most for security. It is the only party that sees all connections at once, and therefore the only one that can meaningfully ask for approval. A server does not know which other servers are in play – and must not assume it does.

4. Transport and operating model

Two transports are common: a local process connected over standard input and output, and an HTTP-based connection for remote servers. The difference is not a matter of taste; it determines the entire permission model:

Local: the server runs as a process under the account of the person who starts it – and inherits their permissions, including the file system and locally stored credentials. Convenient, but rarely finely graded.
Remote: access runs over an authenticated connection. For this case the specification describes an OAuth-based authorisation model, which cleanly separates identity, scope and revocation.

For organisations with their own infrastructure the second route is usually the only viable one – not because of the protocol but because only there does traceable permission assignment become possible. The protocol keeps evolving and is versioned by date; which version applies to your tool chain belongs in your decision documentation.

5. Permission boundaries: the real design work

The most common design error is giving an MCP server the same permissions as an administrator – “so that it works”. That turns the tool into a way around your own authorisation model.

A solid scoping answers four questions:

On whose behalf does the server act? A technical shared account makes any later attribution impossible. Better an identity that traces back to the acting person.
Which slice is reachable? One project, one tenant, one repository – not “everything the service can do”.
Which actions write? Reading and writing belong apart. Much of the benefit already comes from read-only mode.
What is irreversible? Deleting, deploying, approving, granting permissions: such actions belong either out of the tool list entirely or behind an explicit human approval.

A proven rule of thumb: the agent gets the permissions of a new team member on day one – enough to work, without access to production, secrets and permission administration. How that translates into a company-wide policy is described in the deep dive AI coding governance.

6. MCP in the development workflow

The benefit becomes concrete where an agent works against defined platform capabilities instead of an empty file. A typical flow in backend development:

The AI coding tool produces frontend code against a known interface.
Through the MCP server, data models, relations, roles and permissions plus validation rules are defined – not as a text file but as an explicit model.
The result is reviewed visually and corrected where the domain decision belongs to a person.
From the reviewed project definition come the build, container image and deployment through your own CI/CD.
The generated OpenAPI documentation closes the loop: it is precise integration context for the frontend and the AI tools alike.

The difference from “the agent writes backend code” is fundamental. What is created through defined capabilities stays reviewable, comparable and repeatable. How CodamAI implements this flow is on the features page.

7. Where overly broad rights tip over

The relevant risks of agentic tool chains rarely come from a single mistake but from an unfortunate combination. Every team should know three patterns:

Indirect prompt injection

Anything an agent reads – ticket descriptions, code comments, error messages, web pages, tool results – can contain instructions. Models do not reliably tell content from instruction. Tool results are therefore data, not commands, and their trustworthiness depends on the source.

The dangerous combination

It becomes critical when three properties come together: access to confidential data, processing of untrusted content and the ability to communicate outwards (network access, pull request, message, commit into another repository). If one of the three is missing, the damage stays limited. That is exactly what tool scoping should aim at.

Mutable tool descriptions

A server can change its tool list and their descriptions after a user has approved it once. Hence: obtain servers from a trustworthy source, pin versions and treat changes to the tool list like a dependency change – review and approve them.

8. Placing the human in the loop correctly

Approvals only work as long as they are read. A client that asks on every read teaches users reflexive confirmation within a morning – and thereby devalues exactly the prompt that matters.

A sensibly staged practice:

Reading within the approved scope: without asking.
Writing, reversible: a single approval per session or tool, with a visible log.
Irreversible or outward-facing: confirm individually every time – showing the concrete parameters, not just the tool name.
Permission and production changes: do not offer them as tools at all.

An approval does not replace reviewing the result. What an agent produces through MCP goes through the same quality gates and reviews as hand-written code.

9. An example architecture

The following pattern has proven itself for teams introducing agentic development in a controlled way. It is an illustration, not a product configuration:

1 Workstation: a host with a coding agent, connected to a few deliberately chosen servers – not to everything available.
2 Platform server (write access, per project): models, relations, roles, validation rules – limited to one project and a non-production environment.
3 Context server (read only): requirements, architecture decisions, API contracts, coding rules – as resources, not as tools.
4 No production connection. Deployment runs through the CI/CD pipeline with its own approvals – never through agent credentials.
5 Server-side logging: who called which tool with which parameters and when – analysable, not just in the client’s session history.

The matching client configuration stays deliberately narrow. What matters is the limited scope and credentials coming from the environment rather than from the file:

{
  "mcpServers": {
    "project-platform": {
      "command": "<server-binary>",
      "args": ["--project", "erp-2026", "--env", "staging"],
      "env": { "PLATFORM_TOKEN": "${PLATFORM_TOKEN}" }
    },
    "project-context": {
      "command": "<server-binary>",
      "args": ["--repo", "erp-2026", "--read-only"]
    }
  }
}

Structure and available options differ by client and server; the example shows the principle, not a specific interface.

10. Trade-offs and limits

Context cost. Every tool on offer takes space in the context and raises the chance of a wrong selection. Twelve precise tools beat sixty generic ones.
Additional operational surface. An MCP server is software that has to be run, updated and monitored – including dependency upkeep.
Non-determinism remains. The protocol makes calls traceable, not predictable. Repeatability only comes from the reviewed artefact.
Client maturity. Not every client supports every capability or approval model. Test that before rolling out, not afterwards.

Common mistakes

An administrative shared account for the server, because it is quicker.
Offering everything as a tool, including pure read operations.
Connecting servers from an unknown source without pinning versions.
Training approval dialogs instead of designing them – too many prompts produce blind confirmation.
Production access through the agent instead of through the pipeline.
No server-side logging, and therefore no ability to answer later.

Checklist: introducing MCP under control

Every server has a named purpose and a limited scope – project, tenant, environment.
Reading and writing are separated; pure context data is exposed as resources, not as tools.
Access is tied to a person and revocable – no technical shared account.
Irreversible and outward-facing actions are excluded or approved individually.
Tool results count as data, not as instructions; the source determines the trust.
Servers are pinned and from a known source; changes to the tool list are reviewed.
Calls are logged server-side and stay analysable – also after the session ends.
The result goes through the regular checks: review, tests, quality gates, approval.

Conclusion

MCP is not an acceleration technology but a structural decision. It replaces the question “how do I connect my system to the AI tool?” with a much better one: “which capabilities do I want to give an agent explicitly – and which not?”

Teams that answer that question cleanly get an agent that works with the right information and whose actions stay traceable. Teams that skip it get an access path nobody can fully describe any more. The effort for the difference is a few days of design work – the difference itself is substantial.

MCP in software development: controlled access for AI agents