rostro

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

Annotations already establish this is read-only, idempotent, and non-destructive. The description adds valuable context by specifying exactly which account fields are returned (identity, scopes/access, subscription, credit balance), which is information not present in the structured metadata.

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 efficient sentence with no extraneous text. However, the passive phrasing ('Response includes...') front-loads the output rather than the action, which is slightly less scannable than starting with the verb (e.g., 'Fetch account details including...').

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 has zero parameters and an output schema exists (per context signals), the description appropriately focuses on summarizing the return value contents rather than re-documenting the schema. It adequately covers the tool's simple scope.

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, which per the baseline guidelines warrants a score of 4. With no arguments to document, the schema coverage is trivially complete and no additional parameter semantics are needed in 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 indirectly describes the tool's purpose by listing what the 'Response includes' rather than stating the action explicitly (e.g., 'Retrieves account details'). While the fields listed (identity, scopes, subscription, credit) clarify the resource, there is no differentiation from sibling tools like 'check' that might overlap conceptually.

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 guidance is provided on when to use this tool versus siblings like 'check' or 'history'. There are no prerequisites, conditions, or exclusion criteria mentioned to help the agent decide if this is the correct tool for a given user request.

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 declare readOnly/idempotent safety properties, so the description appropriately focuses on adding operational context: it clarifies this is a polling/waiting mechanism and specifies which generation types typically require extended waiting. No contradictions with annotations.

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 tightly constructed sentences with zero redundancy. The first sentence establishes the core action immediately; the second qualifies usage by content type. Every word serves a purpose.

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 presence of an output schema (not shown but indicated), comprehensive annotations covering safety properties, and 100% parameter coverage, the description provides complete conceptual context without needing to specify return values or technical constraints.

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?

With 100% schema description coverage for the single 'generation_uuid' parameter, the baseline is 3. The description implies the UUID comes from a prior generation request but does not add syntax details or explicit sourcing guidance beyond what the schema 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 uses a specific verb phrase ('Continue to wait') combined with the resource ('currently running generation') to clearly define the tool's polling function. It effectively distinguishes from sibling 'imagine' (likely the creation tool) by implying this is a follow-up status check.

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 contextual guidance by identifying specific content types that require polling ('videos and 3D models'), implying when the tool is necessary versus when results might be immediate. Lacks explicit workflow mapping (e.g., 'use after imagine'), but the usage context is 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?

Annotations already declare destructiveHint=true and idempotentHint=true, establishing the safety profile. The description adds valuable behavioral context regarding authorization requirements (explicit user consent) not present in the annotations. However, it omits details about deletion permanence, recovery options, or what the operation returns (though output schema is present).

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 waste. Front-loaded with the core action, followed immediately by the critical safety constraint. 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?

Adequate for a single-parameter destructive operation where annotations and output schema handle the safety profile and return structure. The explicit consent requirement addresses the key missing behavioral gap. Could be improved by mentioning permanence of deletion, but not strictly necessary given destructiveHint annotation.

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% ('A list of UUIDs to delete'), so the structured documentation carries the full burden. The description references the parameter obliquely ('these uuids') but adds no syntax, format, or semantic details beyond the schema. Baseline 3 is appropriate given high 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?

States specific verb (Delete) and resource (media) with clear scoping mechanism (UUIDs). The sibling tools (account, check, history, imagine) perform entirely different functions, so the verb alone effectively distinguishes this tool, though the description doesn't explicitly contrast with 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?

Provides explicit when-not guidance ('Don't use this unless the user explicitly asks you to'), which is critical for a destructive operation. However, it does not name specific alternative tools for non-destructive actions (e.g., if there's a 'soft delete' or 'archive' option among 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 establish read-only, idempotent, non-destructive safety properties. The description adds the 'unified' concept, clarifying this aggregates multiple generation modalities. However, it omits behavioral details like pagination mechanics (despite the cursor parameter), rate limiting, or history retention periods.

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 single sentence is tightly constructed with zero redundancy. 'Unified' efficiently signals multi-type support, 'fetching' establishes the read operation, and 'multimedia asset generation history' precisely scopes the resource without wasting words.

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 presence of an output schema and comprehensive input schema documentation (100% coverage), the description adequately anchors the tool's purpose. However, for an 8-parameter tool with complex filtering capabilities (UUID arrays, media type filters, pagination), mentioning pagination behavior or filtering logic would improve completeness.

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?

With 100% schema description coverage, the structured documentation carries the semantic load. The description does not explicitly elaborate on parameter interactions (e.g., how uuids filters interact with media_types), meeting the baseline expectation for well-schematized tools.

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 tool as fetching 'multimedia asset generation history' with the term 'unified' hinting at comprehensive coverage across media types (supported by the GenerationType enum in schema). It effectively distinguishes this read operation from sibling tools like 'imagine' (likely creation) and 'delete' (removal).

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 no explicit guidance on when to use this tool versus siblings like 'check' or 'account'. While 'unified' implicitly suggests use for broad historical queries across all generation types, there are no stated prerequisites, exclusions, or workflow 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?

Annotations already declare readOnlyHint=false and destructiveHint=false, establishing this is a safe write operation. The description adds context about it being a 'unified' endpoint handling multiple modalities, but does not disclose additional behavioral traits like generation latency, credit consumption, or async completion status.

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 efficiently structured sentences where every clause earns its place. The first establishes scope ('unified endpoint'), the second provides actionable trigger words. No redundancy or unnecessary verbosity.

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 high complexity (9 generation types, 30+ parameters) and presence of output schema, the description appropriately focuses on high-level purpose and usage triggers rather than parameter minutiae. It successfully conveys the breadth of capabilities (multimedia) that the schema elaborates.

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?

With 100% schema description coverage, the schema itself documents all parameters comprehensively. The description adds value by explaining the polymorphic nature ('unified endpoint') that justifies the single 'request' parameter structure, meeting the baseline for high-coverage schemas.

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 explicitly defines the tool as a 'unified endpoint for multimedia asset generation' and lists specific media types (image, song, video, speech, sound effect, 3D model). This clearly distinguishes it from siblings like 'delete', 'account', or 'history' through its specific verb and resource scope.

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 explicit trigger keywords ('make', 'create', 'generate', 'imagine') for when to invoke the tool. However, it lacks explicit 'when not to use' guidance or named alternatives, though none of the siblings appear to be alternative media generation tools.

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