Server Quality Checklist

Tool Scores

• get_gemini_taskA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds that the tool returns status and final result, which is useful context, but it doesn't disclose potential error states, whether the task must be completed, or any behavior around unfinished tasks.

  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, front-loaded sentence with no wasted words. It immediately states the action, the resource, and the parameter without redundant phrasing.

  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 read-only lookup with one parameter and annotations covering safety, the description is mostly complete. It names the high-level return content (status and final result), though it lacks output shape details and relationship to sibling tools. These are minor gaps given the low complexity and available annotations.

  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%, but the single parameter job_id is self-explanatory and is further constrained by uuid format and pattern. The description confirms job_id is the lookup key, yet it doesn't explain where the id comes from or what values are valid beyond the schema pattern, so compensation for missing schema descriptions is partial.

  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 a specific verb (查询/query), a resource (后台 Gemini/Teamwork 任务状态和最终结果), and the key parameter (job_id). It is clear and distinct from mutation siblings like start_gemini_task and cancel_gemini_task, though it doesn't explicitly differentiate from antigravity_status.

  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 usage when you need the status or final result of a Gemini task by job_id, but it provides no explicit guidance on when not to use this tool or which sibling to choose instead. It doesn't mention that job_id would come from start_gemini_task or delegate_to_gemini.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cancel_gemini_taskA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already state destructiveHint=true and readOnlyHint=false, matching the terminate semantics. The description adds useful context by scoping cancellation to tasks 'still running in the current MCP process', which clarifies that tasks in other processes or already-completed tasks are not affected. It does not describe side effects like partial work loss, but the destructive annotation covers the core safety signal.

  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 concise sentence, front-loaded with the action verb, and contains no filler. It efficiently communicates scope, target resource, and the action.

  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 one-parameter cancellation tool, the description, combined with destructiveHint and the 'current MCP process' scoping, is mostly complete. The main gap is not stating that job_id should come from a starting/delegating tool, but this is inferable from siblings and not critical for invoking the tool.

  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%, and the description never mentions job_id or explains where it comes from. The parameter name and UUID format are self-explanatory to some degree, so the tool is callable, but the description adds no meaning beyond what the schema already provides.

  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 '终止' (terminate) with a clear resource: Gemini/Teamwork background tasks still running in the current MCP process. This clearly distinguishes the tool from siblings like start_gemini_task and get_gemini_task, which have different actions.

  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 phrase '仍在运行' implies the tool should be used for running tasks, which gives some usage context. However, there is no explicit when/when-not guidance, no mention of alternatives such as get_gemini_task for finding the job_id, and no note about what to do if the task is already finished.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• open_dashboardA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context by noting that the tool opens a browser window as a side effect and that the dashboard shows real-time data. This goes beyond the annotations and helps the agent set user expectations, though it does not address possible failures or return behavior.

  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, compact sentence that front-loads the main action and purpose. There is no redundant wording or repetition of schema 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 tool is simple, has no required parameters, and annotations cover its read-only, non-destructive nature. The description adequately explains what the dashboard shows and that it opens in the default browser, though it does not mention what the tool returns after opening, which would be slightly more 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 100% and the single auto_open parameter already includes a clear description and default value. The tool description adds no further parameter-specific detail, but the schema carries the semantic weight, so the baseline score of 3 is appropriate.

  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 states a specific verb (open), a clear resource (standalone visualization dashboard / Web UI), and its purpose (real-time display of subagent workflows, action streams, and physical logs). It is clearly distinguishable from the sibling task-management tools like start_gemini_task or cancel_gemini_task.

  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 usage context: an agent would call this when the user wants to visually monitor subagent activity. However, it does not explicitly state when to prefer it over alternatives or when not to use it, and it names no sibling tools as alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• delegate_to_geminiA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint=false, destructiveHint=true, openWorldHint=true), the description adds the critical blocking trait '调用会等待结果' (the call waits for results), which materially affects agent timeout planning. It also discloses prompt transformation behavior — retaining the prompt, appending the absolute working directory, and enabling slash-command expansion for /teamwork-preview. These are genuine behavioral disclosures not encoded in the annotations.

  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?

  Three dense sentences with zero filler. Sentence one front-loads purpose and default model; sentence two covers prompt handling mechanics; sentence three delivers the most decision-relevant fact (blocking behavior) and the sibling routing. Every sentence earns its place, and the critical sync/async guidance is positioned as the concluding takeaway.

  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 13-parameter, destructive, open-world tool with no output schema, the description covers the core UX (sync vs async, prompt handling) but leaves meaningful gaps: there is no description of the return value (conversation_id is only hinted at in the schema), no timeout or failure behavior, and no explicit warning about destructive potential beyond the annotations. Adequate, but incomplete for an agent that must decide execution parameters and interpret results.

  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 100%, and the per-parameter descriptions are unusually rich: prompt already explains slash-command preservation and cwd appending with an example, permission_mode explains the auto-approve rationale, and timeout_seconds already carries Teamwork long-task guidance. The main description adds only marginal context (default model name, synchronous wait) that the schema largely implies, so the baseline 3 applies.

  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 states a specific verb+resource pair — '通过 Antigravity CLI 调用 Gemini' (invoke Gemini via Antigravity CLI) — and names the default model. It differentiates from the async sibling start_gemini_task by explicitly declaring the synchronous behavior ('调用会等待结果') and routing long tasks elsewhere. The title '委派任务给 Gemini 子代理' reinforces the delegation semantics.

  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 an explicit when-not condition with a named alternative: '预计超过数分钟的 Teamwork 任务请使用 start_gemini_task' (for Teamwork tasks expected to exceed several minutes, use start_gemini_task). This cleanly resolves the primary sync/async fork an agent faces. However, it offers no differentiation from the other lifecycle/status siblings (get_gemini_task, cancel_gemini_task, antigravity_status, open_dashboard), though those are largely self-evident from their names.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• start_gemini_taskA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark this tool as non-read-only and destructive, so the description does not need to restate mutation risk. It adds useful behavioral context beyond the annotations: the tool returns immediately with a job_id and the background task depends on the current MCP service process staying alive. No contradiction with the annotations.

  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 compact sentences with the core behavior front-loaded: background start and immediate job_id return. The second sentence adds the use case, follow-up tool, and process-lifetime caveat without filler 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?

  For a 13-parameter background-launch tool with no output schema and destructive annotations, the description supplies the essential runtime model: immediate job_id, suitability for long tasks, polling via get_gemini_task, and the service-lifetime dependency. The remaining details are already in the schema. It could add an explicit contrast with delegate_to_gemini, but overall it is sufficiently 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?

  The input schema has 100% description coverage across all 13 parameters, including enums, defaults, the prompt format, and the working directory requirement, so the schema carries the parameter semantics. The description adds no parameter-level detail beyond the intended use case, which is fine under the high-coverage baseline.

  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 states a specific verb and resource: it launches an Antigravity/Gemini task in the background and immediately returns a job_id. It also scopes the tool to long-running /teamwork-preview tasks and names get_gemini_task as the follow-up, so an agent can distinguish it from the query and dashboard 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 Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives clear when-to-use context by saying the tool is suitable for long-running tasks like /teamwork-preview and explicitly instructs the agent to query results later with get_gemini_task. It also flags the operational prerequisite that the MCP service process must remain running. However, it does not explicitly contrast with delegate_to_gemini or state when not to use this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• antigravity_statusA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already cover the read-only, non-destructive, open-world safety profile. The description adds useful behavioral scope by stating exactly what is inspected: CLI version, available models, and the presence of the default model. No contradiction with annotations.

  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 concise sentence with the action and checked resources front-loaded. It contains no filler, tautology, or unnecessary background.

  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?

  For a zero-parameter, read-only status tool with supporting annotations, the description names all relevant checks and is sufficient for an agent to select and invoke it correctly. The lack of an output schema is not a significant gap given the low invocation 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?

  The tool has zero parameters and the schema contains an empty properties object, so there is no parameter detail to document. The description appropriately focuses on what the status check reports rather than inputs.

  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 ('检查') and concrete resources: AGY CLI version, available models, and whether the default model gemini-3.8-flash-high exists. This clearly distinguishes it from sibling task-management tools like delegate_to_gemini or cancel_gemini_task.

  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?

  Usage is implied from the tool's nature as a status/health-check command, but the description does not explicitly say when to use it versus alternatives or provide any exclusions. No comparable status-checking sibling is named, so the guidance is implicit rather than explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.