antigravity-review-mcp
This server provides AI-powered code reviews using Zhipu GLM, by analyzing git diffs with optional additional context. Key capabilities:
Flexible diff selection: Review staged changes (default), unstaged modifications, or changes against any git reference (e.g.,
HEAD~1, branch, or commit hash).Context enrichment: Include extra source files or OpenSpec change folders, automatically expanded and resolved (including
render_diffs()andfile:///links).Focused reviews: Limit the review to specific files via
focus_files, with scoped diffs.Task description: Guide the reviewer’s intent by providing a custom description of the task.
Repository specification: Set the working directory per review call or as a server startup parameter, allowing one config to review any repository.
Diagnostic tracing: Optionally include a compact trace in the output (workspace, diff target, payload sizes, model iterations, tool calls) for debugging.
Model-driven exploration: The GLM model can inspect the repository tree, search with ripgrep, read specific line ranges, and request full diffs—all safely confined to the repository root.
Efficient resource management: Deduplicates repeated requests, enforces context budgets per call and per tool, and uses timeouts to handle long operations.
Progress updates: Emits best-effort status notifications during major review phases for MCP clients that support them.
Configurable: Customize the AI model, API keys, base URL, timeouts, max iterations, and context limits via environment variables.
Provides AI-powered code review on git repositories by gathering diffs and optional source context, then using the model to generate a focused review.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@antigravity-review-mcpReview my staged changes"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Code Review MCP
AI-powered code review using Zhipu GLM. The server gathers git diffs and optional source context, then asks the model for a focused review.
Installation
Install dependencies:
git clone https://github.com/Enferlain/review-mcp.git
cd review-mcp
cp .env.example .env
# Optional: edit .env and add your API key
uv syncThen add it to your MCP client.
For local development, use uv run from your clone:
{
"mcpServers": {
"review-mcp": {
"command": "uv",
"args": [
"--directory",
"/absolute/path/to/review-mcp",
"run",
"review-mcp"
]
}
}
}For day-to-day use from Git, uvx avoids hardcoding a local install path:
{
"mcpServers": {
"review-mcp": {
"command": "uvx",
"args": [
"--from",
"git+https://github.com/Enferlain/review-mcp",
"review-mcp"
]
}
}
}The MCP caller should pass the repository being reviewed as working_directory on each review_with_context call. If your MCP client cannot pass a per-call workspace, you can still start the server with a fixed fallback:
"args": [
"--from",
"git+https://github.com/Enferlain/review-mcp",
"review-mcp",
"--workspace-dir",
"/absolute/path/to/the-repo-you-want-reviewed"
]Related MCP server: Git Code Review MCP
Configuration
Environment variables (in .env):
AI_API_KEY(required): Your API keyZHIPU_API_KEY(optional): Backward-compatible fallback key nameZHIPU_BASE_URL(optional): Override API endpointAI_MODEL/ZHIPU_MODEL(optional): Override the review model (default:glm-5.2)AI_REASONING_EFFORT/ZHIPU_REASONING_EFFORT(optional): GLM-5.2 reasoning effort (default:high; only sent forglm-5.2)AI_API_TIMEOUT_SECONDS(optional): Timeout for each model API request (default: 900)MAX_REVIEW_CONTEXT_CHARS(optional): Explicit character-based safety ceiling for the accumulated request. Unset by default; character counts are not used as a proxy for model tokens. The completion API'susage.prompt_tokensis the authoritative context measurement, and GLM-5.2 enforces its own model window.MAX_REVIEW_TOOL_RESULT_CHARS(optional): Per-tool result ceiling before truncation (default: 20000)REVIEW_TOOL_TIMEOUT_SECONDS(optional): End the MCP tool call before the host-level timeout (default: 1800)REVIEW_MCP_INCLUDE_TRACE(optional): Append diagnostic trace details to review responses (true/false)
Usage
The MCP exposes 1 tool: review_with_context
Parameters:
diff_target: 'staged' (default), 'unstaged', or a git ref like 'HEAD~1'context_files: Additional files or OpenSpec change folders to include as contextfocus_files: Specific files to focus the review ontask_description: Description of what you're trying to accomplishworking_directory: Git repository root to review (required unless the server was started with--workspace-dir)include_trace: Include a compact diagnostic trace in the returned review (optional, defaults toREVIEW_MCP_INCLUDE_TRACE)
While a review runs, the MCP tool emits best-effort status/progress updates for major phases such as loading context, preparing scoped diffs, calling the model, retrying transient model errors, running reviewer tools, and waiting during long model calls. MCP clients that display progress or log notifications can show those updates before the final review returns.
When called, it automatically:
Reads any files listed in
context_filesExpands explicitly provided OpenSpec change folders into their context files
Resolves
render_diffs()andfile:///links inside those context filesIncludes an initial scoped diff when
focus_filesor context-filerender_diffs()links identify filesLets GLM inspect a bounded repository tree, search with ripgrep, and read targeted line ranges
Lets GLM request repository-wide staged and unstaged diffs even when
focus_filesis activeDeduplicates repeated requests/results, records provider-reported token usage, and enforces the optional character safety ceiling plus per-tool result limits
Returns the final review
OpenSpec change folders are included only when the MCP caller passes the folder path in context_files, for example:
{
"context_files": [
"/home/imi/Projects/sd-scripts/openspec/changes/resource-intelligence-system"
]
}If MCP calls feel opaque, set include_trace to true for a single call or set REVIEW_MCP_INCLUDE_TRACE=true in the environment. The returned review will include a compact trace with the workspace, diff target, context-file count, model calls, provider-reported token usage, and tool calls.
Trace output is meant for debugging review behavior and can be disabled again once the setup is behaving as expected.
Codex / VS Code Notes
This server now starts cleanly under MCP hosts because it avoids doing heavy work at import time. A few setup notes still matter:
Prefer passing
working_directoryper tool call so one MCP config can review any repo.If your MCP client cannot inject the current repo automatically, set
--workspace-dirin the config as a fixed fallback.Prefer setting
AI_API_KEYas a system/user environment variable instead of storing it in MCP config.The tool-level
working_directoryargument still overrides the configured workspace when your agent provides it.
Example Windows fallback path:
"args": [
"--directory",
"D:/Projects/review-mcp",
"run",
"review-mcp",
"--workspace-dir",
"D:/Projects/myrepo"
]Example prompt to your AI assistant:
"Review my staged changes"
Security Note
Model-requested tree, search, and file-read tools are confined to the selected repository root, including protection against .. and symlink escapes. Explicit caller-provided context_files may still reference readable files outside the repository, so use those deliberately in sensitive environments.
Available Tools
1 toolreview_with_contextA
Review code changes against project context using GLM.
Args: diff_target: 'staged', 'unstaged', or a git ref like 'HEAD~1' context_files: Additional files or OpenSpec change folders to read focus_files: Specific files to focus the review on task_description: Optional task description for reviewer intent working_directory: Git repository root to review. Required unless the server was started with --workspace-dir include_trace: Include a compact diagnostic trace in the returned review
Returns: The generated code review.
| Name | Required | Description | Default |
|---|---|---|---|
| diff_target | No | staged | |
| focus_files | No | ||
| context_files | No | ||
| include_trace | No | ||
| task_description | No | ||
| working_directory | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'using GLM' but does not disclose behavioral traits like destructiveness, authentication needs, rate limits, or data handling. The description is minimal on behavioral context beyond the review generation.
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 a well-structured docstring with a one-line summary followed by Args and Returns sections. It is concise, with each sentence earning its place, though the parameter list could be slightly more compact.
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 6 parameters and no annotations, the description covers each parameter's purpose and mentions the return value. While it doesn't explain error cases or prerequisites, the presence of an output schema partly compensates. Overall, it provides sufficient context for basic usage.
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 0% description coverage, so the description's parameter details are crucial. It explains diff_target options, the nature of context_files and focus_files, the working_directory requirement, and include_trace purpose. This adds significant meaning beyond the schema types.
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 'Review code changes against project context using GLM,' which is a specific verb and resource. It distinguishes the tool as a code review tool, and with no siblings provided, it stands alone effectively.
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 does not explicitly state when to use this tool versus alternatives, but it implies use for code review. There are no sibling tools to differentiate, so the lack of exclusion guidance is acceptable but not proactive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
1 tool update
v0.1.0- First observed
review_with_context
TDQS
Only one tool exists, so there is no possibility of ambiguity or confusion with other tools.
With a single tool, naming is trivially consistent. The snake_case format is clear and descriptive.
A single tool for a code review server is borderline. While it can perform reviews, the workflow may benefit from additional tools for history or management.
The server lacks tools for retrieving past reviews, listing reviews, or managing review artifacts, leaving significant gaps in a complete review lifecycle.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
AI-native git hosting — repos, PRs, issues, CI gates, and AI code review over MCP (60 tools).
AI code review for GitHub PRs with an MCP autofix loop for Claude Code and Cursor
Versioned artifact review for people and AI agents, with contextual comments and human control.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceProvides filesystem access and integration with Z.ai's GLM-4 models for code generation and reasoning tasks. Designed to work as a git submodule with automatic parent repository detection.-
- AlicenseBqualityDmaintenanceEnables AI assistants to perform code reviews by providing access to staged files, git diffs, and repository file content. It allows users to evaluate changes and context within any local git repository before committing or pushing.317ISC
- AlicenseAqualityBmaintenanceGemini-powered code review. Offers review-only and review-and-commit modes with integrated Gitleaks security scanning.2Apache 2.0
- AlicenseBqualityCmaintenanceAI-powered code review server that analyzes git diffs and PRs with context from project guidelines and task lists. Supports integration with Claude Code and Cursor via MCP.31MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Enferlain/review-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server