Antigravity MCP Server

by JamesZor

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap between delegate_to_antigravity and start_background_job (both run agy tasks), and between check_job_status and research_status (both poll for status). However, descriptions differentiate them well and the contexts are separate.
Naming Consistency4/5
Tools follow a consistent snake_case verb_noun pattern (e.g., check_job_status, collect_digests, propose_design_questions). Minor inconsistencies: auto_git_commit uses a prefix, and some verbs are compound (cross_model_review). Overall, the pattern is clear and predictable.
Tool Count5/5
With 13 tools, the server covers a broad domain (git, research, design, code review, background jobs) without being excessive. Each tool earns its place, and the count is appropriate for the advertised capabilities.
Completeness5/5
The tool surface covers the full lifecycle of research and design pipelines: question proposal, fanout, status polling, collecting digests, and drafting documents. Additionally, git operations, code indexing, and cross-model review are included. No obvious gaps for the intended use case.
Average 4.2/5 across 13 of 13 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It mentions using 'Antigravity' and the 'adversarial' flag, but does not clarify key aspects like whether the operation is asynchronous, what it modifies, required permissions, or side effects. The description is insufficient for an agent to understand the behavioral implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a one-sentence summary, a helpful tip, and a bullet list for arguments. It is front-loaded with the core purpose. However, the info could be slightly more structured, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown), the description need not detail return values. It covers the basic usage and parameters, but lacks context on sibling tool differentiation and behavioral details. Completeness is adequate but leaves gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 'diff' as the code changes, 'adversarial' as challenging design decisions, and 'tier' with a default and example values. This adds meaningful semantic context beyond the bare schema titles, though it could be more exhaustive (e.g., valid tier options).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('independent cross-model review of a code diff'). It distinguishes itself by mentioning 'using Antigravity' and the concept of cross-model review, but does not explicitly differentiate from sibling tools like 'delegate_to_antigravity' or 'review_fanout'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tip provides guidance on selecting the 'tier' parameter to use a different model family for better blind spot coverage. However, it does not specify when to use this tool compared to alternatives, nor does it provide any 'when-not' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, and description only states purpose; lacks disclosure of read-only nature, error handling, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two effective sentences with front-loaded purpose, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with one param and output schema; description covers main functionality, though missing context on expected status values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter job_id is explained as 'The ID of the job to check', adding meaning beyond schema name, but no format or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'check' and resources 'status' and 'retrieve output', distinguishing from sibling tools like start_background_job.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicitly used after starting a job, but no explicit when-to-use or alternatives provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It implies a read operation ('report') but does not disclose potential side effects, authorization needs, rate limits, or error conditions. It is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two sentences: one for purpose and one for parameters. No redundant information, and the key action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description is sufficient. It explains the tool's purpose and parameter source. It does not cover error scenarios, but that is acceptable with an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds value by explaining the parameter as 'The batch ID returned by research_fanout', giving context beyond the schema's 'Batch Id' title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Report aggregate status of every worker in a research batch.' It specifies the verb 'report', resource 'aggregate status', and scope 'every worker in a research batch'. It is distinct from sibling tools like 'check_job_status' but does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context by stating the batch_id comes from 'research_fanout', guiding where to obtain the parameter. However, it lacks explicit guidance on when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses some behavioral traits: 'cost discipline', 'verify', marks 'yolo' as DANGEROUS, mentions 'sandbox restrictions', and provides defaults. However, it does not explain side effects, failure modes, whether it is synchronous, or permissions needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise: one sentence stating the purpose followed by a parameter list. The parameter list is efficiently formatted with brief explanations. However, the parameter list could be slightly more compact, but overall it is well-structured and not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, one required, an output schema exists but is not shown in the description, and no annotations, the description is incomplete. It does not explain the return value, verification process, or overall workflow. While parameter coverage is good, the lack of output and process explanation leaves significant gaps for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The JSON schema has 0% description coverage for parameters, so the description must fully compensate. It does so by listing all 8 parameters with their names, types, and defaults, and adding explanatory notes like 'DANGEROUS' for yolo and 'stateful' for conversation_id. This provides complete semantics beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delegate a well-scoped subtask'), the target ('Antigravity (agy/Gemini)'), and key constraints ('under cost discipline, then verify'). It distinguishes from sibling tools by focusing on delegation of subtasks with cost discipline, which is unique among the listed siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is for delegating well-scoped subtasks under cost discipline, but it does not explicitly state when to use it versus alternatives, nor does it provide when-not-to-use guidance or compare with sibling tools like 'research_fanout' or 'propose_design_questions'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It mentions 'reads' and 'returns', implying read-only access, but does not explicitly state that the tool is non-destructive, idempotent, or safe. It also lacks information on rate limits, authentication, or potential side effects like file creation via out_path.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at about 100 words, with a clear one-sentence purpose, a usage guideline sentence, and a structured Args section. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters and an output schema, the description provides essential information about what the tool does, when to use it, and parameter details. It does not cover error handling or output format, but the output schema likely addresses the latter. Overall, it is nearly complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully explains all three parameters: paths (list of absolute paths), focus (with examples and default), and out_path (with example and purpose). This compensates entirely for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'reads specific directories or files' and 'returns a distilled architectural index', with a specific verb and resource. It is distinct from sibling tools which include auto_git_commit, check_job_status, etc., and effectively communicates its unique role in codebase understanding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use: 'to quickly understand a subset of a codebase... without pulling all raw files'. While it doesn't explicitly state when not to use or name alternatives, the usage context is clear and specific.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool returns a short digest and the orchestrator reads and edits the file, plus the writing to out_path. It could mention more about error handling or permissions, but provides reasonable transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is structured with paragraphs and an Args list. Front-loaded with the core action. Every sentence adds value, though could be slightly more concise without losing detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given tool complexity (5 params, output schema exists), the description covers return behavior, pipeline context, and parameter roles. It adequately informs an AI agent, though more details on error cases or expected output format would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description compensates by listing parameters with explanations (e.g., 'batch_ids: review_fanout / research_fanout batch IDs'). Adds meaning beyond the bare schema, though some parameters could be more detailed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: drafting a structured design document from on-disk batches. It uses specific verbs ('draft', 'reads') and distinguishes itself from sibling tools as the synthesis step of the Architect pipeline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool's role as the synthesis step, requiring review and research batch dirs plus a verified brief. It implies usage after prior steps but does not explicitly state when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses key behaviors: staging, AI-generated commit message, commit, optional push. Explains stage_all parameter behavior. Could mention what happens on failure or auth requirements, but still provides good transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences plus bullet-style parameter descriptions. Every sentence adds value, no repetition or fluff. Front-loads the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has 3 parameters and output schema (exists but not described). Description covers core workflow and parameters. Missing details on output or error states, but output schema likely handles that. Reasonably complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description compensates by explaining each parameter: repo_path is absolute path, push boolean, stage_all boolean. Defaults are mentioned in schema and description echoes them. Adequate for understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states what the tool does: automatically stage, generate a commit message using Antigravity, commit, and optionally push. Verb 'auto_git_commit' directly reflects action, and resource is git operations. Differentiates from siblings as no other tool handles git commits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this to offload boring token-wasting git operations from the frontier model', providing clear when-to-use context. Does not mention when-not-to-use or alternatives, but the guidance is direct and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden of behavioral disclosure. It explains the return value (short digest per worker plus on-disk path), implies it is a read-only operation ('Gather... from a finished research batch'), and mentions no destructive side effects. It could add details about required permissions or error handling, but is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: three sentences plus an 'Args' section. It front-loads the purpose, each sentence adds value, and there is no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and sibling tools, the description adequately explains what the tool does, when to use it, and what it returns. It implies the batch must be finished, which is clear enough, but could explicitly mention that the batch must be completed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains that batch_id is the ID returned by research_fanout and that include_stderr, when true, includes stderr for debugging. This adds meaningful context beyond the schema's basic 'Batch Id' and 'Include Stderr' titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Gather the stdout digests from a finished research batch (NOT the full reports)', specifying the verb 'gather', the resource 'stdout digests', and the scope 'finished research batch'. It explicitly distinguishes from full reports, helping differentiate from sibling tools like research_fanout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool: after a finished batch, to keep context lean, and suggests reading individual subreport files only when needed. It implies not to use it for full reports, but does not explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 describes that workers web-search, write markdown reports to files, and print digests to stdout, but lacks details on error behavior, file naming, resource limits, or batch identification. This is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a one-line summary, a block explaining the pipeline, and a concise Args list. Every sentence delivers value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main behavior and workflow integration. Given that an output schema exists, it doesn't need to explain return values. However, it could be more explicit about how to obtain the batch_id, though that is assumed to be in the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description provides detailed parameter semantics in the Args section, explaining the purpose of each parameter, including defaults for tier and timeout. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Launch parallel grounded-research workers, one detached Antigravity (agy) job per sub-question.' It uses specific verbs and resources, and distinguishes itself from sibling tools by naming them as polling/gathering tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says it's the fan-out half of a deep-research pipeline and guides the user to poll with research_status(batch_id) and gather with collect_digests(batch_id), providing clear context on when to use this tool and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the return format (JSON or fallback to raw text), the pipeline flow (orchestrator asks user, refines, writes requirements.md), and notes that the task is cheap (flash tier). However, it does not explicitly state whether the tool has side effects (though it is likely read-only).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, context, return details, and args. It is informative but slightly verbose with non-essential phrases like 'the *grill*'. Still, it efficiently conveys necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has four parameters and an output schema, the description covers the return format, fallback, and pipeline. It does not detail the output schema fields, but this is acceptable since the output schema exists. The description is complete for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains all four parameters: goal (required), repo_path (optional path to existing codebase), context (optional extra context), and tier (default 'flash' and described as cheap task). This adds meaningfully beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'draft' and the resource 'clarifying questions and candidate requirements to sharpen a build/improvement brief'. It distinguishes itself from the sibling tool 'propose_research_questions' by specifying it is for software projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states it is the first step of the Architect pipeline and that the orchestrator should use it before spending quota on code review or design doc. The description also notes it mirrors propose_research_questions but for software, providing clear usage context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses return format (JSON with specific fields), fallback behavior (raw text if non-JSON), and model tier (cheap task, default 'flash'). With no annotations provided, this description carries the full burden and does it adequately, though it could mention statelessness or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (~150 words) and front-loaded with purpose. It follows a logical flow: purpose, usage, return format, args. Minor improvement would be to separate sections more clearly, but it is efficient and no sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 3-parameter input, output JSON description, and no annotations, the description provides sufficient context for an agent to use the tool correctly. It covers workflow, parameter meanings, and output structure. Slightly lacking on error handling (fallback raw text not fully described) but overall comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters (topic, context, tier) are described in the 'Args' section with useful explanations and examples. Since the schema has 0% description coverage, this description fully compensates and adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Draft' and the resource 'clarifying questions and candidate sub-questions to sharpen a research brief'. Distinguishes itself from the sibling tool 'research_fanout' by explicitly stating it should be run before it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit workflow guidance: 'Run this BEFORE research_fanout' and explains the subsequent steps (orchestrator asks user, refines brief, then spends quota on research_fanout). This clearly indicates the tool's position in the pipeline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses dangerous behavior (yolo) and sandbox restrictions, but could mention failure handling or concurrency limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with purpose and return value, then clear parameter list. No superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 8 parameters and existence of output schema, the description covers all aspects needed for correct invocation, including parameter details and return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description explains each of the 8 parameters in detail, including values and warnings, fully compensating.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it starts a long-running Antigravity task in the background and returns a job_id. It specifies the association with 'agy/Gemini' and differentiates from sibling tools like 'check_job_status'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the tool is for background tasks, implying when to use it. It doesn't explicitly list when not to use, but the context of sibling tools provides clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains that workers are detached, writes reports to disk, prints digests to stdout, and that collectors are batch-generic. It implies asynchronous operation via polling, but could be slightly more explicit about resource usage or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence summary of the action, a paragraph explaining behavior and follow-up steps, then a list of parameters. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to detail return values. It adequately covers the tool's role, its relation to research_fanout, and the lifecycle of results (poll with research_status, gather with collect_digests). It provides sufficient context for an agent to correctly invoke and manage the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain all parameters. It does so thoroughly: repo_path is mandatory, aspects default to a 7-aspect sweep, goal is an optional focus, tier defaults to 'pro', timeout defaults to '10m'. Each parameter's meaning and default are clearly stated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it launches parallel codebase-review workers, one per aspect, using Antigravity jobs. It explicitly distinguishes itself as the code analog of research_fanout, making the purpose unambiguous and differentiating it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: to launch codebase reviews, and how to follow up by polling with research_status and collecting with collect_digests. It also contrasts itself with research_fanout, clarifying context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![antigravity MCP server](https://glama.ai/mcp/servers/JamesZor/antigravity/badges/card.svg)](https://glama.ai/mcp/servers/JamesZor/antigravity)

Score Badge

Copy to your README.md:

[![antigravity MCP server](https://glama.ai/mcp/servers/JamesZor/antigravity/badges/score.svg)](https://glama.ai/mcp/servers/JamesZor/antigravity)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/JamesZor/antigravity'

If you have feedback or need assistance with the MCP directory API, please join our Discord server