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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the description correctly adds the operational boundary (queued only) and the state change. It doesn't explicitly mention idempotency or failure behavior for non-queued tasks, but the annotations cover idempotency and safety, and the description adds sufficient scoping context without contradicting structured data.

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 with zero fluff. The core action and scope are front-loaded, and the alternative is placed second. 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 2-parameter tool with full schema coverage, an output schema present, and annotations covering safety, the description covers what it does, when to use it, and what to use instead. Nothing an agent needs to call it correctly 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?

Both parameters are fully described in the schema (coverage 100%), so the description adds no new meaning beyond what's already documented. It doesn't clarify when to prefer taskid over tasktoken or how they interact, so it stays at the baseline expected when schemas carry the semantic load.

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 action (cancel), a resource (task), and a clear condition (still queued, before worker assignment). It also explicitly differentiates from the sibling `kill_task`, which handles started tasks, making it easy for an agent to select the correct tool.

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 provides the alternative: 'Use `kill_task` for a task that has already started.' This gives a clear when-to-use and when-not-to-use directive, leaving no ambiguity about which tool fits which scenario.

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 cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the bar is lower. The description adds the curation/grouping behavior and the workflow context, which is useful but not extensive. No contradiction with annotations; 'Browse' is consistent with the read-only flags.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero waste. The purpose is front-loaded in the first sentence and the actionable workflow directive sits in the second. 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 parameterless browse tool with an output schema (so return format needs no explanation) and annotations covering the safety profile, the description is nearly complete. The only minor gap is not explicitly distinguishing itself from search_models, but an agent can still call 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?

The tool has zero parameters, so the baseline is 4 per the rubric. Schema description coverage is vacuously complete. There is nothing to document, and the description appropriately spends no space on 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 ('Browse') plus a well-characterized resource ('curated Wiro models grouped by category'). The curation and grouping qualifier is what makes it distinct from the sibling search_models, so an agent can tell them apart 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?

It gives a clear workflow directive: 'Choose a model and call get_model_schema before run_model', which tells the agent what to do after exploring. It doesn't, however, explicitly explain when to reach for explore versus the search_models sibling, so the usage guidance is strong on next-steps but lacks an explicit exclusion.

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, openWorld, idempotent, non-destructive, so the description does not need to restate those. It adds behavioral value by revealing that the response contains a run_model action to follow exactly once and demonstrating how previousTaskToken should be used. 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?

The primary action is front-loaded in the first sentence, and the following sentences earn their place by describing the workflow. The second sentence is dense and slightly ambiguous ('use it with toolOutputs'), but overall the text is appropriately sized 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?

With an output schema present and strong annotations, the description covers what the returned schema includes and how to proceed (fill required parameters, follow run_model once). It does not spell out error handling or non-existent model slugs, but nothing critical for correct invocation appears 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 only parameter, `model`, has 100% schema description coverage with format and examples, so the baseline is 3. The description does not add new input-parameter semantics beyond the schema; its extra detail targets the returned schema content rather than the `model` argument.

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 opening sentence names the verb 'Get', a specific resource ('one model’s typed parameters, options, defaults, required fields, and pricing'), and clearly distinguishes this from siblings like run_model/search_models by framing it as schema discovery. The mention of catalog fields and the returned `run_model` action leaves no ambiguity about the tool’s purpose.

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 clear context: this is the prerequisite to run a model ('Follow the returned run_model next action exactly once') and states that catalog fields must be discovered here. It lacks explicit exclusions or comparisons with sibling alternatives such as explore or search_models, but it does convey when it should be used in the workflow.

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 behavior. The description adds meaningful behavioral context beyond annotations: active-task nextAction handling, ordered typed segments for completed runs, the run_model continuation template, and the requirement to show media resources. 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?

The description is front-loaded with the core purpose and each subsequent sentence adds a distinct behavior or constraint. There is no filler, repetition, or 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?

An output schema exists, so return values need not be explained. The description covers the key pitfalls an agent faces: not resubmitting active tasks, following nextAction, and including media in the user-facing response. With annotations covering the safety profile, nothing essential 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?

