--- title: Introducing the Autter MCP server | Autter Blog description: Connect Claude Code, Cursor, OpenCode, and other MCP-compatible coding agents to Autter’s reviews, codebase intelligence, security findings, and team knowledge. url: https://autter.dev/blog/autter-mcp-server date: 2026-07-27 author: Team Autter tags: Product, MCP, AI reading_time: 4 min site: Autter - Autter is the assurance layer for the AI coding era: it reviews code, tests product impact, checks security, governs releases, and closes the loop from production failure to verified fix. --- [← All posts](https://autter.dev/blog) Jul 27, 2026 # Introducing the Autter MCP server Connect Claude Code, Cursor, OpenCode, and other MCP-compatible coding agents to Autter’s reviews, codebase intelligence, security findings, and team knowledge. Team Autter 4 min read - Product - MCP - AI AI coding agents have become remarkably good at writing code. They can build features, refactor services, trace bugs, generate tests, and occasionally rewrite half the repository because you asked them to rename one variable. But there is still an awkward gap in the workflow. The agent writing the code often cannot access what the review system already knows about it. It cannot see the architectural context Autter has built, the conventions your team follows, the security issues found during previous reviews, or the potential blast radius of the change it is about to make. Developers have to carry this information between their editor, GitHub, and the Autter dashboard. We built the Autter MCP server to close that gap. Where code is written **Coding agent** Claude Code Cursor OpenCode Any MCP client The bridge **Autter MCP Server** 16 purpose-built tools What Autter knows **Autter intelligence** Reviews Security Codebase Team knowledge *The code writer can finally talk to the code reviewer.* Through the Model Context Protocol, coding agents such as Claude Code, Cursor, OpenCode, and other MCP-compatible clients can now interact directly with Autter. Your coding agent can understand the repository, retrieve review findings, fix issues, check dependencies, and request another review from the same environment where it writes the code. > “The code writer can finally talk to the code reviewer.” ## What we built The first version of the Autter MCP server includes 16 tools covering the main stages of working with a repository. | Area | What the agent can do | | --- | --- | | Repository discovery | Confirm its identity and find connected pull requests | | Pull request review | Retrieve findings, reply to comments, resolve threads, and request another review | | Team knowledge | Read existing conventions and teach Autter new ones | | Codebase intelligence | Query the architecture, inspect symbols, calculate impact, and check repository health | | Security and quality | Run scans, retrieve findings, monitor progress, and check dependencies | These are not generic API endpoints placed behind an MCP wrapper. Each tool is designed around something a coding agent may genuinely need to do while working on a change. ## Review findings an agent can act on The central tool is `get_pr_review`. It returns the latest review status, the overall pass, warning, or blocking verdict, review chapters, risk levels, and up to 50 findings ordered by severity. Each finding includes its file and line location, severity, confidence, verification result, and current GitHub thread state. More importantly, it includes a ready-to-use `fix_prompt`. Review comments are normally written for humans. They assume the developer will inspect the surrounding code, understand the architecture, and work out the right implementation. A coding agent needs that same feedback expressed as a specific instruction it can execute. The `fix_prompt` turns an Autter finding into that instruction. The agent can retrieve the issue, understand what went wrong, and begin fixing it immediately. Once the changes are complete, the agent can reply to the GitHub comment, resolve the review thread, push its changes, and request another review. The complete loop now looks like this: ``` Fetch review → apply fixes → resolve threads → push changes → request another review ``` GitHub remains the source of truth for thread resolution. If GitHub is temporarily unavailable, Autter still returns the rest of the review with a clear indicator that the thread state could not be retrieved. ## Understand the code before changing it Impact analysis **What could this change affect?** Elevated risk 08 **Reverse dependencies** Direct consumers 23 **Transitive dependents** Wider blast radius Changed file **src/auth/session.ts** Core authentication path 61% **Test coverage** 3 affected journeys High **Churn hotspot** 17 changes this month *Autter maps the change beyond the diff before the agent starts editing.* MCP is not limited to fixing problems after a pull request has been opened. Agents can consult Autter before writing the change. `get_impact_analysis` helps an agent understand what could break if certain files are modified. It reports reverse dependencies, transitive dependants, churn hotspots, test coverage, and the estimated risk of the proposed change. `get_symbol_info` lets the agent inspect a function, class, or symbol before editing it. It can see where the symbol is defined, who calls it, what it calls, whether it acts as an entry point, and how large its blast radius may be. For broader questions, the agent can use `query_codebase`. Autter answers natural-language questions using its generated documentation and code graph, then includes citations pointing to the relevant repository context. Instead of repeatedly searching files and hoping it found the important ones, the agent can ask the system that has already mapped the repository. ## Check dependencies before installing them Most dependency warnings arrive after the package has already been added. The feature is built, the pull request is open, and a security scanner finally explains why the new dependency was a questionable life choice. With Autter MCP, the agent can check first. It can look for known CVEs, find fixed versions, retrieve upgrade recommendations, and detect typosquatting or supply-chain warnings. It can also start a full repository scan, monitor its progress, and retrieve findings across Autter’s scanning agents. Security moves closer to the actual decision, allowing the agent to evaluate a package before introducing it instead of discovering the risk after the implementation is complete. ## Give agents your team’s context Every engineering team has conventions that are obvious to its members but invisible to an AI agent. Use the shared logger. Keep database writes inside a transaction. Never call this service directly. Do not touch that old utility on a Friday. Autter learns these patterns through review feedback, dismissed findings, and repository rules. Through `get_learnings`, agents can read those conventions before they begin writing code. The reverse flow works too. An authorized agent can use `add_learning` to teach Autter a new repository rule, such as: > Use the shared structured logger instead of calling console.log. That learning becomes part of the context used by future Autter reviews. Knowledge discovered while implementing one change can improve how later changes are written and reviewed. ## Built with controlled access The MCP server uses organization-scoped Autter Personal Access Tokens. Tokens can expire, be revoked, and be restricted to read, write, or LLM-backed operations. There is no arbitrary SQL access and no generic GitHub write tool. Every operation is limited to Autter’s review, security, and code-intelligence workflows. Tool failures return structured errors such as `repo_not_found`, `insufficient_scope`, `scan_limit_reached`, or `github_unavailable`. This gives the coding agent enough information to correct its request instead of getting stuck on a vague error. Every tool call is recorded in the organization’s audit log, including the actor, token, duration, result, and error code. Per-token rate limits also protect against runaway agent loops, because even machines occasionally need someone to tell them to slow down. ## What this changes The Autter MCP server turns code review from a handoff into a continuous feedback loop. A coding agent can now understand your architecture before touching it, follow team conventions while writing code, check dependencies before installing them, retrieve actionable review findings, fix the issues it introduced, and request another review through one standard protocol. The goal was never to put the Autter dashboard behind an API. It was to make Autter’s review intelligence available at the exact moment an AI agent needs it. AI agents are already writing more of the code. Now they can understand what the reviewer knows before that code reaches production. **PS:** Sagnik wanted to add one more tool to this whole thing: a big red button that lets a human yell at the AI mid-task and tell it to slow down. No settings, no options. Just yelling. Tanvi pointed out that's not a feature, that's just a rate limit with feelings, and we already built one of those. *(currently: deciding if the AI should have to say "please" before it's allowed to teach us anything)* ### See Autter on your own code. A 30-minute walkthrough with the founders. Bring a repo and watch Autter review a live pull request. [Book a demo](https://autter.dev/contact) ## Put an assurance layer on every release. Autter reviews every pull request before it merges, backed by humans. Connect a repo and see your first findings today. [Get started](https://app.autter.dev/login) ## Keep reading [Jul 16, 2026 · 14 min read Autter vs CodeRabbit: a reviewer is not a merge gate Compare Autter and CodeRabbit on AI code review, runtime verification, merge gates, rate limits, and pricing for teams shipping AI-generated code.](https://autter.dev/blog/autter-vs-coderabbit)