ViewMax MCP

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

No annotations exist, so the description carries the behavioral disclosure burden. It adds important facts beyond the obvious generation behavior: it is an async task that must be polled via get_task, listed models can be free within a shared daily fair-use pool, and otherwise credit consumption occurs. This gives the agent material guidance about side effects and follow-up.

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 compact and front-loaded; the first sentence establishes the core operation and the second covers economic/blob behavior and result polling. It is slightly dense, but the factual content 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 an async generation tool with no output schema, it properly tells the caller how to retrieve results via get_task and indicates nudget that lit consumed pricing can be 0. It does not specify output fields, failure behavior, quality, or aspect_ratio constraints, but an agent has enough to invoke it correctly and retrieve results.

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 percent, so the description must compensate. It does add meaning for image_urls by explaining that providing them switches the task to image-to-image, and it offers example model names. However, scene, quality, prompt, and aspect_ratio have no described effect or allowed values, leaving several use issues unresolved.

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 precise verb and resource: it creates an image generation task. It also distinguishes between text-to-image and image-to-image modes depending on image_urls, making it clearly distinct from sibling tools like generate_music, generate_ideo, or generate_speech.

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?

Clear context is present: it is the image-generation tool, and image-to-image is the correct mode when image_urls are provided. It also tells the caller to poll get_task for the eventual result URLs. It does not explicitly list when not to use it in favor of a sibling, but the image-specific wording makes the intended usage effectively unambiguous.

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 transparency burden. It does disclose important behaviors: the operation consumes credits, and it synchronously returns output_urls. However, it omits cost amounts, failure modes, rate limits, or what makes a prompt invalid, so the disclosure is thin rather than robust.

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 load-bearing: the first defines the core action and the second covers side effects and timing. There is no filler and the most important constraints are 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 generation tool with five parameters, no annotations, and no output schema, this is minimally viable: the prompt is explained, credits are flagged, and the synchronous return behavior is stated. But optional parameter semantics, alternative tool routing, and cost nuances are missing, so it does not reach a higher level of 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?

The input schema provides only types and constraints, not descriptions, so schema_description_coverage is essentially zero. The description adds meaning only for 'prompt' by saying the track is created 'from a text prompt,' but it entirely ignores the optional parameters: style, lyrics, instrumental, and duration_seconds. Since the schema carries no semantics, the description needed to compensate more and did not.

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 verb and resource: 'Create an original music track from a text prompt.' This is specific enough to distinguish from image, video, speech, and sound generation at a basic level. However, it does not explicitly call out any sibling tools or edge cases where it might be confused with 'generate_sound'.

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 explicit guidance about when to use this tool versus alternatives. Mentioning that 'This consumes credits' hints at a precondition, but it does not tell the agent when to choose this over other generators, when not to use it, or whether to check credits first.

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?

Since no annotations are provided, the description carries the behavioral disclosure burden. It usefully discloses that the operation consumes credits, renders synchronously, and returns output_urls, which are non-obvious traits an agent should know before calling.

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 concise and front-loaded, stating purpose in the first sentence, followed by two short high-value behavioral notes. 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?

The description covers purpose, synchronous behavior, cost, and result shape via output_urls, but it omits how the optional duration and prompt_influence parameters affect the result and does not differentiate use cases from sibling audio-generation tools.

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 compensate for missing parameter semantics. It only clarifies that generation happens from a text prompt via the prompt parameter, but offers no meaning or usage guidance for duration_seconds or prompt_influence.

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: 'Generate a sound effect from a text prompt.' This clearly distinguishes the tool from siblings like generate_image, generate_music, generate_speech, and generate_video.

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 guidance about when to choose this tool over the closely related generate_music or generate_speech tools. The description gives operational context (credits, sync rendering) but no explicit when-to-use or alternative-selection 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?

With no annotations, the description correctly carries the behavioral burden. It discloses two important non-obvious behaviors: credit consumption and synchronous rendering with output_urls immediately. This is valuable information beyond the parameter schema, though it stops short of describing failure modes, credit limits, or authentication requirements.

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 deliver purpose, prerequisite, cost implication, and expected timing in a compact, front-loaded way. There is no filler or repetition.

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?

The description covers the most important context: what it does, how to pick a voice, credit usage, synchronous behavior, and the output form (output_urls). However, it omits any mention of fallback behavior when rendering is not immediate, model selection, or optional tuning parameters. Still, the core invocation path is reasonably covered.

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 parameter coverage is 0%, and the description only mentions text and voice_id, the two required parameters. Four optional parameters (speed, model_id, stability, similarity) are left completely undocumented, so the agent has to infer their meanings. This does not sufficiently compensate for absent schema descriptions.

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's action ('Convert text to speech'), the target resource (text and voice_id), and explicitly distinguishes it from image, music, sound effect, and video generation siblings. The reference to list_voices reinforces the speech-specific 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?

