I Built an MCP Server That Reviews Code Locally - No SaaS, No Uploads

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 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. uvx means 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_diff slots 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? Top comments (0)