Schema description coverage is 100% for all three parameters, so the schema already documents taskid, tasktoken, and wait_seconds. The description does not add parameter-level meaning, though it reinforces the default immediate check consistent with wait_seconds defaulting to 0.

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 the current status and output of one task.' It explains the default immediate-check behavior, which helps distinguish it from run_model and wait_for_task, though it does not explicitly name sibling alternatives.

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 actionable usage guidance: for active tasks, follow the returned nextAction instead of submitting another run, and present media resources when complete. It does not explicitly explain when to choose wait_for_task over this tool, but the provided context is sufficient for most routing decisions.

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, so the safety profile is covered. The description adds valuable behavioral context: the billing condition (successful billed, failed not) and the next action (wait_for_task if active). This enriches understanding beyond annotations without contradiction.

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 with no unnecessary words. The primary purpose is front-loaded ('Get one task’s final charged cost'), and the subsidiary conditions follow. Every sentence earns its place with essential information.

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 retrieval tool with an output schema present and annotations covering safety, the description is complete. It explains the billing rule and the next action for active tasks, which are the non-obvious aspects. Nothing an agent needs to call this tool correctly 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?

Schema description coverage is 100%, with both taskid and tasktoken fully documented. The description does not add any parameter-specific meaning beyond the schema, so the baseline of 3 is appropriate. No additional semantic value 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?

The description clearly states the specific verb 'Get' and resource 'one task’s final charged cost'. It also adds the distinction that successful tasks are billed while failed ones are not, which differentiates this from the generic get_task. The purpose is unambiguous and distinct from 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?

No guidance is provided on when to use this tool versus alternatives like get_task or list_tasks. The only conditional is 'If the task is active, follow the returned wait_for_task', which is a post-call instruction rather than tool-selection guidance. The description does not help the agent choose between this and sibling tools.

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

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

Annotations already declare `destructiveHint: true` and `readOnlyHint: false`, but the description adds valuable context by stating that it 'changes remote state' and 'can discard in-progress work.' This goes beyond the annotations by specifying exactly what kind of destructive impact occurs. The description does not contradict annotations and provides useful specifics about 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?

The description is three sentences, each serving a distinct purpose: stating the action, noting side effects, and providing usage differentiation. It is tightly written with no filler or redundancy, and the core action is front-loaded. 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?

Given that an output schema exists, the description does not need to explain return values. It covers the tool's action, side effects, and when to use it versus the alternative, which is sufficient for an agent to call it correctly. Annotations handle idempotency and destructive intent, and the description fills in the behavioral nuance (discard of in-progress work). The definition is complete for this operation.

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 already describes both `taskid` and `tasktoken` with full coverage (100%). The description does not add detailed parameter semantics, but it implicitly conveys that either parameter can be used to identify the task, which is already clear from the schema. Given the high schema coverage, a baseline score of 3 is appropriate; the description does not need to repeat parameter info.

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: to stop a task that is already running. It uses a specific verb ('Stop') and resource ('task') and immediately differentiates itself from the sibling tool `cancel_task`. This eliminates ambiguity about what the tool does and which situation it targets.

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 directs the agent to use `cancel_task` for queued tasks, while this tool is for running tasks. It provides a clear binary condition and names the alternative tool, leaving no room for incorrect selection based on task state.

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=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavior beyond these: the caller identity is derived from authentication and no user UUID is accepted, which is important for invocation. It also specifies the 'recent' temporal scope.

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 purpose, followed by usage workflow and an essential authentication constraint. Every sentence earns its place; there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is low-complexity with 0 required parameters, robust annotations, 100% schema coverage, and an output schema present. The description covers purpose, scope, follow-up workflow, and authentication, leaving no significant gap for correct invocation.

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%, so the schema already documents the limit, model, and start parameters. The description adds no additional parameter-level meaning, but none is needed given the complete 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?