The description gives solid context for when to use it: it consumes credits and renders synchronously with immediate output_urls, which lets an agent avoid waiting for tasks or using wait_for_task. It also points to list_voices for selecting a voice. However, it does not explicitly state when not to use it or mention alternatives beyond that.

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 must carry behavioral disclosure. It usefully reveals the credit-consumption behavior and the fair-use pool, which is valuable. But it remains silent on asynchronous behavior, return format, auth requirents beyond 'authenticated ViewMax account', and side effects.

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 fluff, with the core purpose first and the cost/billing note second. The description earns each sentence despite being concise.

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 output schema and no annotations, the description is markedly under-specified. It does not explain return values, task lifecycle, the meaning of the parameters, or how it fits with wait_for_task and get_task. An agent cannot confidently map inputs or interpret results from the description alone.

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% by context. The tool has 10 parameters, including mode, audio, image_urls, video_urls, resolution, aspect_ratio and duration, yet the description defines none of them. It adds no semantic value beyond the bare schema.

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 the direct function: 'Create a video generation task.' The resource is clearly video generation, which distinguishes it from sibling tools like generate_image, generate_music, and generate_speech.

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 primary usage is implied — this is the video-generation tool among siblings — and the credit/fair-use note adds important context about when costs apply. However, there is no explicit guidance on when to prefer this tool over alternatives, nor any mention of related tools like wait_for_task.

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 were provided, so the description carries the disclosure burden. It states that 'Generation consumes credits,' clarifying that generate_tools consume credits, and describes this tool as a read-only retrieval of remaining credits. It doesn't separately atted 'this call itself does not consume credits' or slate exact response format, but for a single purpose zero-parameter balance check the disclosed behavior is sufficiently transparent.

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 contain all essential information, with the core action front-loaded: 'Get the authenticated account's remaining credits.' The second sentence provides useful domain context without bloating the definition.

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 zero-parameter simple lookup, the description is largely complete: it names the autghorized account, the resource credits, and the consumption behavior. Without an output schema it would be slightly stronger if it explicitly stated that the returned value is a numeric balance, but the phrase 'remaining credits' already conveys the expected result.

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?

There are no parameters and schema coverage is 100%, giving baseline of 4. The description adds the meaningful detail that no params are needed because the account is authenticated and the tool concerns remaining credits. It does't need to compensate for undocumented 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 states a specific verb and resource: 'Get the authenticated account's remaining credits.' It clearly defines the tool as a balance/account operation, and because all sibling tools are generation, model, or task tools, this immediately identifies get_credits as the quota-checking counterpart.

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?

