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

Annotations already supply idempotentHint=true and destructiveHint=false. The description adds relevant context by clarifying the operation configures authentication and by pointing to the key source. It does not detail persistence or overwrite behavior, but the annotation coverage reduces the need.

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 short sentences, no filler: the action is front-loaded and the key-source instruction earns its place. Nothing extraneous is present.

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 one-parameter, idempotent configuration tool with an output schema and full schema coverage, the description is complete. It gives the single input, its source, and the purpose; an agent has what it needs to invoke it correctly.

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 already fully documents apiKey with the same Google AI Studio URL and a minLength constraint, so schema coverage is 100%. The description only repeats the source link rather than adding new parameter meaning, which lands at the baseline 3.

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 action ('Set') on a specific resource ('Gemini API key') and ties it to 'authentication'. That scope is clearly distinct from the sibling image/model/status tools, so an agent can tell it apart.

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?

It communicates the intended use case—setting up authentication—and tells the user where to obtain the key. There are no overlapping sibling tools to exclude, though it could more explicitly say to run this before other Gemini API calls.

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?

The description discloses an important behavioral trait beyond the annotations: the operation depends on prior session state ('last generated or edited image') and returns a file path. This is meaningful context beyond readOnlyHint, openWorldHint, and destructiveHint. It does not, however, explain what happens if no prior image exists or whether the original file is replaced.

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?

Three short sentences with no filler. The description front-loads the core action, states the prerequisite, and ends with the return value. Every sentence 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 two-parameter tool with full schema coverage and an output schema, the description provides the core behavior, the prerequisite, and the return artifact. It leaves minor edge conditions to inference, such as failure behavior when no prior image exists, but overall the agent has enough context to invoke the tool correctly.

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 schema already documents the prompt and model parameters, including a prompt example and model enum values. The description adds little beyond calling the prompt 'a new prompt' and connecting it to the last generated/edited image. Baseline 3 is appropriate because the schema carries the parameter documentation burden.

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 and resource: 'Refine the last generated or edited image with a new prompt.' It clearly differentiates this from generate_image and edit_image by focusing on the existing last image rather than creating or editing from scratch. An agent can immediately understand the tool's role in the image workflow.

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 an explicit prerequisite: 'Must call generate_image or edit_image first.' This makes the sequential usage context clear. It does not explicitly state when not to use this tool or contrast it with alternatives, but the prerequisite plus 'last generated or edited image' strongly implies the intended use case.

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?

The annotations already convey that this is not read-only and not idempotent. The description adds useful behavioral detail by mentioning that the result is saved and its file path returned, but it does not explain whether the original file is overwritten or a new file is created. This is a moderate gap, not a contradiction.

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?

Three tight sentences with no filler. The core action, optional input, and return value are all stated efficiently and in a sensible order.

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 complete schema coverage, an output schema, and clear annotations, the description captures the essential behavior well. It could be slightly stronger by noting how this differs from continue_editing or clarifying save behavior, but overall an agent has enough to call the tool correctly.

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 schema already documents all four parameters in detail. The description adds a small clarification that referenceImages are for 'style guidance', which is consistent with the schema. It does not add substantial new parameter 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.

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

The description opens with a specific verb and resource: 'Edit an existing image using a text prompt.' This clearly differentiates the tool from the sibling generate_image, which is about creating new images, and it also states the return behavior ('Returns the file path of the saved result').

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: use this tool when editing an existing image, and optionally supply reference images for style guidance. It does not explicitly name alternatives or state when not to use it, but the 'existing image' framing makes the intended use apparent relative to generate_image.

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?

