MCP & tool configuration for coding agents

Most MCP servers are prototypes with permissive defaults: fine for a demo, dangerous once an agent can read your filesystem. The failure modes are concrete — silent data exfiltration, an agent running rm -rf somewhere it shouldn't, or API keys ending up in someone's training data. You don't need a SIEM or a threat-model document. Five protections cover solo scale and take about 30 minutes:

• Sandbox untrusted servers. If you can't read every line of a server, it doesn't get host access. Run it in Docker (or a VM/LXC). A baseline is docker run --rm --network=none --read-only --tmpfs /tmp -v $(pwd)/sandbox:/data <server>. Turn off networking for anything that doesn't legitimately need it; allowlist specific hosts for the ones that do.
• Use a tool allowlist, not a denylist. Agents default to "call anything." List the tools you've actually vetted by name, and add a new server's tools one at a time — never a whole namespace via wildcard.
• Move secrets out of the env your agent can see. If the agent has shell access it can read .env. Fetch secrets at runtime from a secret manager (export TOKEN="$(op read ...)") so nothing sensitive lives in the repo or the environment file.
• Log every tool call locally. tee MCP output to a timestamped file. When a run feels off, you grep the log; when it is off, you have evidence of what triggered it.
• Keep a kill switch. One alias that pkills every agent and stops MCP containers, for when a prompt injection from a web page sends an agent off the rails.

The full setup takes about 30 minutes; maintaining it costs roughly a minute per new tool. Skip the enterprise-flavored advice — the right question at solo scale is "what would I regret skipping?"

MCP solved capability and created a supply-chain problem. When a citation-verification server, a curated DevOps/SRE list, and an AI gateway for provider fallbacks all show up at once, the base model stops being the whole workflow — and every new server is code you're trusting with tool access. Two habits help.

First, separate trusted tools from experiments, explicitly. Keep a short list of servers you've vetted (ideally pulled from a curated or official catalog) apart from the ones you're just trying out, and don't let an experiment quietly inherit the same permissions as a proven tool. A new server on your machine is a new thing that can edit files, call APIs, or spend budget.

Second, treat verification as a workflow primitive, not an afterthought. Before a server's output becomes part of your work, you want to see what server was invoked, what evidence it returned, and whether a deterministic check passed — not just a confident chat message. The agent's confidence is not evidence. This matters most where verification sits near execution: if a server can edit files, call APIs, or cite sources, the check has to happen before that output lands.

Routing records matter for the same reason. Provider changes affect quality, cost, and risk, so a later review should be able to see which model did the planning, which did the edit, and which verified the result. That compact trail of decisions — which server ran, what it returned, which check passed — is what lets AI-assisted work survive a handoff instead of being reconstructed from memory.

This shows up in every editor's issue tracker: the integrated terminal's PATH differs from your normal terminal, aliases are missing, nvm use fails. It isn't a bug — it's which kind of shell the editor spawns. A shell is one of three types:

1. Login shell — runs ~/.zprofile then ~/.zshrc (Terminal.app, most SSH sessions).
2. Interactive non-login shell — runs only ~/.zshrc (tmux panes, most editor terminals).
3. Non-interactive shell — runs neither (scripts, task runners).

If your nvm/pyenv/rbenv or PATH setup lives in .zprofile, an editor terminal that spawns interactive-non-login never loads it — so you see missing aliases and "command not found."

The quick fix is to force login mode. In Cursor/VS Code settings, add a profile with "args": ["-l"] and make it the default; for JetBrains set the shell path to /bin/zsh -l; for tmux, set -g default-command "${SHELL} -l".

The durable fix is putting setup in the right file: environment variables that need to exist everywhere in .zshenv, once-per-login setup in .zprofile, and everything interactive (aliases, nvm/pyenv init) in .zshrc — which every interactive shell loads regardless of login status. Verify with echo $PATH; type nvm in both Terminal.app and the editor terminal; the output should match.

This matters for agents specifically. Claude Code, Codex CLI, and Aider inherit the editor terminal's environment. Wrong PATH means the agent runs the wrong node; a missing direnv/env load means the wrong DATABASE_URL. You get bugs that look like AI hallucinations but are really environment mismatches — an agent making correct decisions from incorrect context.

The complaint is specific: Claude Code reads CLAUDE.md, Cursor reads .cursorrules, Copilot reads .github/copilot-instructions.md, others read AGENTS.md. Team instructions drift across Claude, Cursor, Copilot, Windsurf, Cline, and Gemini until no two tools carry the same rules. One developer built a sync tool (Nymor) specifically because agent rule files fragment this way and teams want one canonical source.