'Generation consumes credits' gives clear context for when this tool matters: check remaining credits before/while using generation tools. It does not explicitly enumerate when not to use it, but no exclusions are needed among the listed siblings because no other tool checks credit balances.

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 provided, the description carries the full burden of behavioral disclosure. The sentence 'Generating an image with this model consumes credits' adds valuable context beyond the literal 'get information' action, warning the agent about consequences associated with the model itself. However, it does not confirm whether the tool is read-only or disclose any other side effects, though the verb 'get' is strongly suggestive.

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 carry the core purpose and a behavioral warning. No wasted words, and the key action is front-loaded. This is appropriately sized for a read-only tool with a single parameter.

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 absence of an output schema, the description states what the tool returns (full capabilities and price) but does not clarify how to identify valid model inputs or reference the sibling list_image_models as sourcing. For a tool with a single parameter and no output schema, the description is mostly adequate (3), but it doesn't fully compensate for the missing parameter guidance and alternative routing information.

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 input schema provides no description for the 'model' parameter (0% coverage). The description's phrase 'one image model' gives only a loose hint, but does not define what values are valid, whether it accepts a model ID from list_image_models, or any format expectations. With such low schema coverage, the description should have provided semantic details about the input, but falls short.

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') and clearly identifies the resource as 'one image model'. It distinguishes itself from the sibling get_video_model by specifying 'image' and from list_image_models by emphasizing 'one model', making its purpose clear and 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 description implies a singular focus (one model) but does not explicitly state when to use this tool versus list_image_models or get_video_model. It provides no exclusions or alternative routing, though the context of 'one image model' gives a partial hint that this is for a specific model rather than a list.

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, and it does well: it discloses the result contents (status plus output URLs), the allowed task types, and the association with the authenticated user. It adds a meaningful side note that credit consumption happens at creation, clarifying that this read operation is not the charged step. It does not fully elaborate the state/error vocabulary, but for a GET-by-id tool the essential behavior is covered.

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 lean sentences. The first front-loads the verb, resource, scope, and output, the second adds the cost-relevant behavior — both high-value for an agent. No wasted words or redundant restating of the input 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 single-parameter, no-output-schema tool, the description is nearly self-sufficient. It tells the agent what it gets back (status and URLs) and which tasks it applies to. The gaps are minor: it does not describe the possible task statuses or failure modes for an invalid ID, but these are typically observable in the actual response and are not critical to invoking 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 0%, so the description has to carry the parameter meaning, and it does. The parameter is task_id: the description says 'one of the authenticated user's tasks', which is precisely what the ID refers to, including permission semantics. Since there is only one parameter and it is clearly implied, ambiguity is low; a slightly more direct reference to 'by its task_id' would have made it a 5.

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 ('Get') and resource ('task'), enumerates the task types (video, image, music, audio), and scopes it to the authenticated user's tasks. This fully distinguishes the tool from sibling generation tools like generate_image or generate_video, since it retrieves rather than creates.

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 makes the tool's role clear: poll or retrieve the current status and output URLs for tasks the user already started. The note that generation consumes credits at creation implicitly tells the agent that this retrieval tool is not the one that spends credits, which is useful routing context. It stops short of an explicit when-to-use vs. alternatives statement, but for a retrieval counterpart to generation siblings, that is largely self-evident.

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?

There are no annotations, so the description carries the burden of behavioral disclosure. It does disclose that generating a video with this model consumes credits, which is useful cost-awareness information. However, it doesn't disclose other behavioral traits like whether the tool makes changes, requires authentication, has rate limits, or what 'full capabilities' means in practice.

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_for esse: two sentences with no filler. The core purpose arrives: first sentence, and the important cost warning comes second. It could be slightly more concise if it merged both into one sentence, but it's already efficient.

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 one parameter, no output schema, and no annotations, the description does not explain what 'full capabilities' means, what fields are returned, or how the model parameter should be structured. It covers the key availability: consuming credits, but overall the description is thin for an agent deciding whether or how to invoke this 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?

With a single parameter ('model') and 0% schema description coverage, the schema offers almost no semantic information beyond the parameter name. The description doesn't explain what values 'model' should take (e.g., model IDs or names) or how to obtain them, so the agent must infer that from context. It's minimally sufficient but not helpful.

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 clear verb and resource: 'Get full capabilities and credit pricing for one video model.' This distinguishes it from listing tools like list_video_models and from other get_* tools by specifying it targets a single video model. However, it doesn't explicitly differentiate itself from get_image_model or get_credits, so it's clear but not maximally differentiated.

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 implies this tool is for querying a single video model's capabilities and pricing, which gives some context for when to use it versus list_video_models. However, it doesn't explicitly state when to use an alternative or exclude other tools, leaving the when-to-use guidance mostly implied rather than explicit.

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 burden of disclosing behavior. It makes clear this is a read-only enumeration operation and adds useful extra context that image generation consumes credits, which helps agents reason about downstream costs. It could be more explicit that the listing itself does not consume credits, but the verb 'List' strongly implies a safe read.

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, front-loaded sentence that states the action and the key output dimensions. Every word contributes meaning, and the credit note adds useful context without bloat.

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 list tool with no output schema, this description is complete: it tells the agent what resource is listed and what attributes will be returned. No critical information about invocation or expected behavior 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 there is no parameter ambiguity to resolve. The baseline for zero-parameter tools is 4, and the description appropriately focuses on the output content rather than 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 names a specific verb ('List') and resource ('available image models'), and specifies the key attributes returned (modes, aspect ratios, qualities, credit labels). This clearly differentiates it from sibling tools like get_image_model (singular) and list_music_models/list_video_models (different resources).

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 clearly states what the tool is used for: listing available image models with their supported attributes. It implies this is the right tool when an agent needs to enumerate image models and their capabilities, though it does not explicitly call out alternatives or exclusion conditions.

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 behavioral responsibility. It makes clear this is a read-only listing and adds a meaningful business context warning — music generation consumes credits. It does not go into further detail, but for a zero-parameter list tool this is adequate.

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, no fluff, front-loaded with the primary purpose and followed by a useful credit warning. Everything present 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?

