Why an MCP code reviewer — not just the Cursor chat

Asking Cursor to “code review this” on a large diff is fine once. On repeat — open source PRs, client projects, my own repos — you want something reproducible: same angles (bugs, security, missing tests), same outputs, without re-explaining context every session.

Why MCP here

ai-code-reviewer-mcp isn’t “better prompt engineering.” It’s exposed tools: read the diff, target a file, draft a PR comment. The agent picks steps; I control what it’s allowed to touch. That kills vague Friday-afternoon reviews and pairs well with the remote model (free tokens) from my other post.

Why it’s useful for me

• Open source: structured feedback before merge, without five tabs open.
• Same logic on my remote Qwen (vLLM on AWS) — no extra Cursor cost per review.
• Gradio demo on Hugging Face to show the idea without installing MCP.
• Template for other “AI acts on a real system” integrations.

How it’s built (briefly)

TypeScript MCP server (stdio) + Octokit for GitHub + OpenAI-compatible client on Qwen served via vLLM on AWS. Tools split the review: list diff files, fetch a hunk, analyze with a focused prompt (bug / security / debt / tests).

• list_changed_files / get_file_diff — minimal context, not the whole repo.
• analyze_snippet — one focus at a time, structured JSON output.
• Same LLM stack as Cursor (custom base URL) → free tokens, no double billing.
• Gradio Space on Hugging Face: same analysis engine, no MCP layer, for public demos.

// One tool = one responsibility
server.tool('analyze_snippet', { path, diffHunk, focus }, async (input) => {
  const findings = await llmReview(input) // → vLLM on AWS
  return { content: [{ type: 'text', text: JSON.stringify(findings) }] }
})

In short

I didn’t build this to replace a human on final review. I built it to automate the first pass — the one nobody wants to redo by hand — and to show MCP + self-hosted LLM is a credible combo outside Twitter demos.