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

With no annotations, the description carries the burden of disclosing behavior. It reveals key traits: async execution, polling requirement, expected duration (5-20 minutes), and cost ($2-5). This covers the most critical operational behaviors, though it does not mention failure modes or auth specifics.

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

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

Two sentences, front-loaded with the action and immediate next step. No wasted words. Every clause adds value: async nature, return type, polling interval, time and cost expectations.

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

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

Given the tool's complexity (async, expensive, slow) and lack of output schema, the description is complete. It tells the caller what to expect (interaction_id), how to proceed (poll research_get), and sets expectations (time, cost). This is sufficient for correct invocation and orchestration.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-level details beyond what the schema already provides (e.g., defaults, enums, overrides). It does not enhance understanding of the parameters, but also does not need to.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description states a specific verb ('Fire'), a clear resource ('Gemini Deep Research task'), and the asynchronous nature. It distinguishes from siblings by explicitly naming research_get as the polling endpoint, making its role and relationship to the research workflow clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Provides clear operational guidance: returns an interaction_id and instructs to poll every 60s. This implies when to use it (start research) and how to follow up, but does not explicitly compare against alternatives like generate or research_followup. No exclusions are needed given the distinct purpose.

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

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 adds valuable context by stating 'Saves to output_path' (side effect) and mentioning iterative refinement by passing prior outputs. It doesn't cover error conditions or rate limits, but it provides meaningful behavioral insight beyond a minimal description.

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

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

The description is concise and well-structured: two sentences that front-load the primary purpose, then add an important usage note and a side effect. Every sentence earns its place with no unnecessary detail.

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

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

The description covers the core functionality, parameter roles, iterative refinement, and the output side effect. It lacks detail on the 'model' parameter and return value, but given the tool's complexity and the absence of an output schema, it is largely complete for effective selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 25%, so the description must compensate. It does so by explaining prompt ('natural-language instruction'), image_paths ('one or more input images'), and output_path ('Saves to output_path'). However, the 'model' parameter is completely unaddressed, leaving a minor gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description clearly states the tool's function: 'Edit or combine one or more input images with a natural-language instruction'. It lists specific use cases (style transfer, inpainting, compositing) and distinguishes it from sibling tools like generate_image by focusing on editing existing images rather than generating new ones.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description implies when to use this tool: for editing or combining existing images with natural-language instructions. The phrase 'Pass a prior output back in to keep refining' explicitly highlights an iterative use case. It doesn't explicitly state alternatives or exclusions, but the context makes the primary use case clear.

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

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

No annotations are provided, so the description carries the full burden. It discloses the side effect of writing to a JSON file and the return of path and dimensions, but does not mention overwrite behavior, authentication needs, or potential errors. Partial transparency.

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

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

Two concise sentences: the first states the purpose, the second states the side effect and return value. Every word earns its place, with no redundancy.

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

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

No output schema exists, so the description must explain return values – it does (path and dimensions). It covers the core workflow well but omits the 'model' parameter and details about the JSON file contents. Overall sufficient with minor gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 75% (text, texts, and output_path have schema descriptions). The description adds the 'one or more texts' clarification but does not explain the 'model' parameter or output_path default beyond the schema. Provides marginal added value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description uses a specific verb 'Create' with a clear resource 'embedding vectors' and scope 'for one or more texts with Gemini'. It clearly distinguishes from sibling tools which are about image/video generation, speech, or research.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description provides clear context that this tool is for embedding texts, which is enough given no sibling tool handles embeddings. It doesn't explicitly state when not to use it, but the context is unambiguous and no alternatives exist.

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

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

No annotations are provided, so the description must carry the full behavioral burden. It only states what the tool does (generate text) and does not disclose return format, non-determinism, authentication requirements, rate limits, or the effect of the json parameter. This is a significant gap for a generative API call.

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

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

The description is a single, front-loaded sentence that wastes no words. It states the action, the domain, and the tool's role in two concise clauses.

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

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

