OpenRouter

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

Annotations already indicate this is not a read-only or idempotent operation, and the description adds meaningful behavioral context: the image is returned as an inline image content block (so it can be rendered by clients and seen by the model) and, critically, 'This bills the authenticated user for the generation.' That goes beyond what annotations provide and informs the agent of real-world consequences and cost.

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 the core action in the first sentence and essential behavioral content in the second. It avoids repeating schema details, includes necessary financial context, and provides the inline-output type without any padding.

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 no output schema, the description covers the key action, the return format (image content block), how it's consumed, and the billing aspect. It doesn't describe failure modes or all possible client behaviors, but this is a complete enough for selecting and invoking the tool with confidence.

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 baseline applies and the description doesn't add meaningful parameter-level detail beyond what the schema already documents. The prompt, model, and size are all explained in the schema, and the description's mention of 'text prompt' is redundant with 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 specific verb and resource: 'Generate an image from a text prompt and return it inline.' This clearly distinguishes it from audio-related siblings like generate-speech and transcribe-audio, making the tool's purpose immediately understandable.

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 context on when to use the tool: it is for text-to-image generation with inline image output, and explains how the result is presented to clients and the model. It doesn't explicitly exclude alternatives, but the behavior description is sufficient to guide usage for image generation rather than speech or other MCP actions.

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 the annotation values, the description discloses a real side effect: 'This bills the authenticated user.' It also explains the inline-audio output and client compatibility caveat, and points to get-generation for cost afterward. That gives the agent materially useful behavioral context that annotations alone do not provide.

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 core function and output type appear first, followed by billing and the discovery workflow. Each sentence contributes essential operational or discovery information; there is no filler or redundancy.

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 generative audio tool with no output schema, this description covers invocation prerequisites, how to get the right inputs, what to expect in the response, cost implications, and potential client limitations. An agent has enough information to reason about using this tool and checking 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 coverage is already 100%, so the baseline is solid. The description adds value by explaining how to find valid model and voice values: find models with output_modalities=speech and fetch supported_voices via get-model. This directly helps an agent select values for required parameters rather than only knowing their types.

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 (synthesize) plus a clear resource (speech from text), and explains the audio content-block output. This cleanly distinguishes it from sibling tools like generate-image and transcribe-audio.

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 tells an agent the exact discovery workflow: list TTS models via list-models with output_modalities=speech and find voices via get-model. It also calls out a client-side constraint ('not all MCP clients can play audio') that helps decide whether this tool is appropriate. It does not explicitly exclude alternatives such as transcribe-audio, but for generation the intended path is clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so they cover the safety profile. The description adds the 'remaining balance' scoping but does not add deeper behavioral context such as return shape, rate limits, or account-specific requirements. This is acceptable 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?

The description is a single well-structured sentence with no filler. The core action and timing are both 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 parameterless read-only tool, this description is complete enough: the agent knows what the tool checks, and when to use it. No output schema exists, but the concept of checking a remaining balance sufficiently implies the returned 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 tool has zero parameters, so parameter semantics are trivially satisfied. The schema already communicates 100% coverage, and the description does not need to explain properties that do not exist.

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 ('Check') and a specific resource ('remaining account credit balance'), and it names the intended use case ('before running a workload'). This clearly distinguishes the tool from sibling tools, none of which target credit/balance.

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 context for when to call the tool, namely before running a workload. It does not list exclusion conditions or name alternative tools, but the unique use context is strong enough for an agent to route correctly.

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 reveal readOnlyHint=true, idempotentHint=true, and destructrentHint=false. The description adds useful behavioral context: it returns an hourly timeline of per-provider uptime and mirrors the model-page uptime graph. It does not discuss endpoint rate limits or response structure, but the annotations and use-case context cover the main operator-safety concerns.

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 no wasted words. The primary behavior is front-loaded, and the usage example is compact and useful. Toose without describing structure or unrelated details.

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

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

