LGTMCP lets you run AI-powered Gemini code reviews on git repository changes.
Use review_only to review staged and unstaged changes and get feedback without committing.
Use review_and_commit to review changes and automatically commit them if the review is approved.
Scan changed files for secrets with Gitleaks, honoring repo and server configs.
Let Gemini request file contents for context while blocking gitignored files.
Apply project-specific guidance from AGENTS.md and REVIEW.md files.
Configure the Gemini model, thinking level, fallback model, logging, and exposed tools.
Enables AI-powered code review and automatic commits for Git repositories, including diff analysis and security scanning of staged and unstaged changes.
Leverages Google Gemini models to perform intelligent code analysis and provide detailed feedback or approval for code changes.
A Model Context Protocol (MCP) server that provides AI-powered code review using Google Gemini 3.8 Flash. LGTMCP reviews your code changes and either commits them automatically (if approved) or provides detailed feedback for improvements.
In my usage with Gemini 3.8 Flash, the median review takes 3.2 minutes and costs $0.35, with an acceptance rate around 85%. You should decide whether that is slow and expensive or fast and cheap.
AI Code Review: Leverages Google Gemini 3.8 Flash for intelligent code analysis
Automatic Commit: Commits changes when code passes review (optional)
Security Scanning: Built-in secret detection using Gitleaks, honoring a repository's .gitleaks.toml
Gitignore Protection: Prevents access to gitignored files during review
Project Guidelines: Discovers AGENTS.md and REVIEW.md for project-specific review rules
MCP Integration: Works seamlessly with Claude Desktop and other MCP clients
Review-Only Mode: Option to get feedback without automatic commits
Related MCP server: MCP Code Crosscheck
git clone https://msrl.dev/lgtmcp.git
cd lgtmcp
make buildmake installThis installs the binary to ~/bin by default. You can customize the installation directory:
make install INSTALL_PATH=/usr/local/binNote: Ensure ~/bin is in your shell's PATH. Add this to your shell configuration file if needed:
# For bash/zsh
export PATH="$HOME/bin:$PATH"Get a Google API key from Google AI Studio.
Create configuration directory:
mkdir -p ~/.config/lgtmcpCreate configuration file from example:
cp config.example.yaml ~/.config/lgtmcp/config.yamlEdit the configuration file with your settings:
google:
api_key: "your-gemini-api-key-here"
gemini:
model: "gemini-3.8-flash"
thinking_level: "high"
# fallback_model: "gemini-3.1-pro-preview" # Optional; disabled by default
logging:
level: "info"thinking_level sets how much reasoning Gemini does before answering:
minimal, low, medium, or high (the default, for the most thorough
review), or none to leave the model's own default in place. Gemini 3.8 Flash
accepts only low, medium, and high. Thinking tokens are billed as output.
The optional fallback_model is used when we run into quota exhaustion on the
primary model. It is disabled by default (none); Gemini 3.8 Flash is generally
available with generous daily rate limits, so a fallback is rarely needed. Set
fallback_model to a model name (e.g. gemini-3.1-pro-preview) if you want a
safety net. The fallback receives the same thinking_level.
Set up configuration file as described above
Configure LGTMCP with Claude Code:
claude mcp add lgtmcp -- lgtmcpTo expose only some of the tools (see Enabling tools), add
the -tools flag to that command instead:
claude mcp add lgtmcp -- lgtmcp -tools review_onlyBy default the MCP server exposes two tools:
review_onlyReviews code changes and returns feedback without committing.
Parameters:
directory: Path to the git repository
review_and_commitReviews code changes and commits if approved. This is a separate tool so that
you can set tool permissions on it differently from review.
Parameters:
directory: Path to the git repository
commit_message: Message for the commit if approved
The -tools command-line flag takes a comma-separated list of the tools to
expose. It defaults to both: -tools review_only,review_and_commit. To make the
server unable to commit at all, rather than relying on tool permissions, enable
only the reviewer:
lgtmcp -tools review_onlyTools that are not listed are not advertised to the client and cannot be called. An unknown tool name, or an empty list, is an error at startup.
Review only (no commit):
review_only("/path/to/repo")Review and commit if approved:
review_and_commit("/path/to/repo", "Add new feature")Security check: Scans the changed files for secrets using Gitleaks
Uses the repository's .gitleaks.toml when it has one, with the CLI's
semantics: a config without [extend] useDefault = true replaces the
default rules, allowlists apply, and gitleaks:allow comments are honored
A gitleaks.config file in LGTMCP's own configuration applies to every
repository instead, like gitleaks --config
extend.path, extend.url and .gitleaksignore are not supported
Diff generation: Creates diff of all staged and unstaged changes
AI review: Sends diff to Gemini 3.8 Flash for analysis
Gemini can request file contents for context
Gitignored files are automatically blocked from access
Decision:
If approved (LGTM): Returns approval message (review_only) or commits changes (review_and_commit)
If not approved: Returns detailed feedback
Repositories can include AGENTS.md and/or REVIEW.md files with project-specific
review guidelines. LGTMCP automatically discovers these files by walking from each
changed file's directory up to the repo root, and injects their contents into the
review prompt. Files are deduplicated and sorted root-first (shallowest depth first).
All configuration except the set of enabled tools (the -tools flag; see
Enabling tools) is managed through the YAML configuration
file located at:
$XDG_CONFIG_HOME/lgtmcp/config.yaml (if XDG_CONFIG_HOME is set)
~/.config/lgtmcp/config.yaml (default)
See config.example.yaml for all available configuration options.
LGTMCP logs are written to platform-specific default locations:
macOS: ~/Library/Logs/lgtmcp/lgtmcp.log
Linux: ~/.local/share/lgtmcp/logs/lgtmcp.log (or $XDG_DATA_HOME/lgtmcp/logs/lgtmcp.log)
Windows: %LOCALAPPDATA%\lgtmcp\logs\lgtmcp.log
You can configure logging in your config.yaml:
logging:
output: "directory" # Options: none, stderr, directory
level: "info" # Options: debug, info, warn, error
# directory: "/custom/log/path" # Optional custom directoryTo view logs on macOS:
# View the log file
tail -f ~/Library/Logs/lgtmcp/lgtmcp.log
# Or open in Console.app
open ~/Library/Logs/lgtmcp/lgtmcp.logmake buildmake testmake lintmake coverage"Not a git repository" error
Ensure you're in a git repository with a .git directory
"Secrets detected" error
Review and remove any exposed secrets from your changes
"Gemini API error"
Verify your API key is valid and has quota remaining
Check network connectivity
"No changes to review"
Make sure you have staged or unstaged changes in your repository
"Review Result: NOT REVIEWED"
The diff is larger than review.max_diff_bytes (400 KiB by default), so
nothing was sent to Gemini and review_and_commit committed nothing
Diffs this large are usually generated, vendored, or mass-edited code, where a line-by-line LLM review costs a lot and catches little; raise the limit if you do want them reviewed
"Review Result: INCOMPLETE"
The reviewer found no issues, but file retrieval reached its limit (20 tool
turns or 1.5M prompt tokens per review) while it was still asking for
files, so the result lists the files its refused request asked for and
review_and_commit committed nothing
Review code changes using Gemini and commit if approved (LGTM). Returns review comments if not approved or success message with commit hash if approved and committed.
| Name | Required | Description | Default |
|---|---|---|---|
| commit_message | Yes | Commit message to use if changes are approved | |
| directory | Yes | Path to the git repository directory to review |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses key behavioral traits: uses Gemini for review, conditionally commits based on approval, and returns different outcomes (comments vs. success message with commit hash). However, it lacks details on review criteria, what 'approved' means, error handling, or side effects like branch changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded: a single sentence efficiently conveys the tool's core functionality, conditional logic, and return outcomes. Every word earns its place with zero waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description does well by explaining the conditional behavior and return values. However, as a mutation tool (commits changes), it could benefit from more details on permissions, review standards, or error cases to be fully complete for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters fully. The description adds no additional meaning about parameters beyond what the schema provides (e.g., no context on commit message format or directory requirements). Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('review code changes using Gemini', 'commit if approved') and resources ('code changes', 'commit hash'). It distinguishes from the sibling 'review_only' by explicitly mentioning the conditional commit action and different return outcomes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: use this tool when you want to review AND potentially commit code changes, with conditional logic (commit if approved/LGTM). It implicitly contrasts with 'review_only' by showing this tool includes commit functionality, making alternatives clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Review code changes using Gemini and return feedback without committing. Returns review comments and approval status.
| Name | Required | Description | Default |
|---|---|---|---|
| directory | Yes | Path to the git repository directory to review |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that the tool uses Gemini for review and returns feedback and approval status, which adds some context beyond basic functionality. However, it lacks details on permissions, rate limits, error handling, or what 'approval status' entails, leaving gaps in behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, consisting of one sentence that efficiently conveys the core functionality. There's no wasted text, and it gets straight to the point. However, it could be slightly more structured by explicitly contrasting with the sibling tool for better clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (code review with AI), no annotations, and no output schema, the description is somewhat complete but has gaps. It explains the purpose and outcome but lacks details on the review process, output format, or error scenarios. It's adequate as a minimum viable description but could be more comprehensive for better agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'directory' clearly documented. The description doesn't add any parameter-specific information beyond what the schema provides, such as format examples or constraints. According to the rules, with high schema coverage, the baseline is 3, and the description doesn't compensate with extra details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Review code changes using Gemini and return feedback without committing.' It specifies the action (review), the method (using Gemini), and the outcome (return feedback without committing). However, it doesn't explicitly distinguish this from its sibling 'review_and_commit' beyond the 'without committing' phrase, which is implied but not directly contrasted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool through the phrase 'without committing,' suggesting it's for review-only scenarios. However, it doesn't explicitly state when to use this versus the sibling 'review_and_commit' or provide any alternatives or exclusions. The guidance is present but minimal and not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.0.0-4996ceereview_and_commitreview_onlyScored across 2 tools
The two tools have clearly distinct purposes: one reviews and commits if approved, while the other only reviews without committing. There is no overlap or ambiguity between them.
Both tools follow a consistent verb-based naming pattern (review_and_commit, review_only), using snake_case throughout. The naming is predictable and aligned with their functions.
With only 2 tools, the server feels too thin for a code review and commit domain, lacking operations like listing reviews, updating commits, or handling rejections. This minimal set limits agent workflows.
The server covers basic review and commit actions but has significant gaps: no tools for managing or querying existing reviews/commits, no update or delete operations, and no error handling for edge cases, making the surface incomplete for robust code management.
Deep security scans of repos you own from your editor: dependency CVEs, SAST, git-history secrets.
Checks AI-written code for leaked keys and made-up packages, on your machine. Never uploads code.
Multi-brand AI code review for Claude: up to 12 reviewers and a judge, no install.
Security reviews, threat models over a repo or website, and remediation tracking, in your editor.