The description is adequate for basic invocation (prompt is required and clear), but with no annotations and no output schema, it leaves unstated details about response format and the behavior of optional parameters like json and system. It is minimally viable but not exhaustive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers all four parameters with descriptions, achieving 100% schema description coverage. The tool description adds no extra parameter-level detail beyond the schema, so the baseline of 3 applies per the rubric.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description clearly identifies the action ('Generate text with Gemini') and the resource/scope ('prose, code, chat, reasoning'). The phrase 'core generative call' distinguishes this from sibling tools like generate_image and generate_video, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description provides clear context by enumerating text generation use cases (prose, code, chat, reasoning) and calls it the 'core generative call,' implying this is the primary text tool. It does not explicitly list excluded alternatives, but the sibling tool names (generate_image, generate_video, speak) make the boundary obvious enough.

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

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

No annotations are provided, so the description carries the transparency burden. It discloses a key side effect ('Saves to output_path') and the model used, but it does not explain whether existing files are overwritten, what the function returns, or any error conditions. This adds some context but leaves significant behavioral details undisclosed.

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

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

The description is extremely concise: two short sentences, no wasted words. The main action and key side effect are front-loaded. Every word earns its place.

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

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

For a tool with no output schema and no annotations, the description is minimal but covers the core action and output location. However, it is missing important information for reliable invocation, such as return behavior, file handling (overwrite vs. error), and any model constraints. This is adequate for a simple tool but has clear gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 33% (only output_path has a description). The description mentions prompt implicitly ('text prompt') and output_path explicitly, but it does not clarify the 'model' parameter at all. It says 'with Gemini (Nano Banana)', which may suggest a fixed model, leaving the role of the model parameter ambiguous. The description fails to compensate for the low schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description clearly states the tool's function: 'Generate an image from a text prompt' with a specific model ('Gemini (Nano Banana)') and the save location. This is a specific verb+resource pairing that distinguishes it from siblings like edit_image and generate_video.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description implies usage: use this when you need to create an image from a text prompt and save it to a file. However, it does not explicitly mention when to prefer this over 'edit_image' or 'generate', nor does it provide any exclusions or alternative guidance.

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

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

With no annotations, the description carries full burden. It discloses that the tool is asynchronous, returns an operation name rather than the video, and flags 1-3 minutes duration and per-second billing. This is valuable behavioral context beyond the schema, though it doesn't cover error handling or prerequisites.

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

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

The description is a compact two sentences: the first states purpose, the second covers async flow, polling, time, and cost. Every sentence earns its place, with no fluff or redundancy.

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

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

Given no output schema and no annotations, the description covers the essential flow: returns an operation name, poll video_status, and expectations for time/cost. It does not explain the model parameter or error cases, but for a simple async generation tool, this is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, so the description must compensate. It clarifies that 'prompt' is a text prompt, and the mention of 'Veo' hints at the 'model' parameter. However, the optional 'model' parameter's allowed values or default behavior are not explicitly described, leaving some ambiguity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description clearly states it generates a video from a text prompt using Veo, with a specific verb ('Generate') and resource ('video'). It distinguishes from siblings like generate_image (image) and video_status (polling) by explicitly naming the action and async behavior.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description gives clear context on how to use the tool: call it, get an operation name, then poll video_status. It sets expectations for time and billing. It does not explicitly exclude alternatives for images, but the purpose and async flow provide sufficient guidance.

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

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 provides useful details: 'Returns the answer inline, saves nothing.' This conveys the return behavior and side-effect profile (non-persistent), going beyond a simple statement of intent. It does not cover error conditions or auth, but for a simple follow-up tool, the transparency is sufficient.

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

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

The description is exceptionally concise, using two short sentences with no wasted words. It front-loads the core purpose and then adds key behavioral details. Every word earns its place.

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

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

Given the tool's simplicity (2 params, no output schema, no annotations), the description is quite complete. It covers what the tool does, the key behavior (inline answer, no saving), and implies the need for a prior interaction ID. It falls short of describing edge cases or what happens if the previous interaction does not exist, but for most use cases, it provides sufficient context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 effectively maps both parameters: 'prompt' is the follow-up question implied by 'Ask a follow-up', and 'previous_interaction_id' is the completed research task to reference. This adds meaning beyond the bare schema, though it could be more explicit about formatting or constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description clearly states the tool's purpose: 'Ask a follow-up on a completed research task without re-running it.' It uses a specific verb ('ask') and resource ('research task'), and explicitly differentiates from re-running, which distinguishes it from sibling tools like deep_research or research_get.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description provides clear context for when to use the tool ('on a completed research task' and 'without re-running it'), implying it is for follow-ups on existing work. However, it does not explicitly mention when not to use it or name alternative tools for new research tasks, so it lacks explicit exclusions.

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

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