With no output schema, the description gives enough shape to the response by calling out the per-provider uptime timeline shown on the model page. It does not specify the exact uptime metric fields or status codes, but for a read-only history lookup this is a practical 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 schema descriptions cover 100% of parameters, including example values for 'to' and 'from' and clarification that 'slug' can include a variant suffix. The description does not add parameter-specific syntax or semantics beyond that, so the schema already carries the 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 the exact action ('Get'), the resource ('hourly uptime history of every provider endpoint serving a model'), and the time constraints ('last 72 hours'). It is easy to distinguish from the sibling list/read tools because it specifically focuses on uptime history per provider endpoint.

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 explains when to use this tool: to find which provider degraded during a window, with a concrete example. It does not name alternatives or explicitly state when-not-to-use-it, but no sibling appears to directly overlap with uptime history, so 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?

Annotations already cover read-only, idempotent, non-destructive behavior, so the additional requirement is to give real behavioral context beyond the schema. The description provides that context: what metrics are exposed and where the ID originates. It does not describe response shape or error cases, but the tool is small and read-only.

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: the first front-loads what the tool does and why it matters, the second explains how to get the generation id. There is no wasted wording or redundant repetition beyond what the schema already provides.

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 read-only inspector, the description gives enough context to understand why the tool exists, what it returns at a high level (cost, token counts, provider), and how the input id is obtained. The absence of an output schema makes this level of return-field context important, and the description provides it.

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 only gives a one-line description of the 'id' field, which is thin, but the overall description compensates by explaining that the parameter is a specific generation id and that send-message returns it in its output. This provenance is more valuable than a generic field description and helps the agent know exactly how to obtain the id.

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 tool name and description both make the target clear: inspect a generation by ID. The description specifies concrete data returned (cost, token counts, serving provider) and names the purpose (debugging spend and routing), which distinguishes it from sibling tools like get-model or get-credits.

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 a clear invocation context: use it after send-message, which returns the generation id. It justifies the tool's purpose rather than just describing it. It could be stronger with an explicit statement about when not to use it or how it relates to alternatives, but the intended usage is not ambiguous.

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 annotations already indicate readOnlyHint=true, which is consistent with the read-only nature of 'Get full details'. The description adds meaningful behavioral context beyond the annotations: the tool supports :variant suffixes and slug aliases, and it avoids pulling the whole catalog. This is useful operational detail, though the exact return payload is not described.

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 carry the complete usage context: what the tool does, what extra syntax is supports, and when to choose it over the sibling tool. There is no redundant or filler language.

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 single-model lookup tool, the description covers the key context: the resource key, the supported identifier formats, and the relationship to list-models. It does not specify what 'full details' includes, but given the small scope and the absence of an output schema, the description is enough for safe 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?

The description adds semantic information to the otherwise sparsely documented top-level 'request' parameter by explaining that identification happens via author/slug and that variants and aliases are accepted. It also contextualizes the nested slug description from the schema by tying it to the tool's purpose.

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: 'Get full details for one model by author/slug', identifies the resource type, and immediately differentiates it from list-models by emphasizing it avoids fetching the whole catalog. An agent can quickly understand what this tool does and how it differs from its 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?

The description explicitly says to use this instead of list-models when the model is already known. This gives a direct when-to-use guideline and names the alternative, leaving no ambiguity about tool selection.

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 read-only, idempotent, non-destructive behavior, so the description's job is lighter. The description adds useful transparency by disclosing exactly what payload is returned (config bundle with specific fields) and that it is a single preset with a version selection, which helps set expectations. No contradictions with annotations appear.

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 are focused and efficient: the first describes the core action and what is returned, the second gives practical routing for finding slugs. 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?