Annotations already signal that this is a mutating operation. The description adds useful behavioral context by naming the model family (Google Gemini image models), the side effect of saving the image, and the return form (file path). No contradiction with annotations exists.

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, compact sentence that front-loads the core action, indicates the model provider, and states the return value. It contains no filler, repetition, or vague phrasing.

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 simple generation tool with fully documented parameters and an output schema, the description covers the essential behavior and result. It does not mention setup requirements such as authentication, but the presence of a configure_auth sibling and the overall context make this a minor gap rather than a blocking one.

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 100%: all three parameters already have meaningful descriptions, enums, defaults, and an example for prompt. The description adds no parameter-specific detail, but it does not need to because the schema carries the full semantic load.

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 and resource: 'Create a new image from a text prompt', which clearly differentiates this from editing-oriented siblings like edit_image and continue_editing. It does not explicitly name those alternatives, so it stops short of a 5, but the purpose is 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 usage context is implied: this is for generating a brand-new image from a text prompt, which distinguishes it from image-editing tools. However, there is no explicit guidance about when not to use it or which sibling to choose for editing or continuation tasks.

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?

Annotations already mark this as read-only, idempotent, and non-destructive. The description adds meaningful behavioral detail by specifying the scope ('most recently generated or edited') and enumerating the returned metadata fields, which is especially useful since there is no output schema.

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?

A single, front-loaded sentence states the action, resource, and return fields without any filler. Every part earns its place, and the most important qualifier ('most recently') appears early.

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 no-argument, read-only tool, the description adequately covers what the agent needs to know: what it returns and how the target is selected. It could mention edge-case behavior (e.g., when no image exists yet), but this is a minor gap given the low complexity and clear annotations.

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 tool has zero parameters, so the baseline is 4; the schema fully covers the parameter surface. The description's mention of 'most recently generated or edited' helps clarify what the implicit selection criterion is.

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 ('Get metadata') and names the exact resource ('the most recently generated or edited image') with the fields returned (file path, MIME type, timestamp, size). This clearly distinguishes it from sibling tools like generate_image, edit_image, and list_models.

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 phrase 'most recently generated or edited image' gives clear contextual guidance: use this tool when you need metadata about the latest image from generation or editing workflows. It does not explicitly name alternatives or exclusion conditions, but the usage context is evident from the siblings.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering side-effect safety. The description adds value by specifying exactly what state is inspected, which is useful behavioral context beyond the generic read-only flag. 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.

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

Two sentences, each earning its place. The first lists the inspected state; the second gives the intended use case. No filler, no redundancy, and the key information is front-loaded.

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 simple no-parameter, read-only status tool, the description covers purpose, scope, and usage timing. The presence of an output schema handles return-value documentation, and annotations cover safety, so nothing necessary is missing.

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 tool has zero parameters, so the description carries no parameter burden. Per baseline for a 0-parameter tool, this is a 4; the description appropriately says nothing about parameters.

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 begins with a clear, specific verb ('Check') and names three concrete resources: authentication state, active model, and image output directory. This clearly distinguishes the tool from siblings like list_models or generate_image, which have different purposes.

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 explicitly states when to use the tool: 'Use this to verify setup before generating images.' However, it does not mention alternatives or cases where one would not use it, so it doesn't fully meet the 'when-not' and 'alternatives' criteria.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context by specifying the result includes all available models and the fields returned, which goes beyond the annotations without contradicting them.

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 with no filler. The first sentence front-loads the core purpose and output, and the second sentence adds actionable guidance about using the returned model IDs.

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?

This is a simple zero-parameter read-only list operation with an output schema, so the description does not need to explain return values. It covers what the tool returns and how the results are meant to be used, making it complete for an agent to call correctly.

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 tool has zero parameters and an empty input schema, so parameter documentation is not needed. The description adds no parameter semantics, but the baseline for zero-parameter tools is 4.

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 ('List'), a specific resource ('all available Gemini image models'), and the exact output fields ('product name, ID, and whether they are the default'). This clearly separates it from the image-generation siblings.

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 explicitly connects the tool's output to its consumers: 'Use model IDs when calling generate_image, edit_image, or continue_editing.' This gives clear context for when to call this tool, though it does not explicitly state when not to use it or mention alternatives for listing.

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