LGTMCP is an AI-powered code review MCP server that uses Google Gemini to analyze git repository changes and optionally commit approved code.
Review only (review_only): Analyzes staged and unstaged changes in a git repository and returns detailed AI-generated feedback with an approval status, without committing anything.
Review and auto-commit (review_and_commit): If Gemini approves the changes (LGTM), automatically commits them with a provided message and returns the commit hash — otherwise, returns detailed review feedback.
Security scanning: Automatically scans code changes for exposed secrets using Gitleaks before sending to the AI reviewer.
Context-aware review: Gemini can request additional file contents for better context, while gitignored files are automatically blocked from access.
Project-specific guidelines: Discovers and incorporates AGENTS.md and REVIEW.md files from the repository to apply custom review rules.
Fallback model support: Falls back to a secondary Gemini model if the primary hits quota limits.
MCP integration: Works with MCP clients like Claude Desktop.
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.7 Flash. LGTMCP reviews your code changes and either commits them automatically (if approved) or provides detailed feedback for improvements.
In my usage, the median review takes 1.9 minutes and costs $0.20, with an
acceptance rate around 45%. Those figures were measured with the previous
default model, gemini-3.1-pro-preview; they have not been remeasured on
Gemini 3.7 Flash, which is priced lower per token. You should decide whether
that is slow and expensive or fast and cheap.
AI Code Review: Leverages Google Gemini 3.7 Flash for intelligent code analysis
Automatic Commit: Commits changes when code passes review (optional)
Security Scanning: Built-in secret detection using Gitleaks
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.7-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.7 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.7 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 -- lgtmcpThe 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
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 files for secrets using Gitleaks
Diff generation: Creates diff of all staged and unstaged changes
AI review: Sends diff to Gemini 3.7 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 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 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. Dates show when Glama detected each change.
v0.0.0-4996ceereview_and_commitreview_onlyThe 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Deep security scans of repos you own from your editor: dependency CVEs, SAST, git-history secrets.
Security reviews for coding agents: diffs checked against your org policy and live infrastructure.
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
Agentic code review, no signup to try: reality gates + frontier-model review, with veto.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/shields/lgtmcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