For a single-parameter read operation, the description covers the main aspects: what to pass (slug), where to find it (list-presets), and what will be returned (config bundle with sampled parameters). Since there is no output schema, describing the returned fields is important and appears to be good; only minor edge-case behavior like invalid slugs or missing presets is left unspecified.

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 0% schema description coverage, the description must compensate. It identifies the only parameter as a 'slug' and points to list-presets for finding valid slugs, which is helpful but does not elaborate on slug format or behavior if the slug is invalid. Given that there is only one parameter, this is adequate but not detailed.

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-resource pair ('Get one saved preset by slug') and clearly identifies the returned content (the designated version's config bundle with model, system prompt, temperature, and sampling parameters). It also implicitly differentiates from list-presets by focusing on a single item and pointing to list-presets for discovery.

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 context for when to use this tool: when you need one saved preset's configuration to inspect or reuse. It also names list-presets as the source for finding slugs, which is a clear alternative for discovering presets. It does not explicitly state when not to use this tool, but the recommendation is clear enough.

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 annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe read-only nature of the call is covered. The description adds important behavioral context: the tool returns a recipe the agent is expected to follow, mentions OAuth sign-in without an API key, includes verification and upgrade commands, and exposes the same document at a public URL.

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?

Every sentence earns its place: the first says what to do, the second enumerates trigger scenarios and recipe contents, and the third lists exclusions and the public source. The trigger conditions are front-loaded and the description is dense but not padded.

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-argument, read-only instruction-retrieval tool, the description is complete. It explains what the tool does, when to call it, what it returns, what it does not cover, and where the same content is published. No output schema exists, but the description fully covers the return value's relevance.

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 schema coverage is 100%, so the schema leaves nothing to explain. The description reinforces this by explicitly saying 'Takes no arguments,' which removes any ambiguity. With no parameters, this is as helpful as possible.

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 ('Get the instructions... then follow them'), the resource (Ori Harness), and the exact user intents that should trigger it. It is easy to distinguish from siblings like spawn-ori-eval because it explicitly covers install/sign-in/upgrade/run scenarios and excludes evaluation use cases.

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 trigger conditions ('Call this tool FIRST when the user asks to...') and explicit non-uses ('Do not use it for Ori model evaluations, plain unit tests, or... already-installed agent directly'). It does not name the alternative tool to use instead, though the sibling spawn-ori-eval strongly implies where model evaluations belong.

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 annotations already establish readOnlyHint=true and idempotentHint=true, so the description does not need to restate safety. It adds some context about the returned concept (traffic per app, filterable by category) but does not disclose extra behaviors such as date default, window clamping, or result shape. That is a moderate gap, so 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?

Two compact sentences, front-loaded with the core function, and ends with the specific sibling alternative. Every clause earns its place and no repeated information is present.

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 gives a clear use case and search and points to the relevant alternative. The structured schema carries detail for defaults/enums, while the description handles high-level intent; given no output schema, one could wish for return-format hints, but the high-level usage remains complete and navigable for a read 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_description_coverage is 0%, so the description must compensate for parameter gaps but only mentions 'filterable by category' and does not mention sort, limit, offset, or date. The nested schema has rich docs, but the tool description itself does not add sufficient parameter-level guidance beyond what a user might guess. This undercovers the nested 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 the specific verb and resource: 'See which APPs/products drive the most OpenRouter traffic' and clarifies the optional category filter. It also names the sibling alternative, list-daily-model-rankings, making the purpose unambiguous and 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?

It explicitly tells the agent when to use this tool (to gauge ecosystem adoption and find example use cases) and when not to use it ('For model rankings use list-daily-model-rankings instead'). This both sets the context and provides a clear alternative.

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 annotations already mark this as read-only and idempotent, so no destructive warnings are needed. The description adds useful behavior al detail: result structure varies by source, source are combined when omitted, and task_type narrows model suitability. It leaves details like rate limits and pagination unspecified, but those are not central for this read-only list operation.

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 sentences: purpose, source/result mapping, and filtering behavior. Each sentence contributes a meaningful chunk of guidance, and the highest-level distinguishing detail is front-loaded.

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

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

The description handles the two main sources, the all-source fallback, and task_type filtering, which covers the core flow. The only meaningful gap is that the third source, openrouter, is in the schema but not given the same result-shape explanation; a fuller sentence about what source=openrouter returns would make the description complete.

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

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

The description adds meaning beyond the schema by explaining that source selects both the dataset and the result shape, and that task_type maps to index/category semantics. The input schema's nested param descriptions handle details like arena, category, search_engine, and include_run_config; the tool description still adds the high-level relationship between source, return shape, and task_type.

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

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

The description opens with a specific verb-resource pair: "Compare model quality beyond price using third-party benchmarks." It names the concrete sources and the shapes they return, which distinguishes it from sibling tools like list-models and the ranking lists.

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 supply source, what each source returns, and the impact of omitting source. It also explains how task_type filters. It does not explicitly contrast against sibling benchmark/ranking tools, but for this tool's own options the guidance is actionable.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds one useful behavioral caveat — that category and language_type slices are 'sampled weekly send-stemations', which is valuable because those values are approximate rather than exact. However, it does not mention timing bounds, granularity limits (e.g. day not available with those slices), or any rate/pagination behavior, and since no output schema exists the response format is left undisclosed.

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 a front-loaded purpose, followed by the optional slice summary and the sibling distinction. Every sentence earns its place, and the most important call-intention (the app/model split) is saved for the end as a closing routing note. It is compact and scannable.

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 7 nested parameters and no output schema, the definition is adequate but has gaps: it never states what the response looks off (e.g. per-model rank, token totals), how many results are returned, or how `total_tokens` is aggregated across the sampled and exact datasets. The nested schedule covers parameter mechanics well, and the description covers purpose the active trade-off, but the combination leaves an agent guessing at output structure.

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 at the top level is 0% — the single `request` wrapper parameter has no description, though its seven nested properties carry rich per-paramer text on defaults, restrictions, and data sources. The description partially compensated by naming the slice dimensions (period, modality, context_bucket, category, language_file) and flagging which produce sampled estimates, but it does not explain that all arguments must be nested inside `request` nor does it add per-parameter details beyond what the schema already states.

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 ('which models are most used and trending by token volume') and a clear business purpose ('to pick a proven model'). It also explicitly names the closest sibling alternative ('For app/product rankings use list-app-rankings instead'), so an agent can immediately distinguish it from the one tool it could be confused with.

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 a concrete selection criterion (token-volume usage/trend, to pick a proven model) and calls out the key alternative (list-app-rankings) with an explicit 'instead'. It does not enumerate other nearby siblings like list-benchmarks or list-models, but the main confusion risk is addressed.

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 compute readOnlyHint/idempotentHint/destructiveHint, so the description only needs to add context beyond them. It does add content by disclosing exactly what data the list contains (price, latency, throughput, data-policy), which is valuable because there is no output schema.

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

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

The description is one efficiently packed sentence thatfront-loads the action and resource, then lists the result fields and the intended purpose. Nothing is wasted.

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 lookup with two required string parameters, the description tells the agent what it will receive (provider list plus metrics), which covers the main guidance need. #The lack of output schema is compensated by listing the returned fields; only exact response format/pagination is undeclared.

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% according to the provided context signal, and the description does not compensate: it says 'a given model' but never explains the needed author/slug parameters or their format. The nested slug and author fields also receive only the minimal one-line descriptions in the schema itself.

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 the verb (List), the resource (provenders serving a given model), and the core data (price, latency, throughput, data-policy), which differentiates it from siblings like list-providers and list-models. It states the purpose clearly: to choose routing or debug a slow provider.

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 'to choose routing or debug a slow provider' gives clear context for when the tool is useful. It does not explicitly name sibling alternatives or when-not-to-use conditions, so it stops short of 5.

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 carry the readOnlyHint and idempotentHint, so the description does not need to re-state safety. It adds context like 'live catalog' and server-side sorting/filtering, but it does not describe rate limits, pagination defaults, or the exact response structure—minor gaps for a read-only list operation.

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 well-organized: purpose first, then search/sort, then filters. Every section earns its place, and the long parameter list is appropriate for a tool with this many options.

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

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

With no output schema, the description compensates by listing what the catalog contains: pricing, context length, modalities, supported parameters, and benchmarks. It doesn't spell out the exact wire format, but an agent will know what to expect when invoking it.

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?

Although the JSON schema documents each parameter, the description adds practical meaning: units ($/M), fraction ranges for tool success, case-sensitivity for providers, and the existence of server-side sort/filter alternatives. This helps an agent understand the parameter space quickly without reading the full 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 first line names the verb ('List'), the resource ('live OpenRouter model catalog'), and the key fields it returns, making the tool's purpose unmistakable. It also names the outcome ('pick a model and wire the right slug into code'), which clearly separates it from sibling tools like get-model and list-model-endpoints.

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 says when to use this tool: to inspect the catalog, choose a model, and use server-side search/sort/filter. It does not explicitly compare itself to alternatives or state exclusions, but the use case is clear enough for an 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?

Annotations already cover readOnly, idempotent, and non-destructive behavior. The description adds meaningful context: only the caller's presets are returned, results are ordered by most recently updated, and returned data consists of slugs rather than full configurations. This goes beyond what the annotations alone reveal.

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 well-structured sentences. The first communicates purpose, scope, and ordering; the second gives direct usage guidance and names the alternative tool. No word is wasted and the most important information is front-loaded.

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

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

Given the simple list operation, the description is complete: 'identifies scope, ordering, return content, and the transition to get-preset. Paginated behavior is not mentioned beyond the schema, and there is no output schema, but the tool's purpose and expected usage is still well 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?

The description does not describe limit or offset semantics, but the input schema includes nested descriptions for both. The schema carries most of the parameter burden, so the description adds little at the peveve. The exposed 'request' wrapper itself is not explained, but the parameters may still be discovered from 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 states a specific verb and resource: 'List the caller's saved presets', defines what a preset is, and even notes the ordering. It also distinguishes itself from get-preset by indicating this tool returns slugs rather than full configs.

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 explains when to use it: discover which presets exist and get their slugs. It names the alternative, get-preset, for inspecting a single preset's full config, so the agent receives clear routing guidance.

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

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

Annotations already communicate that the tool is read-only, idempotent, and non-destructive. The description adds only the purpose of the returned data, not any extra behavioral nuances, so there is no contradiction and no need for more.

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 whole description is a single sentence that puts the action first, then the object, and then the intended usage. There is no redundant phrasing 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 tool takes no parameters and annotations fully describe its safety profile, the description is adequate for an agent to understand when and why to call it. It doesn't detail the output shape, but for a simple listing operation the phrase 'List available providers' covers the essential contract.

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 schema is trivially fully covered and no parameter documentation is required. The description correctly avoids inventing non-existent limitations.

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 ('List') and a clear resource ('available providers'), and adds the purpose of configuring allow/deny/routing preferences. This distinguishes it from sibling list tools like list-models or list-presets.

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 context: call this tool when you need to configure provider allow/deny/routing preferences. It does not explicitly mention when not to use it or name alternatives, but the intended scenario 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 present, the description carries the burden of behavioral disclosure and reveals a key limitation: shares are fractions (0-1) of sampled traffic and absolute volumes are not exposed. It also implicitly indicates time-windowed behavior and relative comparisons. This provides useful context beyond surface semantics, though it does not address potential rate limits, pagination, or detailed response format.

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 with no wasted words. The first sentence fronts the core purpose and output composition, the second provides usage direction, and the third states the key output caveat. It is dense with relevant information and remains 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?

The description illustrates the output structure (per-type breakdown, top models, macro-category aggregates) and clarifies the numeric semantics (fractions, no absolute volumes). Given the simple parameter set and no output schema, the description already answers most of the an agent needs for correct invocation. It does not mention authentication or rate limits/expectations, but these are unlikely to affect the call itself.

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, `window`, is already fully documented in the schema with an enum, default, and description. The tool description merely restates 'trailing window' and does not add grain of truth role coverage or alternative usage details. This matches the baseline 3 for a schema with high description 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 uses a clear verb-plus-resource construction: 'See what OpenRouter traffic is actually used for' and then specifies a market-share breakdown by task type, top models per task, and macro-category aggregates. This is distinctive from sibling tools like list_models or list_providers, even though no sibling is named. The full range of output is identified precisely.

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 includes an explicit use directive: 'Use to learn which models real usage favors for a given kind of work.' This gives clear guidance on when to invoke it. It does not explicitly contrast with siblings or mention when not to use it, but the intended use case is unambiguous and sufficient for an agent to choose it over alternatives.

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 tool's safety profile. The description adds a small behavioral context beyond annotations by explicitly stating the tool is a health-check that verifies liveness. It does not contradict annotations, and the description adds a value beyond what the schema alone provides.

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 extremely concise: a single sentence with no wasted words. It front-loads the core value ('health-check') and provides the purpose immediately. It slightly lacks structure, but for such a simple tool, this is near optimal.

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 indeed simple—zero parameters, no output schema—but the annotations cover the safety profile well. The description does not mention what would happen if the connection is unhealthy or what the response looks like, but that is unnecessary for a health check tool whose entire purpose is to confirm liveness and whose annotations already declare non-destructive behavior.

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 is empty with 0 parameters and schema description coverage is 100%, so the description adds no additional semantic value. The baseline for 0 parameters is 4, indicating the description is clear that this is a parameterless operation, which is appropriate for the ping use case.

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 simply restates the tool's purpose with a generic phrase: 'Health-check tool that verifies the MCP connection is alive.' It does not differentiate this tool from sibling tools or specify the exact resource being checked. While 'health-check' and 'verifies the MCP connection is alive' provide some clarity, the description is essentially a tautology of the name 'ping'.

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 when checking MCP connectivity, but there is no explicit guidance on when to use this tool versus alternatives like list-benchmarks or get-endpoint-uptime-history. A clear context is implied, but no exclusions or alternative comparisons are provided.

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 read-only, idempotent, non-destructive behavior. The description adds useful behavioral context beyond those: each result includes a 'View docs' link, and truncated results should be handled by fetching the link or sharing it with the user. 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 two sentences, front-loads the core purpose, and then provides result-handling behavior without wasted words. Every detail 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 documentation-search tool, the description fully covers how to use results, including what to do with truncated entries. There is no output schema, but the description compensates by explaining the link-sharing behavior, making the tool effectively complete for an agent.

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 parameters with 100% coverage. The description does not add much parameter-specific meaning beyond the schema, which is acceptable because the schema carries the load. 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 names a specific verb and resource: searching the full OpenRouter documentation for how-to questions with correct, current API usage. It also clarifies the intended purpose distinctly from surrounding tools because no sibling tool provides documentation search. The use case is immediately recognizable.

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 when to use the tool: to answer 'how do I…' questions about OpenRouter API usage. It does not explicitly mention alternatives or exclusions, but no other sibling tool covers documentation search, so the guidance is contextually sufficient.

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 explains that this is an action to transmit feedback and that it must reference a generated id, which the team acts on. However, it does not detail side effects, whether a submission can be overdrawn, or any auth/rate-limit implications. Given the annotations are all false and do not carry a safety profile, the description could do slightly more.

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 moderately long but every sentence contributes: the first sentence states the action, the second states when to use, the third explains the id source, and the fourth details the comment guidance. It is organized and front-loaded 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?

The description gives enough context for a correct invocation: what to submit, when to use the tool, which sibling tools supply the required generation id, and how to write a useful comment. With a single nested object and 100% schema coverage, this is complete for a feedback 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 already fully documents the request/category/generation_id/comment. The description adds valuable guidance on what the comment should contain: diagnostic context like 'what agent you are', harness, expected model, and discrepancy. This goes beyond the generic 'optional free-text comment' and helps the agent fill the field meaningfully.

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: 'Submit structured feedback on a specific generation the caller made'. It also clarifies the content (a category plus optional comment), so an agent can immediately distinguish this from general messaging tools like send-message.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit when-to-use guidance: 'Use after a generation had a problem... so the OpenRouter team can act on it.' It also identifies where the generation id comes from ('get-generation and send-message both return'). It stops short of naming explicit when-not-to-use conditions or alternative tools for other scenarios.

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 mark it non-read-only and non-idempotent; the description adds meaningful behavioral context beyond that by explaining suffix-driven routing variants (':online', ':nitro', ':floor', ':free'), web search, and how provider pinning affects determinism. It stops short of discussing billing or response-generation edge cases, but the disclosed routing/randomicity information 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?

Three purpose-driven sentences with no wasted filler: the first gives outcomes, the second explains routing suffixes, and the third supplies provider guidance. The most important usage constraints are front-loaded and every clause 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 7-parameter tool with nested provider routing and no output schema, the description covers the core outcome ('plain-text response') and the main routing behavior, while the schema covers max_tokens, timeout_ms, and reasoning_effort fully. It could be more complete about output structure or billing behavior, but given the schema's richness the tool is adequately documented for a competent agent.

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%, so the baseline is 3; the description clearly adds semantics above the schema by introducing model-slug suffix variants that map onto the 'model' parameter. This is extra knowledge an agent could not infer from the `model` field's 'Model slug' description, making the description do real work.

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 action ('Chat with a model'), a resource ('model'), and a concrete outcome ('plain-text response'), plus the intended use cases of testing prompts or comparing models. This clearly separates it from sibling tools like list-models 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?

It gives explicit direction on when to omit provider ('For normal chats, omit provider') versus when to set it ('only when you need zero variance, such as running evals'), plus routing-suffix options. It does not name sibling alternatives explicitly, but the context guidance is strong enough for an agent to decide when to call 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 indicate readOnly, idempotent, openWorld, and non-destructive behavior. The description adds useful context: the tool returns a recipe the agent must follow, includes installation and auth checks, requires relaying Ori's scoping questions to the user, and has a documented public URL. This clearly sets expectations beyond the annotation 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?

The description is moderately detailed but every section earns its place: first-sentence purpose, followed by when-to-use, when-not-to-use, and a parameter note. Key phrases like 'Call this tool FIRST' are front-loaded, and the no-arguments statement prevents extra lookups.

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 no-input, no-output-schema tool, this description fully explains what will happen, how to invoke it, what the agent must do after calling it, and where the upstream document lives. An agent can select and use this tool correctly without needing additional 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?

The tool has zero parameters, so there is no parameter burden. The description explicitly says 'Takes no arguments', which satisfies the baseline for a no-parameter tool and removes any doubt.

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: get and then follow instructions for running an Ori eval, rather than executing an eval directly. It also distinguishes itself from hand-rolling or re-running an existing eval, making its role unique among 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?

The description explicitly enumerates applicable use cases: model comparison, baking off models, measuring agent/prompt behavior, catching regressions, and assessing current model quality. It also gives exclusions — plain unit tests without a model and already-existing evals — and names the alternative command `ori eval <file>`.

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 cover read, idempotency, open-world, and destructive hints, but the description adds behavioral context by stating this bills the authenticated user and returns cost plus a generation id. It also clarifies server-side fetching and model discovery, all without contradicting 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 three short, information-dense sentences with no filler. It starts with a clear purpose, then moves directly to parameter constraints, billing, and model discovery.

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

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

With no output schema, the description still covers the return payload (transcript, cost, generation id). Combined with the annotations and complete parameter schema it gives an agent everything needed to know how to call the tool and what to expect in response.

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 covers rial parameters with descriptions for model, format, language, audio_url, and audio_base64 at 100% coverage. The description adds the useful 'exactly one' relationship and the preference for audio_url, but most parameter meaning is already structured in the schema, so the description adds limited additional semantic value.

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 verb 'Transcribe' and resource 'audio file to text' are explicit and immediately distinguish this from image/speech-generation siblings. It clearly states the main function but does not explicitly name a sibling to differentiate from, so it falls just short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives actionable input guidance: pass exactly one of audio_url or audio_base64, prefer audio_url, and use list-models with output_modalities=transcription to find STT models. It provides clear context and prerequisites, though it does not explicitly say when not to use this tool versus a sibling like generate-speech.

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