antigravity-mcp-server

by adeelali4

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Every tool has a clearly distinct purpose: coordination status/reset, delegation lifecycle, board operations, path locking, messaging, presence, and activity log. There is no overlap or ambiguity.
Naming Consistency5/5
All tool names follow a consistent snake_case pattern with clear prefixes (coop_, ag_, board_, claim_, release_, check_, notes_, presence_) and verb_noun structure (e.g., board_post, ag_delegate). Even the single noun 'activity' is an acceptable exception.
Tool Count5/5
17 tools is well-scoped for a multi-agent coordination server. Each tool serves a necessary function in the collaboration workflow without being excessive or sparse.
Completeness5/5
The tool surface covers the full lifecycle of multi-agent coordination: status, reset, delegation (create, check, wait, followup, cancel), shared board (post, update, list), path locking (claim, release, check), messaging, presence, and activity log. No obvious gaps.
Average 3.7/5 across 17 of 17 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- 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?
No annotations are provided, so the description must disclose behavior beyond what structured fields offer. It fails to state whether reading messages has side effects (e.g., marking as read), requires authentication, or is destructive. The description is minimal and does not cover safety or operation traits like idempotency. This is a significant gap for a tool that reads user-specific data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), which is concise, but it borders on under-specification. It conveys the core action without any waste, but the structure lacks front-loading of critical details like parameter effects or when to use. It earns a 3 because it is efficient yet misses opportunities to pack key info into the brief format.
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 three parameters, no output schema, and no annotations, the description is not nearly complete. It does not address return format, pagination (implied by 'limit'), or the effect of 'mark_read'. For a read operation with parameters influencing state, this leaves significant unknowns for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema provides no parameter documentation. The description does not explain any of the three parameters (limit, mark_read, unread_only) or how they affect behavior. Without clarifying these, the agent cannot effectively configure usage. The description adds no semantic value beyond the raw property names.
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 reads messages left by another agent ('Read messages the other agent left for you'). The verb 'read' and the resource 'messages' are specific. While it distinguishes from 'notes_send' and lists of other tools, it could be more explicit about the source being other agents (not system) and that it retrieves messages addressed to you.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like 'coop_status' or 'ag_task_status'. The description does not mention scenarios for reading messages, prerequisites (e.g., having received messages), or when not to use it (e.g., for sending messages). The sibling tools list provides context, but the description itself lacks usage direction.
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?
With no annotations, the description carries the full burden of disclosing behavioral traits. It implies the tool is read-only (a timeline), but does not explicitly state it is non-destructive. It also omits details like ordering (presumably chronological), pagination, or whether the timeline is real-time. The phrase 'Recent timeline' suggests a limit, but the limit parameter is not mentioned in the description.
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 a single sentence of 14 words, efficiently conveying the core purpose. It is front-loaded with the key idea ('Recent timeline of what both agents have done'). Every word adds value, though the list of activity types could be slightly trimmed or omitted if the schema already structured them. Overall, it is concise without sacrificing clarity.
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 tool is simple (one optional parameter, no output schema, no annotations), the description is minimally adequate. It tells what the tool returns (a timeline of specific activities) but does not specify the return format, ordering, or how to use the 'limit' parameter. For a tool with no output schema, more detail on the structure of the returned timeline would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'limit' (integer) with no description (0% schema coverage). The description does not mention 'limit' or explain its purpose (e.g., 'maximum number of events to return'). While the parameter name is intuitive, the description adds no value beyond what the schema provides, failing to compensate for the missing schema documentation.
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 returns a 'Recent timeline of what both agents have done' and lists specific activity types (delegations, claims, releases, notes, status changes). It distinguishes from siblings like 'board_list' (board posts) and 'notes_read' (notes only) by implying a combined view. However, it lacks an explicit verb like 'List' or 'View', which slightly reduces precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. For example, it does not mention that for agent-specific task status you should use 'ag_task_status', or for board posts use 'board_list'. The description lists included activities but provides no exclusion criteria or context for choice.
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 are provided, so the description must fully disclose behavioral traits. It fails to mention whether this operation is read-only, what happens if the board is empty, performance implications of large lists, or any side effects. For a listing tool, the behavior is relatively simple, but the lack of annotations and any safety context leaves the agent without important behavioral information.
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 two concise sentences that convey the main purpose and a key filtering option. There is no wasted text, and the information is front-loaded. Every sentence adds value relative to the tool name and title.
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 that there is no output schema and no annotations, the description should compensate by explaining return format, pagination behavior (if any), and default values for limit and include_done. The absence of these details leaves the agent guessing about how many items are returned and what status items are included by default.
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?
Schema coverage is low at 33%, meaning only 1 of 3 parameters has a schema description (owner: 'Agent id; omit for all'). The tool description adds a semantic hint about 'Filter by owner' aligning with the owner parameter, but it does not explain limit or include_done beyond what the schema provides. Baseline 3 is appropriate given the partial coverage.
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 states 'List board items and delegated tasks' which gives a clear verb and general resource. It also adds scoping detail with 'Filter by owner to see just one lane.' While it doesn't explicitly distinguish itself from siblings like board_post or board_update, the purpose is clear enough to separate it from tools with different verbs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks guidance on when to use this tool versus alternatives. With 15 siblings including board_post, board_update, ag_delegate, and several other listing tools (e.g., check_paths, notes_read), there is no explicit when-to-use or when-not-to-use advice, no prerequisites, and no mention of alternative tools.
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?
Without annotations, the description carries the burden. It discloses that the tool returns status, final response, and conversation_id, and implies it can be called while running (since 'running' is a status). However, it does not state whether it is read-only (safe to call repeatedly), what happens if the task_id is invalid, or if there are any side effects. It provides basic transparency but lacks depth.
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 a single sentence of 18 words, front-loading the purpose and key outputs. Every word adds value; there is no fluff or repetition. It is efficiently structured for quick parsing.
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 two parameters, no output schema, and no annotations, the description is insufficient. It explains the purpose and return values but omits parameter meanings, error scenarios, and usage context relative to sibling tools. An agent cannot fully determine correct invocation without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/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 for the two parameters. The description does not mention 'task_id' or 'include_output' at all. It only hints at output via 'final response and conversation_id', but the boolean parameter for controlling output inclusion is completely unexplained. This is a critical gap for correct usage.
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 checks the status of a delegated Antigravity task, listing possible statuses (running/done/failed) and what additional data is returned (final response, conversation_id). It distinguishes from siblings like ag_task_wait (which waits) and ag_cancel (which cancels) by focusing on polling/checking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool vs alternatives (e.g., ag_task_wait, ag_followup). It does not mention prerequisites, such as the task_id coming from a delegated task, nor does it advise against calling it before the task starts or how to handle errors. The agent must infer usage from context.
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 are provided, so the description carries full responsibility. It discloses that calling this tool updates another agent's coop_status, which is a side effect. However, it does not explain whether it is idempotent, if previous status is overwritten, or any other behavioral traits like auth requirements or error handling. The disclosure is minimal.
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 sentences with no wasted words. The description is front-loaded with the purpose and ends with usage guidance. Very concise.
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?
For a tool with 2 parameters, no output schema, no annotations, and several sibling tools, the description covers the basic purpose and usage timing. However, it lacks parameter descriptions, return value information, and any mention of error conditions or prerequisites. It is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the input schema has no descriptions for its parameters. The description does not compensate: it mentions 'what you are doing' implicitly referring to the `status` field but gives no details about the `detail` parameter or the meaning of enum values. Parameter semantics are entirely missing.
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 announces the current activity to update another agent's coop_status. It uses specific verb-resource ('announce what you are doing') and the title reinforces this. However, it does not explicitly differentiate from the sibling `coop_status` tool, which likely reads the status, but the distinction is implied.
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 provides explicit guidance: 'Call when you start and finish a chunk of work.' This tells the agent when to use the tool. It does not, however, state when NOT to use it or mention alternatives, but the context of cooperation implies it is for status broadcasting.
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 that the tool releases the user's own locks and mentions the 'all_mine' parameter behavior. However, it does not describe side effects (e.g., whether releasing non-existent locks causes errors, if the operation is idempotent, or what happens with an empty paths array). Some behavioral context is present ('so the other agent is not blocked'), but gaps remain.
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 two sentences, front-loaded with the core purpose. The second sentence is slightly long but still clear. There is no unnecessary information. It could be more concise by combining the guidance with the parameter explanation, but it is effective.
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 lack of output schema, annotations, and schema descriptions, the description is incomplete. It does not explain what the tool returns (e.g., success/failure, list of released locks), error handling, or the relationship with 'claim_paths'. The agent may not know how to verify the release or handle failures. The description is adequate for a simple use case but lacks depth for a robust interaction.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 the 'all_mine' parameter ('Pass all_mine=true to drop every lock you own'), but it does not mention the 'paths' parameter at all. The agent has no guidance on how to use the 'paths' array, e.g., what format paths should be in or whether they are required. This is a significant gap.
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: 'Release path locks you hold.' It distinguishes from sibling tools like 'claim_paths' (acquire locks) and 'check_paths' (check status) by specifying the action of releasing. However, it does not explicitly mention what happens if no locks are held, which could be clarified.
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 provides a usage guideline: 'do this when you finish a chunk of work so the other agent is not blocked.' This gives clear context for when to use the tool. It does not explicitly mention when not to use it or alternatives like 'check_paths' or 'coop_reset', but the guidance is sufficient for the primary use case.
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 correctly indicates this is a mutation tool ('update'), but doesn't disclose what happens to fields not provided (left unchanged? cleared?), whether a note is required for certain status changes, or any permission/auth requirements. Annotations being empty makes a 3 reasonable – not misleading but incomplete.
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?
Two sentences, front-loaded with purpose, followed by a usage hint. Efficient and no wasted words. Could be slightly more structured with param details, but good for its compactness.
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 4 parameters (1 required, 1 enum), no output schema, and no annotations, the description covers the basics but lacks depth. Missing: behavior for partial updates, required note for certain statuses, and return value description. Adequate for a simple tool but not fully complete.
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?
Schema description coverage is 0%, meaning the description must compensate. It does mention the three updatable fields (status, owner, note) and groups them, giving some semantics. But it doesn't explain each parameter's meaning, constraints, or interplay (e.g., can you update status without note?). With 4 parameters and no schema descriptions, more param-level context would improve agent usage.
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: updating a board item's status, owner, or attaching a progress note. This distinguishes it from siblings like 'board_post' (which presumably creates) and 'board_list' (which reads). However, it doesn't explicitly name any sibling for differentiation, so it's not a full 5.
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 a clear usage hint in the second sentence: 'Keep your own items current here so the other agent is not guessing.' This implies when to use it (for tasks you're working on) but doesn't give explicit when-not-to-use guidance or name alternative tools for specific scenarios.
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 the full burden of behavioral disclosure. It mentions that cancelling releases held paths, which is a useful side effect. However, it does not state whether the task must exist, whether cancellation is idempotent, or what happens to associated resources.
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 a single sentence of 12 words that is front-loaded with the key action. Every word earns its place; there is no redundancy or unnecessary detail.
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 one required parameter, no output schema, no annotations, and moderate complexity (cancellation semantics), the description is too sparse. It lacks necessary details about task state assumptions, error cases, and the effect on the task's lifecycle.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the parameter 'task_id', and the description does not provide any additional meaning about it (e.g., format, expected values, or how to obtain it). The description adds no value beyond the schema's type and required flag.
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 ('Stop a running delegated Antigravity task') and the side effect ('release any paths it held'), making the purpose immediately understandable. It distinguishes from sibling tools like ag_delegate (start) and ag_task_status (status check).
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 the tool is for cancelling a running task, but provides no explicit guidance on when to use it versus alternatives (e.g., if the task is already finished, you might use ag_task_status instead). No exclusions or prerequisites are mentioned.
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 the full burden of behavioral disclosure. It reveals the key behavioral trait that the tool keeps context from the previous task. However, it does not mention required permissions, whether the task must be 'finished' (as stated), rate limits, or any side effects. The description adds some value but leaves significant gaps.
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 two sentences, front-loading the purpose and usage guidance. Every sentence adds value, and there is no extraneous text. The structure is efficient and clear.
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 3 parameters (2 required), no output schema, and no annotations, the description is insufficient. It does not explain the task_id format, what timeout_seconds controls, or the return value. It also does not clarify whether the 'finished task' condition is a requirement or a hint. The description leaves many critical details undocumented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the input schema provides no property descriptions. The description does not explain the meaning of any parameter (task_id, prompt, timeout_seconds). It only gives an example prompt in the quote. This is a critical failure to compensate for the missing schema descriptions.
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 sends a follow-up into the same conversation as a finished task, using 'prompt' as the follow-up request. It contrasts with the sibling 'ag_delegate' by noting context preservation. The phrasing 'as a finished task' is slightly ambiguous, but the example clarifies the intent.
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 provides when to use this tool ('whenever the request builds on work it just did') and when not to use it (by contrast with 'ag_delegate'). This is excellent guidance for tool selection, directly addressing the distinction from the most relevant sibling.
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 are provided, so the description bears full responsibility for behavioral disclosure. It only says 'Leave a message' without explaining side effects, persistence, whether notes are delivered, appended, or overwritten, or any authorization requirements. The example hints at the content but not at the behavior after sending.
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 two sentences long, front-loaded with the purpose, and every sentence adds value. There is no wasted words or repetition. The example is compact and illustrative.
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 absence of an output schema and only 50% schema description coverage, the description is adequate but not thorough. It explains the purpose and gives a usage example, but does not cover return values, error conditions, or behavior after sending. For a simple tool, it is minimally complete but has clear gaps.
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?
Schema description coverage is 50% (only 'to' has a description). The tool description does not add explicit meaning to the parameters beyond what the schema provides. The example demonstrates usage of 'body' but does not formally describe its format or constraints. The description neither compensates for the missing schema description nor adds significant value.
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 'leave a message' and specifies the resource 'the other agent'. It elaborates with concrete scenarios (interface contract, hand-off, heads-up) and provides an example. This distinguishes it from siblings like 'notes_read' (reading) and 'board_post' (posting to a board).
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 gives clear context for when to use the tool: to communicate changes, hand-offs, or heads-ups to the other agent. It advises making messages self-contained and concrete. However, it does not explicitly mention when NOT to use it or point to alternatives (e.g., 'notes_read' for retrieval).
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 must fully disclose behavioral traits. It clearly states that the action is non-executing (write without running), but does not elaborate on idempotency, overwrites, error handling, or any side effects. It adds some value by saying 'so the other agent can see it' (implying persistence), but lacks depth expected for a mutation tool with no annotation support.
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 two sentences long. The first sentence effectively states the purpose and gives concrete examples. The second sentence provides a direct alternative. Every sentence earns its place with no verbosity or redundancy.
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?
The tool has four parameters with poor schema coverage, no output schema, and no annotations. The description covers purpose and usage guidelines but omits critical context: what the tool returns (if anything), parameter format guidance, constraints (e.g., limits on board items), and whether posting is additive or overwrites. Given the complexity of a shared-board communication tool, this is insufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only 'owner' has a description in the schema). The description adds no additional meaning to any of the four parameters: cwd, owner, title, detail. It does not explain that 'title' is a short subject, 'detail' is optional body text, or how 'cwd' influences behavior. For a tool with this low coverage, the description should compensate but fails to do so.
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 uses a specific verb ('put an item') and clearly identifies the resource ('shared board'). It enumerates typical use cases (plan entry, hand-off, announcement) and distinguishes this tool from the sibling 'ag_delegate' by emphasizing that board_post does NOT execute the item. This provides strong purpose clarity and differentiation.
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 states when to use this tool (for non-execution items like plan entries, hand-offs, announcements) and when to use an alternative ('Use ag_delegate instead when you want Antigravity to run it now'). This gives the agent clear decision guidance, especially given the presence of ag_delegate in the sibling list.
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 effectively covers key behavioral traits: the lock action, scope (directory locks cover subpaths), return value (granted vs conflicts), and required conflict response. It lacks details on async/blocking behavior, authentication, or rate limits, but covers the essential operational behavior well.
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 three sentences long, no filler, front-loaded with the core action. Each sentence adds essential information: what it does, scope, and what to do on conflict. Ideal length for a straightforward locking tool.
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 no output schema, the description briefly notes the return format ('granted vs conflicts') but does not detail the exact structure or error cases (e.g., network failure, already locked by same agent). The sibling context helps disambiguate, but the description leaves moderate gaps in what the agent can expect as a response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description only elaborates on 'paths' (files/directories to lock). It does not explain the 'note' or 'task_id' parameters, leaving their purpose unclear. The agent would need to infer or guess their meaning, which is insufficient for a tool with 3 parameters.
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 'Lock' and the resource 'files or directories you are about to edit'. It distinguishes itself from siblings like release_paths and check_paths by specifying the action of claiming/locking for exclusive editing.
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 tells when to use the tool ('before editing'), what to avoid ('if a path is held by the other agent, do NOT edit it'), and provides alternatives ('pick different work or send a note asking for a hand-off'). No ambiguity.
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?
Since no annotations are provided, the description carries full burden. It indicates a read-only operation ('before touching them', 'read the situation') and mentions lower cost, but does not explicitly state that it has no side effects or what happens on failure.
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 sentences with zero wasted words. The purpose and usage guidelines are front-loaded and immediately actionable.
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 simple tool with one parameter and no output schema, the description covers the core functionality and usage context. However, it does not describe the return value (e.g., boolean per path) or clarify what 'free' means, which would be helpful for an agent.
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?
The schema has no parameter descriptions (0% coverage), so the description must compensate. It explains that 'paths' are the specific paths to check, but provides no further details on format, constraints, or semantics beyond the array of strings.
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 checks if paths are free, using the verb 'ask' and 'free', and distinguishes from siblings like claim_paths by noting it's 'cheaper than claiming' when only reading.
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 tells when to use: 'Ask whether specific paths are free before touching them' and 'Cheaper than claiming when you only want to read the situation.' It also implies not to use it when you intend to claim.
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 the full burden. It clearly discloses the async non-blocking nature, the detached background job behavior, and the effect of auto_approve on permissions. It could improve by noting whether there are rate limits or resource implications, but covers the key behavioral traits well.
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 (4 sentences) and front-loaded with the key async behavior. Every sentence adds value, but it could be slightly more structured by grouping parameter guidance at the end.
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 complexity (10 params, no annotations, no output schema), the description does a good job covering the key decisions: async behavior, claim mechanism, prompt construction, auto_approve risk. Minor gaps: no return value description, no error handling guidance, but overall sufficient for a tool that delegates to another 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 coverage is 50%, so the description must compensate. It adds meaning beyond the schema for key parameters: explains prompt must be a complete brief (schema only says 'self-contained brief'), claim means path reservation, auto_approve means skip permissions. It does not document all 10 parameters (cwd, mode, model, effort, add_dirs, timeout_seconds), but the core behavioral params are well explained.
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 starts with a specific verb-resource pair ('Hand a task to Antigravity') and immediately clarifies the async, non-blocking behavior ('returns immediately with a task_id -- it does NOT block'). This clearly distinguishes it from synchronous siblings like coop_status or ag_task_wait.
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 tells the agent to 'keep working on your own part meanwhile' and explains when to use claim ('locks paths for Antigravity up front so you stay off them') and auto_approve ('passes --dangerously-skip-permissions so it can edit unattended'). It also instructs how to write the prompt as a self-contained brief, providing clear when-to and how-to guidance.
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 discloses that the operation is destructive, requires confirm=true, and lists exactly what will be cleared, giving the agent a clear safety profile.
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?
A single, tightly worded sentence delivers the purpose, scope, safety warning, and usage context with no redundant 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?
For a destructive one-parameter tool with no output schema, the description covers what is cleared, when to use it, and the confirmation requirement; it could explicitly mention irreversibility but the 'Destructive' label suffices.
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 schema lists no descriptions, but the description explicitly states that confirm=true is required, clarifying the sole parameter's purpose and correcting the schema's optionality.
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 it clears the whole board and enumerates the elements (tasks, locks, notes, events, presence), distinguishing it from sibling tools like board_update or board_list.
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?
Provides a specific use case ('Use when starting a fresh project') and warns that it is destructive, but does not explicitly name alternative tools or exclusion criteria.
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?
The description clearly discloses the key behavioral trait of blocking execution ('Block until...'), which is a critical piece of information not captured by any annotations (none provided). However, it could additionally mention what happens on timeout (e.g., error return vs. graceful handling), hence a 4 rather than 5.
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 two sentences long, front-loaded with the core blocking behavior, and every part adds value. There is zero waste or repetition.
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 2 parameters, no output schema, and no annotations, the description covers the key semantics (blocking, timeout, preference for non-blocking approach). It could benefit from a brief note on return value or error behavior, but overall it is adequately complete for a simple blocking wait tool.
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 for the lack of parameter info. The description implies the task_id refers to a 'delegated Antigravity task' and hints at the timeout_seconds parameter via 'or until timeout'. This adds meaningful context beyond the bare schema definitions, but does not fully elaborate on each parameter's format or constraints.
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 uses a specific verb ('Block') and resource ('delegated Antigravity task'), clearly distinguishing the tool's synchronous blocking behavior from its sibling ag_task_status. It also specifies the timeout condition, making the tool's purpose unambiguous.
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 states when to use this tool ('only wait when you genuinely cannot proceed without Antigravity's result') and recommends an alternative approach ('Prefer ag_task_status and doing your own work in between'). This provides clear guidance on when not to use it, which is crucial given the blocking nature.
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 exist, so the description carries the full burden. It discloses what information is returned (online status, running tasks, locked paths, etc.), implying a read-only operation. It does not mention whether data is real-time or cached, but for a status tool this is minor. Overall, sufficiently transparent.
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 sentences: first lists the tool's output, second provides usage guidance. Every sentence adds value, no fluff. Front-loaded with the most important 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?
The description lists all the categories of information returned (online agents, running tasks, locked paths, tasks, notes). With no output schema, this is fairly complete. It could be slightly more explicit about the output format (e.g., returns a summary object), but for a simple status check it is adequate.
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?
No parameters exist, and schema coverage is 100%. Baseline for 0 parameters is 4. The description does not need to add parameter info, and it correctly omits any.
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 provides 'one-stop situational awareness' and lists specific items: who is online, running tasks, locked paths, open tasks, and unread notes. This distinguishes it from siblings like coop_reset, ag_delegate, or presence_set, which are more focused.
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 says 'Call this before starting work or editing files so you do not collide with the other agent.' This gives clear when-to-use context and the rationale, making it easy for an agent to decide.
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 MCP server](https://glama.ai/mcp/servers/adeelali4/antigravity-mcp/badges/card.svg)](https://glama.ai/mcp/servers/adeelali4/antigravity-mcp)

Score Badge

Copy to your README.md:

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

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/adeelali4/antigravity-mcp'

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