MCP for coding agents across an engineering org

An engineer hands Claude Code a Jira ticket at 4:40 PM and goes to a meeting. When she returns, the agent has read the ticket and pulled the Sentry stack trace. It has checked the PagerDuty incident, changed three files and pushed a branch. It has posted in the team's Slack channel. That took dozens of tool calls, and nobody read any of them as they ran.

That run is what MCP for coding agents has to be designed around. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. A chat assistant answers a person who reads every reply. A coding agent works a task, and the person reads the result.

What makes a coding agent different from a chat assistant?

Four things: it takes many steps per task, it acts without a person approving each call, it runs on the engineer's machine, and the engineer wires it up in a config file. Each one moves the control away from the person in the chat.

Both clients let engineers turn approval prompts down. Claude Code's auto mode "runs without routine prompts", with a background classifier checking actions instead. Its bypassPermissions mode skips prompts, and the docs say to use it only "in isolated environments like containers or VMs" (Claude Code permissions, checked October 2026). A scripted claude -p run "shows no workspace trust dialog and no per-server approval prompt" (Claude Code headless docs).

Cursor "asks for approval before using MCP tools by default". Its Run Modes can let approved tools "run immediately" and send everything else to a classifier (Cursor's MCP docs, checked October 2026).

None of that is a flaw. Speed is the reason teams use coding agents. It does mean the approval prompt is a convenience the engineer controls. The rules that matter have to sit where the call lands.

What goes wrong when each engineer wires up their own MCP servers?

Four problems arrive together: server sprawl, secrets in dotfiles, slow offboarding and no shared record. They grow with headcount, not with usage.

Sprawl comes from the config model. Claude Code stores a server at local, project or user scope, in ~/.claude.json or a project's .mcp.json (Claude Code MCP docs, checked October 2026). Cursor reads .cursor/mcp.json or ~/.cursor/mcp.json. Forty engineers end up with forty different sets of servers, and nobody holds the list.

Secrets follow the same path. Claude Code's own example adds a server with --header "Authorization: Bearer YOUR_GITHUB_PAT", and .mcp.json can expand ${API_KEY} from the environment. Cursor interpolates ${env:MY_SERVICE_TOKEN} the same way. The token then lives in a shell profile or an .env file. A personal token usually carries everything its owner can do in that app, and the agent inherits all of it.

Offboarding becomes a hunt. Each token is revoked app by app, and only if someone knows it exists. The record is split too. Each app logs the call against the engineer's token, and a call on a personal token looks the same as the engineer's own.

How should MCP for coding agents work without shared API keys?

Through one organization-wide endpoint that each engineer signs in to with OAuth (a sign-in that issues a revocable grant instead of a copied secret). Elaichi serves every connected account at https://api.elaichi.ai/mcp. Claude, ChatGPT, Cursor, any MCP client, and the Elaichi Agent use that same address.

The config entry holds a URL and nothing else. Claude Code "supports OAuth 2.0 for secure connections", runs the sign-in in the browser from /mcp, and stores tokens securely and refreshes them. Cursor supports OAuth for servers that require it. Both register themselves with Elaichi through dynamic client registration, so nobody types a client ID or a secret. A project .mcp.json holding only the address is safe to commit.

Each SaaS account is connected once, in Elaichi, not on a laptop. A separate credential service holds the account secrets in the organization's region, encrypted at rest, and owns refresh. An engineer's grant issues access tokens that last an hour and refresh tokens that rotate on every use.

The step-by-step setup is in connecting Cursor for a whole team and in the Claude Code setup guide. For why a grant beats a pasted key, read OAuth or API keys for AI agents.

How do you give engineers AI access to Jira and PagerDuty with the right permissions?

Give engineers one role, share them a toolbox instead of the connections, and restrict the destructive tools on that role. The consent screen then holds back deletes on each engineer's grant.

The role carries tool:execute, which gates the whole endpoint. Each member holds exactly one role, so it has to be complete. A member sees only what they own or what was shared with them, and no admin role widens that view. Restrictions decide which connectors and which individual tools a target may reach. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything.

Start with the tools whose damage is hard to undo:

• delete_a_jira_issue_by_id, which can take an issue's subtasks with it when deleteSubtasks is true.
• delete_a_pagerduty_service_by_id. Its description says that once deleted, "new incidents cannot be created for it".
• delete_a_pagerduty_event_orchestrations_integration_by_id, which removes a routing key, "stopping all future events sent with that key".
• sentry_organization_issues_bulk_delete. If no issue IDs are passed, "the first 1000 matching issues are removed".

A restricted tool is invisible. It never appears in the agent's search, so an agent chasing a bad idea finds nothing to call. A rule takes about two minutes to apply, so wait before you test it.

The grant adds a second lock. On Elaichi's consent screen, "Delete data and remove access" is never ticked in advance. Without that scope, connected tools whose method is a delete are left out of the tool list and the search index.

Why shouldn't a coding agent's own approval rules decide read versus delete?

Because every connected Elaichi tool reaches the client through one tool, execute_tool, and the usual approval rules name that tool instead of the one inside it. In Elaichi, connected tools are never listed one by one, however few there are. The agent finds a tool with search_tools and runs it with execute_tool.

Claude Code writes MCP permission rules against a tool name, such as mcp__puppeteer__puppeteer_navigate. For Elaichi, that name is the same for a Sentry read and a Sentry bulk delete. A Cursor approval prompt likewise names execute_tool, with the real tool inside the arguments.

Claude Code can go further, but only on the command line. A deny rule passed with --disallowedTools can match the name parameter of execute_tool by exact value, which names one tool. Settings files skip MCP rules that carry a parameter, and allow rules cannot match a parameter at all.

So keep the read-versus-delete decision in Elaichi's restrictions. execute_tool is only a naming indirection. It unwraps to the real tool and arguments and passes the same checks as a direct call, with no extra privilege.

How do frozen parameters keep a long-running agent on target?

They fix the arguments that pick a destination, so the agent cannot choose them. Freeze channel on create_a_slack_chat and the project inside fields on create_a_jira_issue.

A frozen key is stripped from the schema the agent sees, so the model is never offered a channel to pick. At execution, the frozen value is merged over whatever the agent sends. The order is entry defaults, then the agent's arguments, then frozen values last.

That matters most for an agent nobody is watching. A misread ticket cannot send its status update to the company-wide channel. One condition: a freeze binds only calls made through its toolbox entry, so share the toolbox with the people it governs, not the connection itself. The connection owner pins the entry and vouches for it, so pick an owner who will stay. Locking a wire transfer's receiver walks through the same setup.

What does one Jira ticket look like, call by call?

Seven steps, five of which run through Elaichi. The code edits and the pull request stay on the engineer's machine.

1. The agent searches for a Jira tool and calls get_single_jira_issue_by_id for the ticket.
2. It reads the error with get_single_sentry_organization_issue_by_id, then list_all_sentry_issue_events with latest as the event ID.
3. It checks the incident with get_single_pagerduty_incident_by_id.
4. It edits files and runs tests locally. Elaichi sees none of this.
5. It opens the pull request with the engineer's own Git and GitHub credentials. GitHub is not in Elaichi's catalog, so this step stays outside Elaichi.
6. It links the pull request with create_a_jira_issue_comment and create_a_pagerduty_incident_note.
7. It posts a summary with create_a_slack_chat, to the frozen channel.

Each call through Elaichi passes the engineer's role, the restrictions and the grant's scopes. An agent stuck in a retry loop meets a plain limit: 120 MCP requests a minute per token, then a 429 with Retry-After: 60.

How do you tell afterward which agent made a call?

From Elaichi's audit trail, which records one entry per tool-call attempt, succeeded or failed. Each entry names the account the call actually reached.

Each tool-call entry also records the surface and the OAuth client the call came through. Elaichi trusts a client's name only when its registered redirect addresses prove it, as with Claude, ChatGPT and Cursor. A terminal client that signs in through a local loopback address, such as Claude Code, carries the name it registered with, marked unverified.

The trail keeps argument names and counts, and never argument values, so it shows what ran and where without holding the payload. The read-only Auditor seat is free. Beyond the in-app trail, export to your own Datadog comes with the Black plan, which is launching soon. What an AI audit log must capture lists the fields.

Is there an MCP gateway that supports Claude Code and Codex for engineering teams?

Elaichi is an MCP control plane rather than a gateway in front of servers you run, and its endpoint is standard MCP over Streamable HTTP behind OAuth. Claude Code, Cursor, Codex, Windsurf and VS Code Copilot connect to it with an OAuth sign-in and no key. Any other client fits under "any MCP client" when it supports remote servers with an OAuth sign-in.

Codex documents both. Its docs describe "Streamable HTTP servers: Servers that you access at an address", and codex mcp login <server-name> "to start an MCP OAuth login" (Codex MCP docs, checked October 2026). Sign-in needs a browser. An unattended CI run with no browser, in any of these clients, cannot sign in, so plan for engineers to sign in at their own machines.

When is an app's own MCP server the better choice for a coding agent?

When the team needs one app, especially one Elaichi does not carry. The app's server runs under its own permission model and puts no second vendor in the path.

GitHub is the clearest case. Its server "connects AI tools directly to GitHub's platform", hosted at https://api.githubcopilot.com/mcp, with a read-only mode that skips write tools (GitHub MCP Server, checked October 2026). Sentry runs one at https://mcp.sentry.dev/mcp, and "All connections use OAuth" (Sentry MCP, checked October 2026). Atlassian's server connects Jira, Confluence and more to AI tools "using OAuth 2.1 or API tokens" (checked October 2026).

What Elaichi adds is the layer across apps. Engineers add one address instead of one server per app. Restrictions are written once for the engineer role across Jira, Sentry, PagerDuty and Slack. Frozen arguments, one audit trail, and one removal that ends access through Elaichi come with it. That removal does not close the person's accounts inside each app.

When does an engineering team not need any of this?

When the agents only touch local code, or when a few engineers share one read-only account and nobody asks who did what. A coding agent that reads and writes files reaches no SaaS account, so there is nothing to govern.

Elaichi also stops at its own edge. It does not see the shell, Git, or a local server an engineer adds beside it. The prompt-injection write gate lives in the Elaichi agent window and does not apply to a raw tool call. A poisoned ticket can still steer a model toward a tool. Restrictions decide whether that tool exists for the engineer, and the attempt is logged.

A contractor, a second Jira site or an auditor's question changes the math. Run the test in when you don't need an MCP gateway first. Gold lists at $15 per user per month in USD.