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

Annotations declare destructiveHint=true and readOnlyHint=false for the whole tool, but the description never says which actions mutate versus read, nor what setup_reset or cache_clear actually destroy. The only behavioral detail added is that relay_* names are honored as deprecated aliases. Given a blanket destructive annotation over mixed read/write actions, this leaves a meaningful gap.

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?

Purpose is front-loaded, and the dense parenthetical/pipe notation packs the action list into minimal space. Some of the grouping syntax is harder to parse than plain prose, but nothing is padding.

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?

An output schema exists, so return values need not be explained, and the sibling routing is covered. Still, for a merged tool spanning ~11 actions, the absence of per-action behavior and of key/value semantics leaves an agent guessing about several invocations.

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 carry the load. It usefully enumerates the valid action strings (which the schema leaves as an unconstrained string), but never mentions 'key' or 'value' or which action consumes them, leaving two of three parameters undocumented anywhere.

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 scope ('Server config + credential setup') and enumerates the exact action values, so an agent knows the tool is a multi-action config router. It also explicitly distinguishes itself from the sibling config__open_relay. It stops short of 5 because the individual actions are listed but never explained, so the purpose of each branch is opaque.

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 groups actions into (setup) and (runtime) and explicitly routes the credential-form task to config__open_relay, which is real guidance. However, it gives no when-to-use guidance for choosing between setup_status, status, set, or cache_clear, and no prerequisites are stated.

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 behavioral burden. It usefully discloses that the browser may be opened and lists returned fields, but it does not cover prerequisites, authentication, or failure behavior.

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, well-structured sentence that front-loads the primary action and adds the side effect. Every phrase is relevant and there is no wasted text.

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 simple zero-parameter interface and the existence of an output schema, the description provides enough context for the tool's purpose and side effect. It does not need to explain return values in depth, and the lack of explicit usage alternatives is a minor gap.

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 the schema is empty, so there are no parameter semantics to document. The baseline for a zero-parameter tool 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 clearly states the specific action and resource: getting the relay configuration URL for imagine-mcp. It does not explicitly differentiate from the sibling config tool, but the relay-specific scope is evident from the tool name and description.

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 the relay configuration context, but the description offers no explicit guidance on when to use this versus config, help, or other siblings. The 'when possible' phrase describes browser behavior, not tool selection.

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=false, idempotentHint=false, openWorldHint=true, so the safety profile is covered. The description usefully adds the async/polling behavior for video, which annotations cannot express, but omits significant behavioral traits such as cost/quality implications of the default 'poor' tier and any rate or duration limits.

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 tight sentences with the core action front-loaded and the polling caveat immediately after. Every clause carries information an agent needs; there is 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?

Return values need not be explained because an output schema exists, and the async flow is described. However, for a 10-parameter, no-schema-description tool, the missing explanation of tier defaults, output modes, aspect ratios, and durations leaves the definition short of 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?

Schema description coverage is 0% across 10 parameters, so the description carries the full burden and does not meet it. It only clarifies job_id (poll to resume) and media_type (image vs video), leaving tier, model, provider, output_mode, aspect_ratio, duration_seconds, and reference_image_url completely undefined.

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 and resource ('Generate an image or video from a text prompt') and even subdivides by media type, so the agent knows exactly what the tool produces. It does not explicitly differentiate itself from the sibling tools (understand, help, config), but those are clearly different domains, so the risk of confusion is low.

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?

Gives clear operational context for the video path: the first call returns a job_id and subsequent calls with job_id poll for completion. There is no explicit when-not guidance or comparison to alternatives, but no real alternative generation tool exists among 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, idempotentHint, non-destructive and non-open-world, so the safety profile is fully covered. The description adds nothing beyond what the annotations provide — no note on output size, truncation, or how the documented topics relate to the sibling tools.

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 terse fragments, front-loaded with the purpose and then the option set. No sentence is wasted.

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 an output schema present, return values need no explanation, and there is only one optional parameter. The description covers the topic set adequately, but it never links those topics to the sibling tools an agent is choosing between, which is the main remaining gap.

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% and the schema types the topic as a bare string with no enum, so the description's enumerated values ('understand | generate | config') are the only place the valid topic set is documented. It adds real meaning over the schema, though it omits the default and what each topic covers.

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+resource: it returns 'full documentation' scoped by topic. The topic list maps directly onto the sibling tool names (understand, generate, config), which lets an agent connect this helper to those tools, though it never says so explicitly.

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 only implied: listing 'understand | generate | config' as topics hints that an agent calls help to learn about those siblings, but there is no stated when-to-use, no when-not-to-use, and no explicit routing to an alternative.

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 readOnly, idempotent, openWorld, and non-destructive behavior, so the safety profile is covered. The description adds provider capability constraints (mixed media on Gemini, image-only elsewhere), which is a genuine behavioral fact beyond the structured fields, but says nothing about limits or output behavior.

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 tight sentences with the core action front-loaded and the provider caveat immediately following. No filler 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?

An output schema exists, so return values need not be described, and annotations cover safety. But for a 6-parameter tool with 0% schema coverage, the description leaves half the parameters unexplained (tier, model, provider, max_tokens), making it incomplete relative to the tool's actual surface.

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% across 6 parameters. The description only clarifies that media_urls is multi-URL and that a prompt accompanies it; it says nothing about tier, model, provider, or max_tokens, leaving four parameters entirely undocumented in both the schema and the description.

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 names a concrete verb (understand) and resource (images and/or videos with a prompt), and clarifies multi-URL input. It is clear on its own, though it never names or contrasts with the sibling 'generate', so the agent must infer the distinction between understanding and generating media.

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 implicitly guides provider choice by noting Gemini handles mixed image+video while OpenAI/Grok are image-only, which is real usage context. However, it gives no guidance on when to use this tool versus 'generate' or any other sibling, leaving tool selection to inference.

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