ViewMax MCP

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

Beyond the annotations (which only declare openWorld=true, readOnly=false, idempotent=false, destructive=false), the description discloses the credit cost model — 0 credits for Pro/Ultra flagship models within the shared daily fair-use pool, otherwise credits are consumed — and that the operation is asynchronous and requires a follow-up wait_for_task call. That is substantive operational context not available in structured fields.

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: purpose + modes first, then cost caveat, then the required next call. Every sentence carries load and nothing is repeated from the schema or annotations.

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 7 parameters, 14% schema coverage, and no output schema, the description correctly covers the async workflow and result retrieval path, but leaves model selection, prompt/scene relationship, quality, and aspect_ratio guidance entirely to guesswork. Adequate for invocation, incomplete for confident parameter choice.

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 14% (just idempotency_key), so the description must compensate for six undocumented parameters. It partially does so for image_urls (triggers image-to-image) and model (flagship models are free within the fair-use pool), but scene, prompt, quality, and aspect_ratio semantics are entirely unaddressed in both schema and 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 opens with a specific verb+resource ("Create an image generation task") and immediately qualifies the two operating modes, text-to-image vs image-to-image, tied to the image_urls parameter. This clearly separates it from generate_video, generate_music, and generate_speech siblings without needing to name 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?

It states the condition that selects image-to-image ("when image_urls are provided") and the required follow-up workflow ("Call wait_for_task with the task_id for the result URLs"). It does not, however, point to list_image_models/get_image_model for choosing a model, nor state any exclusion for the non-image generation 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?

Adds substantial context beyond the annotations: pricing (60 credits for up to 60s, then 1 credit/second), that plan allowances do not cover music, that duration_seconds defaults to 60, and that rendering is synchronous with output_urls returned immediately. Annotations only cover safety flags, so this description carries the real behavioral burden well.

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 dense sentences, each front-loading the most decision-relevant fact (what it does, cost, parameter interaction, latency). 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?

For a synchronous generation tool with no output schema, the description covers cost, latency, return artifact (output_urls), and the key parameter pitfalls. An agent has everything needed 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?

Schema description coverage is only 17% (idempotency_key alone), so the description must compensate, and it does: it explains the prompt/style/lyrics interaction and the duration_seconds default and cost implications. Only 'instrumental' is left unexplained.

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?

Opens with a specific verb+resource: 'Create an original music track from a text prompt.' This cleanly separates it from sibling audio tools like generate_sound_effect and generate_speech, which produce different artifacts.

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 concrete usage rules: how to use style vs lyrics vs prompt, and that style converts the prompt into lyrics so they shouldn't be combined. It doesn't explicitly name when to prefer a sibling tool (e.g., sound effects vs music), but the operational guidance is clear and actionable.

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 a non-read-only, open-world, non-idempotent operation, and the description meaningfully adds cost (5 credits) and the synchronous return behavior with output_urls. That cost and timing disclosure is exactly the kind of context annotations cannot carry, though failure/timeout handling is left to the idempotency_key schema text.

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, front-loaded with the core action, then cost, then execution behavior. Every sentence 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?

For a paid, open-world generation tool with no output schema and sparse parameter documentation, the description covers cost and the typical return but omits parameter tuning, credit-failure behavior, and any return-content detail. It is adequate to attempt a minimal call but not 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 coverage is only 25% across 4 parameters, so the description carries a heavy burden but adds essentially nothing: duration_seconds, prompt_influence, and idempotency_key are never mentioned, and prompt is only implied by 'from a text prompt'. No guidance on ranges or how to tune the output is provided.

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 (sound effect) from a text prompt, which cleanly separates it from generate_music, generate_speech, and generate_image among the siblings. It stops short of explicitly naming the nearest alternative, but the resource noun does the differentiation work.

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?

There is no when-to-use guidance, no statement of when to prefer this over generate_music or generate_speech, and no prerequisites or exclusions. The synchronous-render note hints at timing expectations but never tells the agent when this tool is the right choice.

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?