With no annotations, the description carries the full burden. It discloses the output behavior (saves cited Markdown to output_dir, returns path) and a key requirement (pass same format/citation/tone). However, it does not describe what happens when the task is still running (e.g., returns pending status), any error conditions, or side effects beyond saving the file. It is moderately transparent but not comprehensive.

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

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

The description is two sentences, front-loaded with the action ('Poll a running research task'), and every clause adds value. It avoids redundancy with the schema and is appropriately sized for the tool's complexity.

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

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

For a polling tool with 7 parameters and no output schema, the description covers the core workflow: poll, save, return path, and reuse parameters. It does not explain the output_filename parameter or the behavior before task completion, but for a straightforward polling tool the description is largely sufficient. The missing details are minor given the sibling context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 43%, but the description adds significant meaning beyond the schema by telling the agent to 'Pass the same format/citation/tone used to start it.' This links the optional parameters (format, citation_style, tone) to the originating research task, which is crucial for correct invocation. It also implies interaction_id ties to deep_research. This compensates well for the schema gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description uses a specific verb ('poll') and identifies a clear resource ('a running research task'), distinguishing it from siblings like deep_research (likely starting) and research_followup (likely follow-up). It also states the outcome (saves Markdown report and returns path), fully clarifying its role.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description clearly indicates when to use: when a research task is already running, not to start a new one. It provides context ('Poll a running research task') and a key instruction about reusing format/citation/tone, but does not explicitly exclude alternatives or mention when not to use it. Thus it has clear context but no formal exclusions.

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

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

No annotations are provided, so the description must disclose behavior. It mentions saving a WAV file, but this duplicates the output_path schema description. It does not explain return values, overwrite behavior, authentication needs, or failure modes.

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

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

The description is short and front-loaded, but the parenthetical note about music generation is a roadmap detail that does not help an agent invoke the tool. It adds noise without practical value.

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

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

For a tool with no annotations, no output schema, and partial parameter coverage, the description is insufficient. It omits key operational details such as model behavior, voice selection consequences, and expected response format.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 50%, leaving 'text' and 'model' undocumented in the schema. The description does not clarify these parameters, such as supported text formats or model options. The 'voice' parameter has a schema description, but the description adds no extra semantic value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description clearly states 'Text to speech with Gemini TTS' and notes it saves a WAV to output_path. This distinguishes it from sibling tools focused on images, video, research, and search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

No usage guidance is provided about when to choose this tool over siblings or what prerequisites are needed. The description only states what the tool does, not when it should be used.

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

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

No annotations are provided, so the description carries full burden. It states the core behavior (poll and download) but does not disclose important traits like whether the tool blocks until the generation completes, what it returns (if anything), error handling, or behavior if the generation fails. This is insufficient for a polling tool.

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

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

The description is a single sentence that is front-loaded and free of fluff. Every word contributes meaning, making it appropriately concise.

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

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

Given no annotations, no output schema, and only two parameters, the description is too sparse. It does not explain the polling behavior (e.g., blocking vs. non-blocking), return value, or failure modes. For a status tool, this incomplete context could leave an agent uncertain about how to use it effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with both parameters clearly described in the schema. The description adds little beyond the schema—just affirms that it downloads to output_path and uses the operation name. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description clearly states the tool's function: 'Poll a Veo generation by its operation name. When done, downloads the mp4 to output_path.' It uses a specific verb (poll) and resource (Veo generation), and the download action distinguishes it from sibling tools like generate_video or generate_image.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description implies usage after generating a video (polling a generation), but does not explicitly say 'use after generate_video' or mention alternatives. The schema adds context by noting 'operation' comes from generate_video, but the description itself lacks explicit when-to-use guidance.

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