Coding agents jump from autocomplete to operators when they can open PRs, read CI, query errors, and touch internal platforms. MCP is the standard way those hosts obtain tools and context (intro).
Hosts and official entry points
| Host | Where to start |
|---|---|
| VS Code | MCP servers in VS Code (Microsoft docs) |
| Cursor | Cursor MCP docs |
| Claude (local) | Connect to local MCP servers |
| Claude (remote) | Connect to remote MCP servers |
| Protocol | Architecture, Transports 2025-11-25 |
The official intro also cites VS Code and Cursor among clients with ecosystem support (What is MCP?).
High-value tool groups for engineering
Design small, well-described tools (tools spec):
| Domain | Example tool intents | Notes |
|---|---|---|
| Source control | list PRs, comment, request review | Scope PATs; no force-push by default |
| Issues | triage, label, assign | Rate-limit bulk ops |
| CI | failing jobs, log excerpts | Prefer summaries over raw multi‑MB logs |
| Observability | errors, traces (read) | Mask secrets in outputs |
| Platform | feature flags, deploys | Separate staging vs prod servers |
| Meta-ops | deploy MCP infra via management MCP | e.g. MCPLambda MCP server |
Put stable reference material (API schemas, runbooks) in resources; use prompts for repeatable playbooks (“draft release notes from these commits”) (server concepts).
Local vs remote for coding workflows
| Pattern | Transport (official) | Best for |
|---|---|---|
| Personal filesystem / local scripts | stdio — client launches subprocess | Solo laptop, sensitive local paths |
| Shared GitHub/CI/company APIs | Streamable HTTP remote | Team consistency, always-on agents, CI bots |
Architecture docs: local often stdio; remote often Streamable HTTP (architecture).
Cursor documents remote servers with url (+ optional headers / OAuth) vs local command-based servers (Cursor MCP). Prefer product docs for exact JSON keys — they change.
Context-window reality: progressive discovery
Coding hosts often attach many MCP servers. Official Client best practices warn that loading every tool definition into the model upfront wastes tokens and hurts quality. Patterns:
- Progressive discovery — catalog/search tools; load full schemas only when needed
- Dynamic server management — connect servers when the task needs them
- Programmatic tool calling / code mode — compose multi-step tool use in a sandbox so intermediate payloads don’t flood context
If your org exposes 50+ tools, design servers so hosts can discover progressively (clear names/descriptions, stable grouping by server).
Security for coding agents
Coding tools often hold high privilege (repo write, cloud deploy).
From official MCP guidance:
- Human-in-the-loop for tool invocation (tools)
- Validate inputs, rate-limit, sanitize outputs (tools security)
- No token passthrough; careful OAuth proxy design (security best practices)
- Local one-click install: show full command, consent before execute (local compromise)
- Streamable HTTP: Origin validation + authentication (transports)
Practical org rules
- Staging MCP servers with non-prod credentials first
- No shared “admin GitHub token” in every laptop config — use remote + issued tokens
- Disable destructive tools (delete repo, force push) on shared prod servers
- Audit tool calls weekly
Reference setup (team)
- Deploy remote MCP for org tools (Git/Docker/package or registry install)
- Auth on (authorization)
- Document URL + how engineers obtain tokens
- Each engineer points Cursor / VS Code / Claude at the same remote URL
- Keep personal stdio only for true local-only tools
Onboarding detail: connect remote clients, team-shared remote.
MCPLambda-specific (optional)
- Deploy engineering tools from Git with
mcplambda.yaml - Agents can deploy via Agent guide / MCP control plane
- Watch tool analytics for failing CI/repo tools
Worked scenario: Repo write is not a demo toy
An eng MCP can open PRs and merge. Someone enables it globally with a personal admin PAT. A confused agent opens noisy PRs across repos.
You issue fine-scoped tokens, separate staging vs prod MCP servers, disable merge/force-push tools on the shared prod server, and require human approval for write tools in the host. Remote shared endpoints replace five divergent stdio GitHub configs.
You also stop loading every devops tool into every session—server split + progressive discovery keeps coding agents sharp.
Checklist for this topic
- Scope PATs/apps to least privilege
- Separate staging and prod coding MCP servers
- Disable highly destructive tools on shared prod
- Prefer remote shared URL for org tools
- Human approval for write/merge tools
- Monitor tool error rates on CI/repo tools
Topic-specific failure modes
| Failure | Likely cause | Fix |
|---|---|---|
| Admin PAT everywhere | Convenience | Fine-scoped tokens + remote auth |
| Agent merges to main | Write tools too open | Remove merge tools or require approval |
| Context overload | Too many servers/tools | Progressive discovery |
| Local-only CI MCP | Laptop dependency | Remote always-on server |
Related guides
Connect clients · Agent frameworks · Team-shared remote
In practice: repo tool policy
Default shared coding MCP:
- Allow: read PR, list checks, comment
- Deny by default: merge, delete branch, force-push, secret scan bypass
Write tools can exist on a separate server used only by seniors or CI bots.
Sources
- What is MCP?
- Architecture overview
- Client best practices
- Connect local / remote servers · remote
- Tools — 2025-11-25
- Security Best Practices
- Cursor MCP
- VS Code MCP
- Example / community servers index