Begins with a specific verb and resource: 'List the authenticated project's recent model-generation tasks.' It clearly scopes the operation to recent tasks and distinguishes it from the sibling get_task by mentioning that get_task returns the complete result for a returned task ID.

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 to use the tool: 'Use this to find work from previous conversations, then call get_task with a returned task ID.' This provides clear context and the follow-up workflow, though it does not name alternative list/filter tools or explicitly state when not to use 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. Beyond those, the description adds the critical behavioral detail that the tool returns a `get_model_schema` next action, guiding the agent's workflow. This enriches the annotation coverage, though not exhaustively.

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, highly efficient. The main purpose is front-loaded, and the follow-up action is stated crisply. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description need not detail return values. It explains the purpose and the immediate next step. It lacks explicit mention of when to avoid this tool (e.g., when a specific model name is known), but that is a usage-guideline gap rather than a completeness gap. Overall adequate for a recommendation 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 schema covers the single 'task' parameter with a clear description and example. The tool description reiterates 'natural language' but does not add significant new meaning beyond the schema. Baseline 3 is appropriate given full schema coverage.

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

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

The description states a specific verb ('recommend') and resource ('models') based on a natural language goal, clearly distinguishing it from siblings like search_models or get_model_schema. It explains the purpose without 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 implies usage timing ('before running a model') and mentions the next action, but does not explicitly contrast with alternatives like search_models or state when NOT to use this tool. The guidance is present but minimal.

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?

Despite annotations already indicating non-readonly and non-idempotent behavior, the description adds crucial operational context: bounded waits, continuation mechanics, file parameter URL handling, and the requirement to render media results to the user. These details go well beyond the structured annotation fields and materially shape how the agent must behave.

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 dense but every sentence carries operational weight. It front-loads the core action, then walks through the async and continuation flows in a logical order without repeating schema content or including 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 tool this complex—with async behavior, continuations, file params, and a rich output schema—the description covers the essential call flow, edge cases, and user-facing obligations. The presence of an output schema and sibling tools further supports a complete context without needing to restate return structures.

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 100% and each parameter already has a description, but the tool description adds high-value semantics: how to pass JSON values, how to continue a completed turn with toolOutputs or messages, and how to handle file input types including combinefileinput arrays. This meaningfully supplements the 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 opens with a crisp verb+resource statement: 'Run any AI model on Wiro' and enumerates supported modalities. It clearly identifies the tool as the execution entry point, and sibling tools like get_model_schema and wait_for_task are contextually distinct without needing to be named.

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 explicit procedural guidance: call get_model_schema first, use wait=true for bounded polling, delegate to wait_for_task when nextAction appears, do not resubmit, and complete continuation templates. It also distinguishes the completed-tool-call flow from the initial invocation, which is essential for correct use.

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=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, indicating a safe read-only operation. The description does not add further behavioral context such as result format, pagination, or any caveats about searching. With the safety profile covered by annotations, the description's minimal addition is acceptable but not enriching.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that immediately communicates the tool's purpose. It is front-loaded with the action and resource, with no wasted words or redundant information. 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?

