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

The annotations already declare readOnlyHint=true and openWorldHint=true, so the safe read-only nature is known. The description adds the specific context that this tool exposes the account credit balance, which is helpful for setting user expectations. It doesn't mention return format or auth, but for a zero-parameter getter, that's acceptable.

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, clear sentence with no wasted words. It front-loads the purpose and is immediately understandable.

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 balance getter with good annotations, the description is sufficient. It does not need to list return values because the name and description already imply the output—the balance. The absence of an output schema is not a gap here.

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 has zero properties, so the baseline is 4. The description adds no parameter-specific details because there are none; no ambiguity exists.

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 the specific verb 'Show' and identifies the exact resource 'WaveSpeed account credit balance', clearly distinguishing it from sibling tools that deal with models, pricing, or file uploads. Its one-sentence definition leaves no ambiguity.

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 doesn't explicitly state when to use this tool, but its clear purpose (checking account credit) gives sufficient context for an agent to choose it over the unrelated siblings. There are no obvious alternative tools for balance checking, so no exclusions are needed.

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 annotations declaring readOnlyHint=true and openWorldHint=true, the description does not contradict these and adds value by specifying that the returned schema includes 'required fields, properties, defaults' and that it represents the 'real' accepted inputs. This goes beyond what annotations alone convey, though it could mention more about side effects or response format if any.

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 the core purpose and usage instruction without any fluff. The information is front-loaded, and 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?

For a simple read-only introspection tool with one parameter and no output schema, the description fully covers what the tool does and when to use it. It supplies enough context for an agent to correctly invoke it as part of a workflow, making it complete for its complexity.

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% — the single 'model' parameter is well-documented in the input schema. The description doesn't need to add parameter details since the schema already covers it. The baseline of 3 applies because the description adds no extra parameter semantics, but none are needed.

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 a clear resource: 'a model's real input schema (required fields, properties, defaults).' It differentiates from sibling tools like list_models and run_model by indicating this retrieves the actual schema of a model. The purpose is immediately 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 explicitly instructs 'Call this before run_model so inputs match what the model actually accepts,' providing clear when-to-use guidance and a workflow relationship with a sibling tool. It does not list alternatives or exclusions, so it stops short of a perfect 5, but the context is 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 provide readOnlyHint=true, so the agent knows this is a safe read operation. The description adds the recovery use-case context but doesn't disclose additional behaviors like error handling, response structure, or rate limits. With annotation coverage, a 3 is appropriate.

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, no redundancy, completely front-loaded with the core action and purpose. 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?

For a simple single-parameter read-only tool with annotations covering safety, the description fully conveys what it does and when to use it. No output schema exists, so explaining 'status and outputs' is sufficient.

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 single parameter 'id' is fully described in the schema ('Prediction id returned by run_model'), achieving 100% coverage. The description adds no extra semantics but also doesn't need to since the schema is clear. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool fetches the status and outputs of a prediction by id, using the specific verb 'fetch' and resource 'prediction'. It also includes a specific use case (recover from wait limit) that distinguishes it from siblings like run_model.

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 explicitly says 'use to recover a run that hit the wait limit', giving a clear context when to use. It doesn't mention when not to use or name alternatives, but the purpose is unique among siblings (list_models, run_model, etc.), so the guideline 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?

The description adds meaningful behavioral context beyond the annotations: it is free/no-charge, it does not execute the run, and the estimated cost depends on the provided inputs. It does not explicitly describe response shape or potential edge cases, but for a pricing-estimate tool this is reasonably 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?

The description is two sentences and front-loads the core function: estimate cost before executing, no charge. Every sentence adds actionable value without repetition or unnecessary 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?

