Server Quality Checklist

Tool Scores

• list_generationsA
  4.2/5.0
  Behavior4/5

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

  Annotations already indicate idempotent and non-destructive behavior. The description adds valuable behavioral context: it returns public URLs, models, prompts, and is newest-first, which goes beyond the annotations. It does not mention pagination beyond the limit parameter, but overall it provides sufficient transparency.

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

  Conciseness5/5

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

  The description is a single, well-structured sentence that front-loads the core purpose and includes key details. Every word contributes meaning without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (one optional parameter, no output schema, simple behavior), the description is largely complete. It explains what is returned and in what order. It could mention that it lists all recent generations without filters, but it is sufficient for most use cases.

  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%, with the 'limit' parameter fully documented (max 100, default 20). The description does not add additional meaning beyond what the schema provides, so it meets the 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 clearly specifies the action (browse), resource (recently generated media), and details (public URLs, models, prompts) with ordering (newest first). It effectively distinguishes from sibling tools like generate_image, generate_video, and get_video which are for creation or specific retrieval.

  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 appropriate usage for browsing recent media, but does not explicitly state when not to use it or provide direct comparison to alternatives. The context from sibling names helps, but explicit guidance would improve clarity.

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

• get_videoA
  4.5/5.0
  Behavior4/5

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

  Annotations already indicate idempotent and non-destructive hints. The description adds valuable context: while running it returns status, once completed it downloads and caches the MP4 and returns a public URL. This goes beyond what annotations provide.

  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, front-loaded with the core purpose. Every sentence adds value with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite no output schema, the description explains what the tool returns (status or URL) and mentions caching. With only one parameter and clear annotations, this is fully complete for its complexity level.

  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 single parameter video_id has a schema description coverage of 100%. The description adds extra meaning by specifying that the video_id comes from generate_video, helping the agent source the correct 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 tool checks a video generation job started by generate_video and distinguishes itself from siblings like generate_video and list_generations by detailing the behavior of returning status or the final URL.

  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 states when to use the tool (to check a job from generate_video) and notes it is safe to call repeatedly. It does not explicitly list when not to use it, but the context is clear given the sibling tools.

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

• generate_imageA
  4.7/5.0
  Behavior5/5

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

  The description adds significant value beyond annotations (openWorldHint, destructiveHint) by explaining the synchronous behavior, that it returns public URLs (and to pass them onward), and mentions the models used. No contradictions.

  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 four sentences with no wasted words. It is front-loaded with the core purpose and models, then covers return format, synchronicity, and model details. Every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the 3 parameters, no output schema, and no nested objects, the description is complete. It explains the return format (public URLs), synchronicity, model choices, and how to handle the output. No gaps.

  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?

  With 100% schema coverage, the description still adds meaning: for 'prompt' it advises specificity on subject/style/composition/lighting; for 'model' it adds context on when to use each variant. The 'n' parameter does not get extra description, but overall adds 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 'Generate one or more images from a text prompt' providing a specific verb and resource. It distinguishes from sibling tools like generate_video by explicitly mentioning images and the model names.

  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 contextual usage guidance by describing the two models with their trade-offs (quality vs. speed) and the synchronous nature. It implicitly differentiates from siblings, but does not explicitly 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.

• generate_videoA
  4.8/5.0
  Behavior5/5

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

  Annotations already show non-destructive and open-world. Description adds key behavioral context: asynchronicity, immediate video_id return, polling requirement, and cost per second. No contradictions.

  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?

  Compact single paragraph of 4 sentences, front-loaded with async nature, then polling, optional image, and model cost. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Covers async job, polling, model selection, optional image, and output format (video_id then MP4). Lacks error/rate limit details but sufficient for typical use.

  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 covers 100% of parameters with descriptions. Description adds value with cost implications for model choice, default seconds, and use of image_url for image-to-video. Slightly above 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?

  Clear verb 'Start an ASYNCHRONOUS video generation job' with specific resource 'Google's Veo models'. Distinguishes from siblings like get_video (polling) and generate_image (static).

  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 tells when to use (async video generation), how to get results (poll with get_video every ~10s), and model selection advice (veo-3.1 for quality, veo-3.1-lite for drafts). Context for sibling tools is clear.

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