Given the tool has no parameters, no annotation, and no output schema, the description adequately covers what you get: available models, controls, and costs. A more explicit mention of the output format or a note to use generate_music for actually creating tracks could have made it fully complete, but none of these are blocking for an agent selecting this simple read-only 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?

The tool accepts zero parameters and the input schema is empty, so there are no parameter semantics to explain. With 0 params the baseline is 4, and the description's mention of controls and credit cost helps clarify what is included in the output rather than what arguments to pass.

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: 'List available music models.' It specifies exactly what the tool provides (controls: duration, instrumental, and credit cost) and clearly separates it from the generation-oriented siblings like generate_music and from other list tools like list_image_models and list_video_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 description implies the use case: inspect available music models and costs before generation, especially since 'Music generation consumes credits.' It does not explicitly name alternatives or say when not to use this tool, so the transfer to sibling tools is left to inference.

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 disclosure burden. The warning that 'Video generation consumes credits' implicitly indicates this listing operation does not generate videos, but it does not explicitly state that listing is read-only or free of credit consumption. The absence of an explicit safety profile leaves some ambiguity.

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 sentence that front-loads the core purpose and adds the most relevant caveat about credits and pricing. Every phrase earns its place, with no redundant or filler content.

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 parameterless tool with no output schema, the description sufficiently conveys that the result is a list of video models with their capabilities, and it directs the agent to get_video_model for pricing. It could have stated that the operation is non-consuming explicitly, but the tool is simple enough that this 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 input schema is empty, so there is nothing meaningful to document. The description adds no parameter-specific semantics, which is expected here. 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 clear verb-resource pairing: 'List available video models and their capabilities.' It also differentiates itself from the sibling get_video_model by noting that detailed pricing is obtained there rather than in this listing.

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 routes the agent to get_video_model when detailed pricing is needed, which gives a clear usage boundary. It does not enumerate other alternatives like list_image_models or generate_video, but the domain of video models is clear enough that an agent will know when to choose it.

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?

Because no annotations are provided, the description must detail the operation and side effects. It states exactly what is returned (id, name, gender, accent, language) and the per-generation credit cost, which is an important behavioral fact. It does not mention pagination or caching, but for a zero-argument listing tool the disclosure is adequate.

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?

One sentence, front-loaded with the verb and resource, followed by a compact parenthetical field list. There is no filler and every phrase contributes to the agent's understanding.

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 and no output schema, the description is mostly complete: it tells the agent what will be returned and includes credit cost. A fully robust definition might note that this is a read-only list or mention whether results are paginated, but those are minor absences for such a simple 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?

There are zero parameters and the schema is an empty object, so there is nothing to document. The description actually enriches the output side by listing the fields and cost. Since the baseline for zero parameters is 4, this fits.

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 the exact verb 'list' and the resource 'available text-to-speech voices', explicitly enumerates the returned fields, and adds the credit-cost detail. This clearly distinguishes it from generation-tool siblings such as generate_speech or generate_image.

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 'available text-to-speech voices' clearly scopes this to TTS voice discovery and gives an implicit context: before generating speech, an agent should consult this tool. It does not explicitly name when-not-to-use or alternatives, but the 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?

With no annotations, the description must carry the behavioral burden, and it does so reasonably well: it discloses the wait timeout, the need for repeated calls, and that results are persisted and never lost. It could be more explicit about what happens when a single call times out, but the core behavior is transparent.

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, each earning its place: the first describes the core behavior, the second gives the essential retry/termination rule, and the third adds a useful persistence guarantee. There is no irrelevant detail.

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 small 2-parameter tool with no output schema, the description gives enough to use the tool correctly: it explains the wait bound, the necessary polling loop, terminal states, and data durability. The main remaining gap is the exact behavior on timeout and how to obtain task_id from generation calls, but those are inferable from the sibling context.

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 description adds no direct explanation of task_id or timeout_seconds. The phrase 'wait up to 50 seconds' hints at the timeout concept but doesn't map to the parameter, and task_id is only implied by the word 'task'. Parameter names are intuitive, so the tool remains usable, but the description compensates barely.

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 action (wait up to 50 seconds) and the resource (a task), and identifies the key output (its latest status). It doesn't explicitly differentiate itself from the sibling get_task tool, but the blocking/waiting behavior and time limit make its purpose reasonably distinct.

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 concrete when-to-use guidance: keep calling wait_for_task until status becomes success, failed, or canceled. It doesn't mention alternatives like get_task or usa cases where an immediate non-blocking check would be prefer, but the retry-until-terminal protocol is explicit and actionable.

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