Given the simple parameter surface and no output schema, the description covers the main pieces needed to invoke the tool correctly: what it returns conceptually, when it runs, whether it charges, and how inputs affect it. A bit more detail on the output format would make it even stronger.

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 already high, with model and input clearly described. The description enriches parameter understanding by explaining that input should mirror run_model inputs and that duration/resolution-style values can affect pricing, which is useful semantic context.

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 tool's purpose: estimate the cost of a run before executing it, and explicitly notes there is no charge. It is clearly distinguished from run_model by describing it as the pre-execution cost-estimation step that provides the same inputs.

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 strong usage guidance by instructing users to provide the same input they would pass to run_model and mentions that pricing often depends on input values. It does not explicitly say when not to use it, but the 'before executing it' framing makes the intended use 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 provide readOnlyHint and openWorldHint, which the description reinforces by calling the catalog 'live' and implying dynamic results. It adds context about the cache (1h) via the refresh parameter but does not fully explain what 'live' means beyond the cache. Beyond annotations, it conveys that results are dynamic and authoritative, which is valuable.

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 two sentences, front-loaded with the core purpose, and every sentence earns its place. It is concise and structured effectively.

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 list tool with high schema coverage and no output schema, the description is complete enough. It addresses the need to know that results are model IDs for run_model and warns against fabrication, which covers the key contextual requirements. Slight deduction for not detailing the return format (e.g., list of objects) but it's not critical given the schema.

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%, with each parameter having a description, so the baseline is 3. The description adds value by connecting the tool's output to run_model and emphasizing that returned IDs are authoritative, but it does not add parameter-specific details beyond the schema. The refresh parameter's purpose (bypass cache) is already in the schema, so extra credit is limited.

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 tool searches the live WaveSpeed model catalog across modalities (image, video, audio, 3D) and returns model IDs, clearly distinguishing it from siblings like run_model. It uses a specific verb (search) and resource (model catalog), making its purpose 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?

It explicitly instructs agents to use returned model IDs with run_model and warns against inventing IDs, which clarifies when to use this tool in the workflow. While it doesn't explicitly state when not to use it, the guidance to always use this tool for obtaining model IDs is strong usage direction.

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 indicate readOnly=false, openWorld=true, idempotent=false, and destructive=false. The description adds valuable behavioral details such as local file upload-and-replace semantics, bare paths not being uploaded, the task continuing after the wait limit, and the recovery mechanism via get_prediction.

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 enumerative, front-loaded sentences cover the core purpose, parameters, file-upload nuance, output type, and timeout recovery. Nothing is redundant; every sentence carries operational or informational weight.

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 3-parameter model-steering tool with no output schema and nested inputs, the description covers the critical inputs, file upload caveat, output expectation, asynchronous wait timeout, and recovery path. It leaves no crucial behavioral gap for selecting and invoking the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, but the description adds meaningful semantics beyond the schema by explaining local file path handling (@./path), the upload-replacement behavior, how return URLs are produced, and the wait-limit continuation behavior. This directly supplements the input and wait_seconds parameter 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?

Description opens with a specific verb and resource: "Run any WaveSpeed model," immediately distinguishing this from sibling list_models and get_model_schema. It also references returning output URLs and the recovery path via get_prediction, making the tool's role unmistakable.

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 clear usage context: input keys come from get_model_schema, local files need a @./path prefix, and wait-limit timeouts should be recovered with get_prediction. It doesn't state explicit 'when not to use this tool' exclusions, but the references to sibling tools provide enough guidance for orchestration.

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 indicate idempotentHint=true, but the description adds the specific 24-hour reuse window and that it returns a hosted URL. This goes beyond the annotations by explaining the dedup behavior and the return value, though it doesn't detail side effects beyond the upload. No contradiction 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 sentences, front-loaded with the core action and purpose. The second sentence provides usage guidance. Every word earns its place, with no redundancy or fluff. Perfectly 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 simple one-parameter tool with no output schema, the description covers the purpose, the return value (hosted URL), the dedup behavior, and the typical usage context relative to siblings. It's fully self-sufficient without needing additional details.

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 single parameter 'path' is already described in the schema with 'Local file path.' The description adds no additional semantic information about the path format, restrictions, or how it relates to the '@./path' convention. Since schema coverage is 100% and there's only one simple parameter, a baseline 3 is appropriate.

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: 'Upload a local file to WaveSpeed and get its hosted URL.' It also mentions the deduplication behavior (identical bytes reuse the same upload) and distinguishes itself from run_model, which handles the same input natively. This is a specific verb+resource with clear 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?

Explicitly states when this tool is usually unnecessary and gives the alternative: 'Usually unnecessary — run_model handles '@./path' inputs itself.' This is direct when-not-to-use guidance with a named alternative, making it exceptionally clear for the agent.

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