AI coding assistants ship code fast. But someone still has to review it. I wanted that “senior engineer second pair of eyes” to live inside my editor, run entirely on my machine, and work with whatever assistant I’m using today. So I built MCP Code Review Server — a Model Context Protocol (MCP) server that connects to Claude Code, Cursor, Cline, or any MCP client.
What it does
It exposes three tools to your AI assistant:
-
review_code— paste any snippet and get a structured review -
review_diff— review a git diff before you merge -
review_file— point it at a local file
Each review returns findings with severity ratings (Critical / High / Medium / Low), file locations, and concrete fix suggestions.
The checks are the ones I kept catching my own assistants missing:
- OWASP Top 10 security scanning — injection, broken auth patterns, crypto misuse, unsafe deserialization
- Bug detection — None handling, exception swallowing, mutable default arguments, race conditions
- N+1 query detection — the classic ORM performance killer
- Performance profiling — repeated work in loops, blocking I/O, memory hotspots
- Style and complexity — long functions, deep nesting, configurable rule thresholds
Installation is one command
No signup, no API keys. It’s on PyPI:
# Claude Code
claude mcp add code-review -- uvx aicraft-code-review
# Cursor / Claude Desktop — add to ~/.cursor/mcp.json
{
"mcpServers": {
"code-review": {
"command": "uvx",
"args": ["aicraft-code-review"]
}
}
}
# Or pip
pip install aicraft-code-review
Enter fullscreen mode Exit fullscreen mode
That’s it. Your assistant now has a review tool it can call whenever you ask.
Why MCP instead of another SaaS tool
I tried the hosted code-review tools first. They’re good, but three things kept bothering me:
- Privacy. My review tool never needs to see the rest of my codebase. Uploading proprietary code to yet another vendor felt wrong.
- Cost. Per-seat subscriptions for something that runs fine on the laptop in front of me.
- Lock-in. I switch between Claude Code, Cursor, and Cline depending on the task. MCP is the common denominator — build once, run everywhere.
The server runs over stdio as a local process. Your code never leaves your machine. The only cost is the electricity.
Design decisions worth stealing
A few things I’d do the same way again:
-
Python + stdio. Simple, zero-dependency-at-runtime design, works on macOS/Linux/Windows.
uvxmeans users never even install it. - Structured output. Severity ratings + file/line references instead of prose. Agents consume structured data far more reliably than paragraphs, and humans can triage by severity.
- Static-first, then heuristic. It combines AST walking (Python) with regex/pattern rules for other languages, so it catches both structural issues (N+1 patterns) and localized smells (unsafe string formatting into SQL).
-
Git-native.
review_diffslots right into the “review before commit” habit that agents already have.
What I learned about MCP distribution
Getting a server working is the easy part. Getting it found is the real work:
- PyPI is where the install commands live, but almost nobody discovers tools there.
- Directories (Smithery, Glama, mcp.so, cursor.directory, awesome lists) are the actual discovery surface. Each has its own submission flow, quality bar, and wait time.
- AI agents now install MCP servers directly from directories — the distribution channel is increasingly agents themselves, not just humans.
That’s why I’ve been submitting the server to every directory with a review process, and keeping the repo metadata (glama.json, .mcp.json, smithery.yaml, a Dockerfile) in shape for their automated checks.
Try it
- GitHub: GoodJobwilliam/aicraft
- PyPI: aicraft-code-review
- Site: aicraft.vip
If you try it and hit a case it misses, open an issue — the rules are all configurable, and new checks are the fastest way this thing gets better.
What would you want an in-editor code reviewer to catch that yours currently misses?