It's the same problem teams hit moving from single-user AI experiments to shared workflows: agent rules, MCP servers, prompts, and skills all have to line up across the team, or every person re-derives the setup from scratch. The durable pattern isn't picking one tool — it's keeping the rules, routing, and setup in one place and projecting them into each tool's expected file, so a change happens once instead of six times.

Two things make this worth doing early rather than late. Drift is silent: these files are read by tools, not humans, so a section that quietly disappeared two months ago produces wrong agent behavior with no error to catch it. And retrofitting costs more: once the setup has scattered — config in different files, context in dead chats, the "real" rules living only on one person's machine — you're reconstructing the workflow instead of improving it. Build the shared layer up front and a new developer starts from a known setup instead of reverse-engineering the last twenty prompts.

CLAUDE.md files drift for four reasons: they're read by tools not humans (so breakage is invisible), they aren't quite "code" (reviewers skim them), they aren't quite "docs" (doc review doesn't apply), and they're template-like (people delete sections they don't understand). The drift is rarely a deletion you notice — it's the security section that quietly vanished during an unrelated change two months ago.

The fix is the same as for any team-wide standard: a CI check. Enforce only cross-repo policy — security ("never commit secrets"), forbidden actions ("no --no-verify", "no force-push to main"), branch/PR rules, the list of authorized AI agents — and leave repo-specific sections (architecture, test commands) alone. The minimal version is a bash script that greps for required section headers and required phrases and exits non-zero if any are missing, wired into a GitHub Action on pull_request.

For 10+ repos, don't copy the script everywhere. Keep the required list in one central policy repo and have each repo's CI curl it and compare — updating policy becomes a single PR that every repo picks up on its next run. Some teams prefer auto-fix (append missing boilerplate) over fail-on-missing; that works for identical boilerplate but not for sections needing repo-specific content, so fail-on-missing is the better default.

This matters more for AI than for humans. An assistant reads the file cover-to-cover and treats every line as authoritative, so a missing "no --no-verify" line means it will happily bypass your pre-commit hooks. A 30-line script in CI is the cheapest team-wide AI policy enforcement you can buy.

Once you move past generic code generation, MCP setup gets domain-specific fast. A real example from the threads: making Claude useful for Power BI work through MCP — prompts, Skills files, semantic-model cleanup, DAX, and measure creation. But the setup is only half the job; the other half is trusting the result.

Domain work multiplies the action surface: shell commands, package installs, migrations, file deletes, network calls, generated credentials, and test runners that can mutate local state. A chat transcript can't be the control plane for that. Three things make a domain MCP setup usable.

Context has to be searchable, not just present. A big repo is full of old experiments, generated files, and stale docs; giving the agent file access isn't the same as giving it useful context. The workflow should show which folder, file, or prior decision is actually in play, so the agent doesn't spend budget rediscovering what you already know.

Guardrails belong around actions. Distinguish read-only inspection from destructive commands, make approval decisions visible, and let a project declare which tools are allowed and which steps need a human. The point isn't to slow the agent down; it's to stop confusing speed with permission.

Runtime proof beats a polished explanation. Logs, command output, test results, and a link between the final diff and the run that produced it. Without that trail, review turns into archaeology — and false progress (an agent looping the same search, or claiming a test passed without showing the command) stays hidden. The pattern generalizes past Power BI: any domain server you add needs searchable context, action guardrails, and an evidence trail before you can trust its output.

AI coding has spread from one assistant into a messy toolchain: Claude Code plugins with hooks/MCP/skills, Cursor users tracking whether specific Anthropic models are even available in their IDE, and a broader shift from cloud/model-locked agents toward bring-your-own and local models. Routing everything through the strongest model makes cost unpredictable and feedback slow; routing everything through the cheapest pushes quality failures downstream into debugging.

The practical answer isn't a universal model choice — it's deciding, per task, which one deserves expensive reasoning and where proof of completion has to appear. Two realities make this a config problem rather than a taste problem.

Model switching alone doesn't fix bad execution. A cheap model repeating the wrong tool calls is still expensive; a strong model working from stale context still wastes time. You need to see where tokens, time, and retries are going before you can decide whether the model, the prompt, or the workflow is the bottleneck.

Provider churn shouldn't rewrite your setup. Speed changes, billing changes, and quota 429s all push from different angles, and none is solved by loyalty to one provider. You want a layer above the provider that remembers the project rules and lets you swap engines without changing the whole operating model.

Visible routing also makes model comparisons less theatrical. If you can see which model planned, which edited, and which verified — plus what each one cost — you judge a workflow by operational quality instead of by one impressive answer.