Given the tool's simplicity (one parameter, read-only, clear scope), the description is complete. An output schema exists, so explanation of return values is unnecessary. The description fully conveys what an agent needs to correctly invoke this tool for documentation searches, and there are no missing critical 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 'query' is fully described in the schema with concrete examples (e.g., 'how to upload a file', 'websocket'), giving 100% schema coverage. The description does not add any additional semantics or usage details beyond what the schema provides. Per the baseline rule, with full schema coverage, this is a reasonable score.

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 'Search' and clearly identifies the resource: 'official Wiro guides, API references, examples, and how-to documentation.' This is not a tautology and clearly distinguishes it from sibling tools like search_models, which searches models. An agent can immediately know what this tool does and what it does not do.

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 states what it searches but does not explicitly say when to use it versus alternatives, nor does it provide exclusions or alternative tool routing. While the resource scope implies usage for documentation queries, there is no explicit guidance, so an agent might need to infer context from sibling names. This is adequate but leaves room for improvement.

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=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the behavioral instruction to proceed to get_model_schema and run_model, which is useful context beyond the annotations. It does not contradict any annotation and provides a touch of workflow transparency.

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 with zero fluff. It front-loads the primary purpose and then delivers the key workflow instruction. Every word earns its place; it is succinct and well-structured.

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 search tool with a rich output schema and high schema coverage, the description is largely complete. It includes the essential post-search workflow (get_model_schema, run_model). It doesn't spell out when not to use the tool versus siblings, but this is a minor gap for a search function. Overall, the description supplies sufficient context for correct invocation.

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%, so each parameter (sort, limit, start, search, slugowner, categories) is already well-documented. The description adds no additional parameter semantics beyond what the schema provides. Per the rubric, a baseline of 3 is appropriate when the schema does the heavy lifting.

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 function: 'Search and browse AI models on Wiro.' It also details a specific workflow ('call the returned get_model_schema next action before using run_model') which distinguishes it from siblings like recommend_model or explore. This gives an agent an unambiguous understanding of what the tool does and when it fits into the overall model-running process.

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 clear guidance on how to use the tool: select a result and then call get_model_schema before run_model. This defines the expected usage flow. It does not explicitly contrast with alternative tools (e.g., explore or recommend_model), but the workflow hint implicitly signals when this tool is appropriate (when a search is needed before running a model).

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, covering the mutation nature and non-idempotency. The description adds the 'remotely accessible file' clarity (implying fetching from a URL) but doesn't disclose potential side effects like storage limits, overwrites, or failure modes. Given annotations carry the safety profile and the description adds some context, it's adequate but not rich.

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 succinct sentences with zero fluff. The primary purpose is front-loaded, and the usage guidance is placed right after. Every sentence serves a purpose and the formatting is tight.

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 an output schema (which would define return values), annotations cover the safety profile, and the schema covers parameters, the description provides the essential context: what it does, when to use it, and the source requirement. It could mention storage implications or return values, but those are covered by structured data, so this is complete enough for an agent to call 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 100% for both parameters (url and file_name). The description itself doesn't add parameter-specific meaning beyond the schema; it implicitly references the url via 'remotely accessible file' but provides no extra formatting or constraints. Baseline 3 is appropriate since the schema handles parameter documentation.

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 a specific verb (Upload) and resource (a remotely accessible file to Wiro). It also distinguishes this tool from siblings by noting that it's only needed when the model schema requires a Wiro-hosted file or the same file will be reused, which differentiates it from the task/model-related 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?

It explicitly articulates when to use this tool vs. direct URLs: 'Most models accept source URLs directly, so use this only when the model schema requires a Wiro-hosted file or the same file will be reused.' This gives clear usage conditions and implies not using it for simple cases, effectively routing the agent.

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?

Beyond readOnlyHint/idempotentHint, the description discloses the polling loop ('repeat the exact nextAction'), the instruction not to resubmit, and the special run_model continuation-template case. It also specifies user-facing response requirements for completed tasks, which annotations could not convey.

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 sentences, each carrying a distinct operational fact: purpose, repeated-call behavior, continuation-template caveat, and final response expectation. It is front-loaded with the core purpose and contains 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 waiting tool with a full schema and output schema, the description supplies the missing behavioral context: it tells the agent how to poll, what not to resubmit, and how to present the final result. Nothing necessary to invoke it correctly is left unexplained.

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 already documents all three parameters at 100% coverage, including the taskid vs tasktoken relationship and the timeout default. The description adds no additional parameter-level meaning, so the baseline of 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 uses a specific verb and resource ('wait for an existing Wiro task') and immediately disambiguates from run_model by saying 'without submitting a new model run.' The follow-on instructions about repeating nextAction also separate it from one-shot status lookups like get_task.

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 clearly states when to call this tool (after an existing task exists) and what to do when the task is still running, and it warns not to resubmit the original request. It does not explicitly name a lighter-weight alternative such as get_task for non-blocking status checks, so it stops short of a full when/when-not/alternatives profile.

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