Goes well beyond the annotations by disclosing the credit formula (ceil(characters/20), minimum 1) and the synchronous rendering behavior with an output_urls result, which matters for an agent planning retries or cost. It hedges with 'usually returns immediately', implying possible latency, but doesn't explain what happens in the slow case despite the idempotency_key parameter existing for retry handling.

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, front-loaded with the core conversion action, then cost, then execution behavior. No filler and nothing redundant with the schema.

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 paid, 7-parameter generation tool with no output schema, the description usefully covers cost and return shape, but it leaves most tuning parameters unexplained and doesn't clarify what happens when rendering isn't immediate. Adequate but with 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 description coverage is only 14% (just idempotency_key), so the description must carry the load for 7 parameters. It explains voice_id's sourcing via list_voices but says nothing about text, speed, model_id, stability, or similarity_boost, leaving five parameters undocumented in both places.

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 ('Convert text to speech') with the required input (voice_id) called out, which cleanly distinguishes it from siblings like generate_image, generate_music, and generate_sound_effect. An agent can pick this tool without opening the 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?

Usage is implied by the purpose, and it routes the agent to the sibling list_voices for picking a voice_id, which is useful. However, it never states when to prefer this over alternatives such as generate_sound_effect, nor any preconditions 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?

Annotations only declare readOnly=false/openWorld=true/idempotent=false/destructive=false; the description adds real behavioral context beyond them: credit consumption tied to the authenticated ViewMax account, the Ultra ViewMax C1 daily fair-use pool, that omitted duration/resolution/aspect_ratio are billed at mode defaults, and that the call is asynchronous and must be polled. It does not restate what the idempotency_key schema field already covers.

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?

Four dense sentences, front-loaded with the action and return value, then mode derivation, then billing, then the follow-up call. No filler and nothing buried.

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 correctly supplies the return contract (task_id plus the wait_for_task polling instruction) and the billing/account context an agent needs before spending credits. Gaps remain around the audio and source_video_duration_seconds parameters and model selection, but the core workflow is 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 coverage is only 9% (just idempotency_key), so the description must compensate, and it does for mode, image_urls/video_urls, duration, resolution and aspect_ratio, including that defaults are resolved via get_video_model and billed at those values. It leaves model, prompt, audio and source_video_duration_seconds unexplained, so it is not fully complete.

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?

Opens with a specific verb+resource: 'Create a video generation task and return its task_id.' That immediately distinguishes it from siblings like generate_image, generate_music and generate_speech, and the return value is named up front.

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 gives explicit mode-selection logic (image_urls -> image-to-video, video_urls -> video-to-video, else text-to-video) and routes the agent to get_video_model for defaults and wait_for_task for polling. It never states when video generation is the wrong sibling (e.g., vs generate_image), but the operational guidance is otherwise strong.

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, and destructiveHint=false, so the safety profile is fully covered. The description adds one useful domain fact (generation drains credits), but says nothing about account scoping failures, auth requirements, or whether the balance is live or cached.

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 with zero filler; the core action is front-loaded and the consumption note adds context in a single clause. 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 zero-parameter read with a full annotation set and no output schema, the description is nearly sufficient. The only real gap is the shape of the return value (a raw count vs. currency units), which the absence of an output schema would normally justify mentioning.

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 carries no parameter semantics to compensate for; the baseline of 4 applies. The description correctly implies no input is needed by referring to 'the authenticated account'.

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 ('Get') and resource ('remaining credits') scoped to the authenticated account, so the agent knows exactly what it retrieves. It is implicitly distinguished from the generate_* siblings via the consumption note, but never names an alternative 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?

The line 'Generation consumes credits' implies the tool is useful for checking balance before or after a generation, but it never states when to call it, when not to, or any alternative. Usage is inferable rather than instructed.

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 readOnlyHint, idempotentHint, so safety is covered. The description adds that generating with the model consumes credits, a useful cost context beyond annotations, though it doesn't explain the response's pricing structure or rate 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 concise sentences, front-loaded with the main action and followed by relevant credit context; no waste.

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 read-only, one-param tool with no output schema, the description covers purpose and a key side effect. However, without output schema, it should hint at what 'full capabilities' returns and the parameter's expected value, which it doesn't.

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 0% and the single 'model' parameter has no description. The description references 'one image model' but doesn't clarify format (e.g., model ID or name), leaving semantics thin.

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 (Get) and resource (capabilities and credit pricing for one image model), clearly distinct from list_image_models and generate_image 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?

