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 an important behavioral trait – that it does not reveal secrets – and describes return content (credential source + runtime info). It does not state read-only safety explicitly, but the read-only nature is strongly implied by 'Reports ... without revealing secrets.'

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 what is reported and the key constraint (no secrets revealed). Slightly wordy in enumerating credential source names, but each 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 zero-parameter, no-output-schema status tool, the description covers what it returns (credential source and runtime info) and a debug use case. It is largely complete, though it could note whether it requires auth or always succeeds.

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 takes zero parameters, which per rubric yields a baseline of 4. No parameter documentation is needed, and the description correctly implies a no-argument call.

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?

States a specific verb ('Reports') and resource ('credential source ... plus basic runtime info'), and enumerates the three possible credential sources, which is concrete. It doesn't explicitly distinguish itself from siblings, but none of the siblings (generate_image, edit_image, list_models, etc.) overlap in purpose, so misidentification is unlikely.

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?

Ends with 'Useful for debugging setup,' which implies the when-to-use context. However, it doesn't state when NOT to use it or name alternatives, and the guidance is vague rather than an explicit trigger condition.

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 load. It does disclose useful behavior: accepted input forms (local path or inline base64) and automatic model selection by prompt complexity/reference count. It says nothing about side effects, permissions, cost/latency beyond 'high' thinking, or how results are returned when save_to_file is false.

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 compact sentences with the core capability front-loaded and no filler. Efficient and easy to scan, though the third sentence duplicates the schema's 'auto' model description.

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 10-parameter tool with no annotations and no output schema, the definition covers capabilities and model selection but leaves return behavior ambiguous — e.g. how the agent receives the image when save_to_file is false versus true. Adequate but with a real gap for a heavy tool.

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's param-related claims ('accepts local file paths or inline base64', auto model picking by prompt complexity and reference-image count) largely restate what the schema already documents for images and model, adding little new meaning.

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?

Specific verbs (edit, inpaint, restyle, compose) plus a clear resource ('one or more reference images') and the backing model family. It implicitly separates itself from generate_image by requiring reference images, but never names or explicitly contrasts with that sibling, so it stops short of a 5.

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?

Usage is implied by 'one or more reference images' (this is the image-to-image path), but there is no explicit when-to-use guidance, no statement of when to prefer generate_image or render_template instead, and no stated prerequisites or 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 exist, so the description carries the full burden. It usefully discloses the auto-model-selection logic and that the image is returned inline and optionally written to disk, but it says nothing about auth requirements, latency/cost tradeoffs beyond the thinking_level note, rate limits, or content-policy 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?

Three sentences, front-loaded with the core action and model family, followed by the model-selection rule and return behavior. No filler and every clause carries information.

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 9-parameter generation tool with no output schema, the description covers the essentials: generation source, model-selection behavior, and return/save format. It stops short of describing permissions or failure behavior, but the rich schema compensates for most parameter detail.

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 every parameter in detail. The description only restates the model default/override behavior, adding no meaningful semantics beyond what the schema provides; baseline 3 applies.

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?

States a specific verb (generate) and resource (image) plus the backing model family, which is far beyond a tautology. The distinction from the sibling edit_image is only implicit (this creates from a prompt rather than modifying an existing image), but the purpose itself 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?

Explicitly explains the default behavior (auto-selects Nano Banana 2 vs Pro by prompt complexity) and the condition for overriding it via the model parameter. It does not say when to prefer this tool over edit_image or render_template, so full routing guidance is missing.

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 supplied, so the description carries the burden, and it does so by disclosing that this is a fixed enumeration of three models and enumerating the attributes returned. It does not state read-only safety explicitly or the exact response shape, but for a zero-parameter lister side effects are not plausible.

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 sentence, front-loaded with the resource, then the payload contents. Every clause carries distinct information with no filler.

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?

With no output schema, the description must convey the return contents, and it does so thoroughly (aliases, resolution, thinking_level, grounding, reference limits, auto-selection eligibility). Only the literal response structure/field names are left unspecified, which is a minor gap for a catalogue tool.

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?

Zero parameters, so the baseline of 4 applies. The description adds no parameter detail because there are none to describe, and the schema confirms an empty object.

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?

Specific verb (returns) plus resource (the three supported Gemini image models) and an explicit inventory of what comes back: aliases, capabilities, resolution, thinking_level, grounding, reference limits. This clearly separates it from generate_image/edit_image, which act on images rather than enumerate 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?

Usage is implied rather than stated: an agent can infer this is the discovery call to run before generate_image/edit_image to learn model names and capabilities. There is no explicit when-to-use, when-not-to-use, or named alternative, so it stays at the implied level.

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 that the output is a set of curated templates with their accepted fields, and that the same templates are reachable through the MCP prompts/list API, which is meaningful behavioral context. It is a side-effect-free listing by implication, though it doesn't explicitly confirm read-only behavior or result size.

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, both front-loaded and purposeful: the first defines the resource and its contents, the second defines the usage path. No filler or restatement of the tool name.

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 zero-parameter lister with no annotations and no output schema, the description is nearly complete: it says what comes back (templates plus their fields) and how to use them. It could add a note on the result shape or ordering, but nothing essential for correct invocation 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 takes zero parameters, so the schema provides nothing to interpret and the baseline is 4. The description appropriately avoids parameter discussion and instead explains how the returned template ids/fields are consumed downstream.

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?

States a specific verb (Lists) and resource (nanobanana-mcp's curated prompt templates), and scopes the content to photography, design, and editing with the fields each template accepts. It also names the sibling render_template, so an agent can distinguish this discovery tool from the rendering tool without opening any schema.

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?

Explicitly describes the workflow: use this to list templates, then pass a template id and its fields to render_template, or reach the same templates via the MCP prompts/list API. It routes the agent to the right follow-up tool but does not state exclusions or when this listing should be skipped (e.g., if templates are already cached).

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 that this is a pure transform producing a prompt string (no side effects implied), but says nothing about failure modes such as an unrecognized template id or missing/extra field values, which are realistic for a 10-template catalog with a free-form fields object.

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, zero filler, and the input action is front-loaded ahead of the downstream wiring. Every clause 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 2-parameter tool with no output schema, the description covers what comes back (a usable prompt) and where to send it, and the nested `fields` object is explained by the schema. Only the error/edge-case behavior is left unaddressed.

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% and the template enum list and fields-object semantics are fully documented in the schema, so the schema does the heavy lifting. The description's 'with your values' adds no syntax or format detail beyond it, making the baseline 3 correct.

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?

Specific verb (fills/renders) plus resource (curated template) plus the concrete output (a ready-to-use prompt). It also implicitly separates itself from the generation siblings by being the pre-generation step that feeds them.

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?

Explicitly routes the agent forward: feed the result into generate_image's or edit_image's `prompt` argument, which is exactly the downstream action an agent needs. It does not state when *not* to use it (e.g., writing a prompt from scratch), so it stops short of a 5.

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