Server Quality Checklist

Tool Scores

• pingC
  2.2/5.0
  Behavior2/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. 'Echo' only restates the core action and implies the prompt is returned, but it does not state side effects, safety traits, or response format. For a trivial tool this is minimally acceptable, but it still lacks explicit behavioral transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  While the description is extremely concise, it is under-specified rather than efficiently structured. A single word without context is not a well-formed definition, and the conciseness is the result of omission rather than careful pruning.

  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?

  Despite the tool's low complexity, the description leaves out important context such as the intended use (e.g., connectivity test or echo of user input) and the fact that the given prompt will be returned. There is no output schema, so the description should clarify return behavior, but it does not.

  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 already has 100% coverage with the description 'Message to echo' for the prompt parameter. The description 'Echo' adds no additional meaning beyond what the schema provides, 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.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description is a single word, 'Echo', which names an action but does not specify the resource or what is echoed. It is not a complete statement of purpose and leaves ambiguity about whether it echoes the prompt parameter or something else. This is more like a vague fragment than a clear tool definition.

  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 provides no guidance on when to use this tool versus any of the sibling tools. There is no mention of typical use cases, prerequisites, or exclusions. An agent receives no context to decide whether to call ping instead of ask-gemini or brainstorm.

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

• ask-geminiC
  2.9/5.0
  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 behavioral disclosure. It mentions 'code changes,' which hints at mutation, but does not clarify whether the tool applies edits directly, requires approval, or has side effects. There is also no mention of authentication, rate limits, or safety behavior, leaving a significant transparency gap.

  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 front-loaded sentence with minimal waste. The phrase 'massive context window' is somewhat vague and adds only general marketing value, but the structure is tight and readable.

  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?

  Despite having 12 parameters, no output schema, and no annotations, the description is only one sentence. It omits critical operational context such as what the response looks like, how mode/changeMode/sandbox affect behavior, when to use it versus sibling tools, and whether 'code changes' means actual file modification.

  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%, so the input schema already documents all 12 parameters thoroughly. The description adds no parameter-specific meaning beyond the schema, so the baseline of 3 applies.

  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 uses a specific verb ('Query'), names the resource ('Google Gemini'), and lists concrete use cases: analysis, reasoning, architectural planning, and code changes. However, it does not explicitly differentiate from siblings like gemini-plan or brainstorm, which likely share some of these purposes.

  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 explicit guidance is given for when to use ask-gemini versus alternatives. The phrase 'massive context window' implies suitability for large-context tasks, but there are no stated exclusions, prerequisites, or comparisons to sibling tools such as gemini-plan, brainstorm, or gemini-doctor.

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

• gemini-imageA
  3.7/5.0
  Behavior3/5

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

  No annotations are present, so the description carries the burden of behavioral disclosure. It does disclose the optional side effect of exporting the file into the project workspace, but it does not explain what happens when outputPath is omitted, whether files are overwritten, or how the generated image is returned to the agent.

  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 filler. It states the core purpose first, then the key capabilities, making it easy for an agent to parse quickly.

  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 only one required and two optional parameters, the schema plus description cover the basics needed to make a call. However, with no output schema and no annotations, the description does not clarify what the agent should expect as a return value or what occurs when no outputPath is provided, leaving a moderate completeness gap.

  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%, so the schema already provides full parameter documentation. The description mentions aspect ratio and workspace export at a high level but adds no meaning beyond what the schema already defines.

  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 ('Generate images'), the tool/provider ('Google Gemini & Imagen'), and the input ('text descriptions'). This strongly signals image generation and distinguishes it from the text/planning/model sibling tools, though it does not explicitly name an alternative tool.

  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: use this tool when you need to create an image from a text prompt. It does not explicitly list when not to use it or point to alternatives, but the purpose is obvious enough that an agent can infer appropriate usage.

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

• brainstormA
  3.8/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full behavioral burden. It discloses a meaningful internal pipeline: dynamic context gathering, domain context integration, idea clustering, feasibility analysis, and iterative refinement. This goes well beyond a vague 'generates ideas' and gives the agent a realistic sense of how the tool behaves, though it does not describe output format or potential state changes.

  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 one compact sentence with a clear front-loaded purpose followed by a telegraphic capability list. It wastes few words, though the arrow-plus-list construction is slightly awkward and terms like 'dynamic context gathering' are somewhat vague, keeping it just below a perfect 5.

  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 nine parameters, no output schema, and no annotations, the description stays high-level and does not explain what a successful result looks like, when to prefer this over ask-gemini, or how parameters like effort and methodology alter behavior. Schema descriptions compensate for parameter understanding, so this is adequate but not 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%, so the input schema already documents all nine parameters with meanings, defaults, enums, and examples. The tool description itself adds very little parameter-level detail, but because the schema is thorough, the baseline 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 opens with a specific verb and object, 'Generate novel ideas,' and then reinforces the resource with a distinctive capability list: 'Creative frameworks (SCAMPER, Design Thinking, etc.), domain context integration, idea clustering, feasibility analysis, and iterative refinement.' This clearly separates it from generic siblings like ask-gemini or ping by describing a structured brainstorming workflow rather than a general-purpose query.

  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 when to use the tool—when the user needs novel ideas or structured brainstorming—but it never explicitly says when not to use it or which sibling alternative to prefer. There are no exclusions or routing cues, so the agent must infer usage from the word 'brainstorm' and the creative-framework references.

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