Implied usage is to inspect a model before generating, but there's no explicit when-to-use versus list_image_models or generate_image. The agent must infer the selection context.

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/non-destructive, so the safety profile is covered. The description adds genuine behavioral context beyond that: failed and canceled tasks expose error_code and error_message, and their credits are refunded automatically — information an agent cannot infer from the schema or 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 sentences, front-loaded with what the tool returns, then the failure-case behavior. No filler or restated naming.

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, and the description compensates by naming the key return fields (status, URLs, cost_credits, error_code/error_message). For a simple single-id lookup this is nearly complete; only the origin of task_id and the polling-vs-wait distinction are left implicit.

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?

One required parameter (task_id) with 0% schema description coverage. The description only implies the identifier comes from a previously created task; it adds no format, source, or validity detail beyond what the schema shows. Baseline 3 given a single trivially-named parameter.

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 (Get) plus the resource (task) and enumerates the returned fields (status, output URLs, cost_credits). It also scopes to 'one of the authenticated user's tasks' and lists the task types, which separates it cleanly from the generate_* siblings and from list_* tools.

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 (retrieve status for a known task_id) but there is no explicit guidance on when to call this versus wait_for_task, nor when to prefer it over polling. The presence of wait_for_task as a sibling makes the missing routing instruction a real gap.

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/non-destructive, so the bar is lower; the description goes beyond them by disclosing what each mode returns (durations, resolutions, aspect_ratios, audio_toggle, credits), what the 'defaults' mean, and when max_prompt_length appears. The trailing credit-consumption note concerns generate_video rather than this read tool, slightly diluting the added value.

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?

Front-loaded with the core purpose and return contents; the field enumeration is informative rather than redundant. The final sentence about credits being consumed when generating is tangential to a get tool and is the one line that does not clearly earn 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?

With no output schema, the description carries the return-value burden and does so adequately by enumerating the per-mode fields and explaining the defaults and the conditional max_prompt_length. The missing piece is argument semantics for 'model', which keeps it from being 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% for the single required 'model' parameter, and the description does not compensate: it never states what form the argument takes (model ID, name, slug) or how to discover valid values. A read-only lookup keyed on an undocumented identifier is a real 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?

States a specific verb and resource ('Get full capabilities and credit pricing for one video model'), which clearly separates it from the batch-oriented list_video_models and from generate_video. It stops short of explicitly naming a sibling to route against, so it lands at 4 rather than 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?

The phrase 'for one video model' implies this is the single-model detail lookup versus the list variant, but there is no explicit when-to-use or when-not-to-use guidance, nor any prerequisite such as where to obtain a valid model identifier.

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 and destructiveHint=false, so safety is covered structurally. The description adds genuinely useful context beyond that: the tool is non-billable itself, while image generation consumes credits, and it names the model attributes exposed.

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, front-loaded with the resource and its returned facets, followed by the credit-cost note. Every clause carries information; nothing is redundant with the 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?

