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?