Today we are shipping Connic MCP: a direct connection between a coding agent and a Connic project. Any client that speaks MCP, whether that is Codex, Claude Code, Cursor, or something else, can now read live runs, traces, and logs, ship deployments, and manage the project in the same chat where it writes the agents. The detour through the dashboard is over.
The whole development loop in one chat
Coding agents already write Connic agents well: the YAML, the tools, the middleware. Operating them was a different story. To find out why a run failed or what a deployment's tests said, developers left the editor for the dashboard, read the answer, and typed a summary of it back into the chat. The client that wrote the code could not see the system it was running on. Now it can ask directly. This became practical with the 2026-07-28 MCP release, the first protocol revision we would trust between a coding agent and production. Connic MCP is built on it, with a fallback for clients on the older protocol.
Building an agent was already fast on Connic. The slow part was everything around it: checking whether the deployment's tests passed, digging into last night's failed runs, confirming the new version actually behaves better than the old one. Connic MCP moves that work into the existing development conversation.
An agent that can see real traces writes better fixes than one working from a developer's paraphrase of an error, and one that can watch deployment tests can iterate until they pass instead of handing the checking back to a developer. Every step it can verify itself removes a manual handoff.
What a coding agent can do
The connection covers the Connic platform end to end, reading and acting on the same things available in the dashboard:
| Area | See | Do |
|---|---|---|
| Agents and runs | Runs, traces, logs, input and output previews | Cancel or rerun single and bulk runs |
| Deployments | Deployments, tests, deployment runs | Create, cancel, activate, redeploy |
| Connectors | Definitions, links, runs, stats, logs | Create, update, delete, link agents |
| Retrieval | Namespaces, entries, sources, stats | Upload content, manage and sync sources |
| Database | Stats, collections, inferred schemas, full document queries and counts | Update existing rows; delete documents and collections |
| Sessions | Persistent session state, agent and user identity, timestamps | Search and filter; delete individual or matching sessions |
| Approvals and channels | Pending approvals, routing, channels | Approve or reject calls, manage routing and channels |
| Judges and A/B tests | Judge stats and runs, variants, comparisons | Manage judges and tests, queue evaluations |
| Budgets and audit | Cost summaries, rankings, audit events | Manage budget alerts |
| Environments and governance | Environments, health, AI governance records | Manage environments and governance records |
Connect a client in one command
Setup takes one command, followed by a browser sign-in with a Connic account:
# Codex
codex mcp add connic --url https://mcp.connic.co/mcp
codex mcp login connic
# Claude Code
claude mcp add --transport http --scope user connic https://mcp.connic.co/mcp
# Cursor Agent, after installing the Connic plugin
cursor-agent mcp login connicWe recommend the Connic plugin. It bundles this connection with the Connic skill, so the client can write Connic agents and operate the project they run in. The Coding agent setup guide covers plugin installation in Codex, Claude Code, Cursor, and OpenCode, and manual connections for other MCP-compatible clients.
The Connic plugin or a direct Connic MCP connection lets the client work on the system it builds for.
Set up a coding clientProject members stay in control
Connecting a client does not hand it unrestricted access to a project. During approval, project members choose which project and environments it sees and whether it can only read or also act. A client can never do more than the approving account, and its access changes with that account. Every connection is listed in project settings with what it is allowed to do and when it was last used. MCP-triggered project actions follow the same audit behavior as equivalent API actions, while request-level traffic stays in service logs. Revoking takes one click.
Some capabilities are deliberately unavailable. A connected client cannot spend project funds, read credentials, delete a project, or start agent runs. External systems trigger agents through connectors, the production path built for it. There are also no API keys involved anywhere: never paste a Connic API key into an MCP configuration or a chat.
The third MCP surface
We now support MCP in three places, and they point in different directions:
mcp_servers in its YAML. Tools flow into the agent.Connic MCP does not add tools to a deployed agent or expose an agent as a tool. Those uses are covered by the MCP servers guide for agents and the MCP Server connector reference.
Getting started
Install the Connic plugin for the client, or add
https://mcp.connic.co/mcpdirectly. The Coding agent setup guide lists the exact commands.Approve the connection in the browser: pick the project, the environments, and what the client is allowed to do.
Ask the coding agent something that previously required opening the dashboard: the last failed run, the state of a deployment, yesterday's cost by agent.