There is no output schema, so the description must convey the return shape, and it does so by listing modes, aspect ratios, qualities and credit labels. A brief note that the list is unfiltered/complete or how models are ordered would make it fully 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 tool takes zero parameters, so the schema has nothing to document; per the rubric this sets a baseline of 4. The description correctly does not invent parameter semantics.

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 ('List available image models') and enumerates the returned facets (modes, aspect ratios, qualities, credit labels). It does not explicitly differentiate itself from the singular sibling get_image_model or from list_video_models/list_music_models, so it falls 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: an agent would call this to discover image model options before calling generate_image or get_image_model. However, no explicit when-to-use vs alternatives guidance is given, and the credit sentence is cost context rather than routing 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 the operation safe, read-only, idempotent and non-destructive, so the safety profile is covered. The description adds genuinely new context beyond annotations: the pricing model (60 credits up to 60s, then 1 credit/second), which is useful behavioral detail for planning a generation.

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 that front-load the action and return content, then add the pricing rule. Efficient overall, though the credit-cost sentence arguably belongs to the generate_music tool rather than the listing tool.

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, read-only listing tool with no output schema, the description sufficiently conveys what comes back (models, their controls, and cost). An agent lacks exact response shape, but that is a minor gap for a simple discovery call.

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 there are no parameter semantics to document; baseline for a 0-param tool applies. Nothing in the description is needed to explain inputs.

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 ('List') and resource ('music models') plus what is returned ('their controls and credit cost'). The 'music' qualifier cleanly distinguishes it from siblings list_image_models and list_video_models without needing their schemas.

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: an agent can infer this should be called to discover models before generate_music, but the description never states when to use it versus get_image_model/get_video_model or alternatives. No exclusions or prerequisites are given.

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 and destructiveHint=false, so the safety profile is fully covered. The description adds only the credit-cost warning (which concerns video generation, not this read tool) and the default-values pointer; it says nothing about the return format or scope. Modest added value above 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 compact sentences, with the core purpose front-loaded and the alternative/cost caveat second. No filler, though the credits warning is tangential to this specific tool.

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?

A zero-parameter read-only list tool with annotations covering the safety profile and no output schema; the description adequately states what it returns and routes to get_video_model for detail. Minor gap: it doesn't hint at the shape of the returned model list.

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 per the baseline the schema carries nothing to document and the description is not expected to compensate. Nothing in the text misleads 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?

States a specific verb and resource ('List available video models and their capabilities'), and the 'video' qualifier implicitly distinguishes it from the list_image_models/list_music_models siblings. It does not explicitly name or contrast those siblings, which keeps it 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?

Names the alternative tool (get_video_model) and the condition that selects it ('detailed pricing and the values used when options are omitted'). This is clear routing guidance, though it never states when this list tool is preferred over just calling get_video_model directly.

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 this a safe, idempotent, read-only, closed-world listing, so the bar is low. The description adds real value beyond them by disclosing the credit-cost model (ceil(characters / 20), minimum 1) and the pricing fields returned, which an agent cannot infer from annotations or 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?

Two short sentences with no filler; the field list comes first and the credit formula follows, so the most decision-relevant detail 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?

With no parameters, no output schema, and annotations already covering the safety profile, the description supplies everything needed: what is listed, which fields come back, and how the returned pricing translates into generation cost.

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 baseline is 4; there is no parameter semantics to clarify and the description correctly omits any parameter discussion.

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 ('List available text-to-speech voices') and enumerates the returned fields (id, name, gender, accent, language), which distinguishes it from the model-listing siblings such as list_image_models and list_music_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 only implied: the pricing formula suggests this is called before generate_speech to estimate cost, but there is no explicit when-to-use, no exclusion, and no named alternative or prerequisite.

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, and non-destructive, so the safety bar is met. The description adds real value beyond them: the polling-until-terminal-state contract, the timeout blocking behavior, and the reassurance that results are persisted and never lost.

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, front-loaded with the core action and timeout, then the polling loop, then the persistence reassurance. 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?

No output schema exists, so the description correctly names the return shape. With annotations covering safety and the polling contract explained, it is nearly complete; the only soft spot is not stating what is returned when the timeout elapses without a terminal status.

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 parameter meaning. It explains timeout_seconds semantics (wait up to that long; 1-50, default 45), though the range/default merely restate schema constraints, and task_id is only implied by 'for a task'. Partial compensation, not full.

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 clear verb+resource ('Wait ... for a task and return its latest status') and specifies the return shape matches get_task. It stops short of explicitly contrasting with the get_task sibling (immediate vs blocking), so an agent must infer which to pick.

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 explicit operational guidance: keep calling until status is success, failed, or canceled, with the rationale that some videos take minutes. It does not name get_task as the non-blocking alternative, so the when-to-use-this-vs-sibling question is only implied.

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