• HelpA
  4/5.0
  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. It conveys that the tool returns help information and hints at being a read-only operation, but it does not disclose output format, potential side effects, or what 'active backend' entails. This is acceptable for a simple help tool but not rich.

  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, compact sentence with no filler. It front-loads the core message and every word contributes to understanding the tool's 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?

  For a zero-parameter, no-output-schema help tool, the description is sufficiently complete. It tells the agent what the tool does and its scope, though it could optionally mention that no arguments are required or expected.

  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?

  There are zero parameters and the schema is empty, so the baseline is 4. The description adds meaningful context by indicating the help is scoped to the active backend, which is all that is needed given no parameters exist.

  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 ('Receive') and a concrete resource ('CLI help information'), scoped to the 'active Gemini backend'. This clearly distinguishes it from the sibling tools, which perform other actions like asking questions or planning.

  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 'for the active Gemini backend' implies the tool is used when the agent needs CLI help related to the currently selected backend. However, it does not explicitly mention when to prefer this over alternatives or any exclusions, leaving the usage context mostly inferred.

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

• fetch-chunkA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the behavioral burden. The word 'Retrieves' signals a read operation, and 'cached chunks' implies a non-destructive lookup from previously stored response data. It does not detail cache expiration or whether chunks can be re-fetched, but the core behavior is clear.

  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 short sentences deliver the core behavior and the intended usage context with no wasted words. The primary action is front-loaded and the follow-up guidance is 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?

  The description gives enough context for a simple two-parameter fetch tool: where the cacheKey comes from and when to call it. With no output schema, it could have clarified the response shape or chunk count, but the invocation path is adequately 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%, so the parameters are already well documented. The description adds context about when the cacheKey/chunkIndex are used, but it does not provide substantial extra 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 states a specific verb and resource: it retrieves cached chunks from a changeMode response. It also clarifies the tool's role as the follow-up mechanism for partial changeMode responses, making its purpose unmistakable.

  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 to use this tool 'after receiving a partial changeMode response' and positions it as the way to get subsequent chunks. It does not mention exclusions or alternatives, but no directly competing sibling tool is apparent.

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

• gemini-doctorA
  4.2/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral disclosure burden. It lists what is checked (installation, backend, version, readiness) but does not explicitly state whether the tool is read-only, whether it modifies anything, what output format to expect, or whether it requires any prerequisites. 'Diagnose and verify' strongly implies non-mutating, but this is left implicit.

  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 sentence with no filler. The action verb is front-loaded, and every phrase adds a distinct diagnostic aspect: installation, backend, version, and readiness.

  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 zero-parameter diagnostic tool with no output schema and no annotations, the description covers the key dimensions an agent needs to understand its purpose. It does not state what the verification output looks like or how to interpret results, but the low complexity makes that a minor gap.

  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, so there is no parameter documentation burden. Schema coverage is trivially complete, and the description does not need to explain parameters that do not exist.

  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 specific verbs ('diagnose', 'verify') and names exact resources: Gemini CLI / Antigravity CLI (agy) installation, active backend, CLI version, and system readiness. This clearly distinguishes it from sibling tools like ask-gemini or gemini-image, which are content-generation 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?

  The diagnostic scope clearly implies use when checking environment health or CLI readiness, which is distinct from the content-generation siblings. However, it does not explicitly state when not to use it or name alternative tools for similar checks.

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

• gemini-modelsA
  4.4/5.0
  Behavior4/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. The verb 'Lists' signals a read-only operation, and 'active backend status' discloses that it queries live backend state. It does not mention rate limits or authentication, but for a zero-parameter discovery tool these are low-risk omissions.

  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 efficient sentence that fronts the core action ('Lists available Gemini models') and then packs the important output dimensions into a compact list. Every phrase adds information without repetition or filler.

  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 no-parameter, no-output-schema tool, the description covers what the tool returns: models, defaults, reasoning capabilities, and backend status. It could add a bit more about output format or how status is represented, but nothing essential is missing for invoking it correctly.

  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 is an empty object with 100% coverage, so there is nothing for the description to add about parameter meaning. The baseline of 4 for no-parameter tools 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 uses a specific verb ('Lists') and identifies a distinct resource ('available Gemini models'), then enumerates the exact content categories returned: default selections, reasoning capabilities, and active backend status. This clearly separates it from action-oriented siblings like ask-gemini, gemini-plan, and gemini-image.

  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 makes the use context clear: an agent should call this when it needs to know which Gemini models are available, which are defaults, what reasoning capabilities exist, or whether the backend is active. It does not explicitly name alternatives or exclusions, but no sibling tool appears to cover model discovery, so the context is sufficient.

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

• gemini-planA
  4.4/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the burden. It clearly states the tool generates blueprints, dependency analysis, and risk assessments without modifying code, which sets accurate expectations. It doesn't disclose response format details, but for a planner tool this is reasonable.

  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 waste. Front-loaded with the tool's identity and purpose, then a clear boundary statement. The word count is appropriate for the tool's complexity.

  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 planner tool with a fully documented schema and no side effects, the description is complete enough. It lacks explicit return format or output examples, but given the absence of an output schema and the role of a planner, the description covers the essential context.

  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 100%, so the schema already documents all 6 parameters. The description adds meaningful context about 'without modifying code' and 'reasoning effort' semantics via the description text, going slightly beyond the schema's structural definitions.

  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 ('planner'), resource ('Architectural and implementation planner'), and explicitly distinguishes itself from code modification ('without modifying code'). This clearly differentiates it from siblings like ask-gemini, brainstorm, and gemini-doctor.

  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 implies usage for architectural tasks, complex features, or refactoring goals via the parameter schema, and the 'without modifying code' phrase signals when not to use it. It doesn't explicitly name alternatives, but the sibling list and planner framing provide enough context.

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