Using MCP and coding agents without losing control

MCP is one of those ideas that sounds boring until it quietly changes how work gets done.

A coding agent with only file access is useful. It can edit code, run tests, and occasionally invent a helper named HelperManager because nobody was there to stop it.

A coding agent with MCP can inspect issues, read design docs, query logs, check feature flags, look at observability data, and talk to internal tools through a standard interface.

That is powerful.

It is also how a normal development workflow loses control if nobody writes down the rules.

The mistake is treating MCP as a magic backpack for agents. “Give it access to everything” is not a strategy. It is a compliance incident wearing a hoodie.

1. Start with the job, not the server list

The bad MCP setup starts with tool shopping.

Someone finds a GitHub server, a Linear server, a database server, a browser server, a Slack server, and three experimental things from a README with suspicious enthusiasm. Then they wire all of it into the agent and call the result “context.”

That is not context.

That is a junk drawer with OAuth.

Start with the actual jobs you want agents to perform:

1. Fix a small bug from an issue.
2. Update docs after a code change.
3. Investigate a failing test.
4. Prepare a safe refactor.
5. Draft a pull request summary.
6. Check whether a production error matches a known regression.

Each job needs a different tool shape. The bug fixer may need GitHub issues, source files, and tests. It probably does not need production customer data. The docs updater needs the docs repo and maybe the public API schema. It does not need deployment credentials.

This sounds obvious because it is. Most tool sprawl happens when teams configure capabilities before defining tasks.

Agents do not need more tools by default. They need the right tools for the current job.

2. Treat every MCP tool as a permission boundary

MCP makes tools feel clean because the interface is clean.

Do not let the protocol aesthetics fool you. A tool that can read private tickets is a permission boundary. A tool that can write to a repository is a permission boundary. A tool that can query logs is a permission boundary, especially when those logs contain the delightful little secrets production systems always manage to leak.

Use boring security rules:

1. Prefer read-only tools unless the job truly needs writes.
2. Scope tools to one repo, project, environment, or account where possible.
3. Separate local development tools from production tools.
4. Require explicit human approval for destructive actions.
5. Keep secrets out of prompts and tool responses.
6. Log tool calls in a place humans can audit.

The agent should not be able to discover its way into power. It should receive a narrow capability and use it for a narrow task.

If a human engineer would need elevated access to do something, the agent should not get that access just because the UI has a friendly chat box.

3. Write tool instructions like API contracts

Most teams write agent instructions like vibes:

Use the tools carefully and follow best practices.

This is charming. It also means nothing.

A useful MCP instruction is closer to an API contract. It tells the agent when to use the tool, what the inputs mean, what not to do, and how to verify the result.

For example:

Use the GitHub issue tool only to read the assigned issue and linked comments.
Do not close issues, change labels, or edit descriptions.
If the issue references a design doc, summarize the relevant requirement before editing code.

That instruction does three useful things. It scopes the tool. It forbids tempting writes. It forces the agent to pull requirements into the work before touching code.

Do this for each tool that matters.

The goal is not to write a constitution for your robots. The goal is to remove ambiguity where ambiguity becomes expensive.

4. Keep tool output small enough to review

Agents love context the way build systems love cache directories: more is always presented as better until everything becomes slow, stale, and mildly cursed.

MCP servers should return focused output. Not entire databases. Not every comment on every linked ticket since the founding of the company. Not a 40,000-line log dump because somebody asked for “recent errors.”

Good tool output is:

1. Small enough to read.
2. Structured enough to cite.
3. Recent enough to trust.
4. Explicit about what was omitted.

If a tool returns search results, include titles, IDs, timestamps, and stable links. If it returns logs, include the time window and filter. If it summarizes docs, include the source path and revision.

The agent should be able to say:

I changed this because MOBILE-1842 says password reset must preserve the email field after a failed submit.

That is reviewable.

“The internal docs suggest…” is not reviewable. That is how folklore enters the codebase with a confident commit message.

5. Separate investigation tools from action tools

A good agent workflow has phases.

First it investigates. Then it proposes. Then it edits. Then it verifies.

Do not give every phase the same tools.

During investigation, read access is usually enough. The agent can inspect issues, docs, code, logs, schemas, and previous PRs. During implementation, it needs file edits and test execution. During publishing or deployment, it may need a much stricter path, often with human approval.

This prevents a common failure mode: the agent sees something, decides it understands the problem, and immediately changes the world.

That is not autonomy. That is a raccoon with admin rights.

A practical setup:

1. Investigation profile: broad read access, no writes.
2. Coding profile: repo write access, test commands, limited external reads.
3. Release profile: narrow deploy tools, explicit approval gates.
4. Incident profile: read-heavy observability, no production mutation unless a human takes over.

Profiles do not need to be fancy. They just need to stop one casual prompt from becoming a cross-system adventure.

6. Make verification part of the tool loop

MCP is not only for fetching context. It should also help prove the work is done.

If an agent reads an issue through MCP, it should reference the acceptance criteria in the final summary. If it edits code, it should run the relevant tests. If it changes an API contract, it should check the generated schema or docs. If it claims a bug matches a production trace, it should include the log query and time window.

The review question is simple:

What did the agent verify with tools, and what is still just its opinion?

Keep those separate.

A model saying “this should fix it” is not evidence. A failing test that now passes is evidence. A build that completed is evidence. A log query showing no new errors after deploy may be evidence, depending on the window.

Agents are useful when they compress the loop between hypothesis and verification.

They are dangerous when they compress the loop between guess and merge.

7. Version your MCP setup like production code

Tool configuration should live where the team can review it.

If agents rely on MCP servers, prompts, tool descriptions, allowlists, and approval rules, those things are part of the development environment. Treat them like code:

1. Put shared instructions in the repo.
2. Review changes to tool permissions.
3. Pin server versions where possible.
4. Document required environment variables without exposing values.
5. Keep local-only tools out of shared config unless the whole team has them.
6. Remove tools nobody uses.

Stale tools are worse than missing tools because the agent will still try to use them. Then someone spends twenty minutes debugging the robot’s relationship with a server nobody remembered installing.

This is not a philosophical problem. It is maintenance.

8. The sane default: fewer tools, sharper loops

The best MCP setup I have seen is not the one with the most servers.

It is the one where the agent can answer three questions reliably:

1. What is the task?
2. What context is authoritative?
3. What proof shows the change worked?

Everything else is decoration until it earns its place.

Start small. Give the agent access to the issue tracker, the repo, and the test runner. Add docs when the docs are actually useful. Add observability when the workflow needs production diagnosis. Add write tools slowly, with logs and approval gates.

MCP can make coding agents feel less like autocomplete and more like actual coworkers with access to the building.

Fine. Give them a badge.

Do not give them every key on day one.