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

With annotations covering only the safety profile, the description carries substantial extra burden and delivers: it names the auth requirement (ASL_ROUTER_KEY), discloses billing and quota consequences of a live call, explains the sandbox escape hatch, and enumerates the response fields (model, provider, routing reason, latency).

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

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

Three dense sentences, front-loaded with the action and its return value before cost and auth caveats. Slightly long but each sentence adds distinct information (output, billing, sandbox, key), so little 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 7-parameter open-world execution tool with no output schema, the description covers the two things an agent most needs before calling: the auth prerequisite and the cost/mutation implications, plus the shape of the result. 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% and the mode enum is documented in exhaustive detail inside the schema, so the schema does the heavy lifting. The description only surfaces sandbox in prose, adding little beyond structured data; 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?

States a specific verb and resource ('send a prompt through the AI Stupid Level Smart Router and return the answer') plus the return payload, so the agent knows this is the execution tool. It is distinguishable from the get_* siblings, but it never names its closest sibling, preview_route, which is the natural confusion point.

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?

Offers real usage context: a live call is billed by the provider and counts against the router plan, while sandbox: true gives a free mock. However, it gives no explicit when-to-use-vs-alternative guidance, notably no 'use preview_route first to inspect the decision without spending' routing.

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 the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description goes further by disclosing what the payload actually contains: a per-model drift signature, a regime classification, per-benchmark-suite change-point detection, and axis-level attribution. With no output schema, this content disclosure is the main behavioral value-add; only return formatting/pagination is unmentioned.

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

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

Front-loaded with the purpose, then the returned fields, then the usage questions. The middle field list is dense and slightly enumerative — several items restate the same 'what changed' idea (change point, last significant change, axes moved) — but nothing is 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 with no output schema, enumerating the response contents is exactly the missing piece and it is supplied. Nothing an agent needs in order to call it correctly is absent; only edge cases (unknown model, insufficient data) are unaddressed.

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 the single 'model' parameter is fully documented in the schema, including its accepted forms (numeric id, name, display name) and a pointer to get_leaderboard. The description adds nothing parameter-level, so the baseline 3 applies.

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

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

The description names a specific verb+resource — measuring whether an LLM's measured performance has shifted — and enumerates the exact sub-signals returned (regime, score vs baseline, change-point detector, last significant change, moved axes). That level of detail lets an agent separate it from get_model and get_model_history without opening a 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 supplies concrete triggering questions ('has model X got worse?', 'is X being nerfed?'), which is strong positive guidance. It stops short of naming an alternative tool or stating when not to use it (e.g., versus get_model_history for raw history), so no exclusions 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 declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered elsewhere. The description usefully adds the temporal window (now + last 24 hours) and the output value semantics, but says nothing about freshness/caching, refresh cadence, or what threshold counts as 'performing well'.

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

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

Two sentences, both front-loaded with the payload description first and the routing hint second. Every clause carries information — the 0-100 scale, the two time horizons, trend, and model count — 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 no output schema and no parameters, the description is the only place return values can be conveyed, and it does state the core fields (index value, trend, healthy-model count). It is nearly complete, though it omits the exact response shape and any hint about refresh timing.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain; per the rubric this is the baseline 4. Nothing in the description contradicts or confuses the empty 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 concretely what the tool returns: a single 0-100 aggregate score for tracked models, both current and over the last 24 hours, plus trend and a count of well-performing models. This is specific enough to distinguish it from per-model tools like get_leaderboard, but it never names or explicitly contrasts a sibling, so it stops 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?

It gives a concrete triggering question — 'are AI models worse today?' — which tells the agent what class of user intent should route here. There are no exclusions (e.g., when to prefer get_drift_status or get_leaderboard instead), so it lacks the when-not guidance needed for a 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 declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds useful context about what is returned (severity, affected models, detection and resolution timestamps), but it does not disclose any additional behavioral traits such as rate limits, caching, or pagination beyond the limit parameter.

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, dense sentence that front-loads the resource and then lists the returned attributes. It is efficient with no wasted words, though the long list makes it slightly harder to scan than a more structured presentation.

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 listing tool with full schema coverage and helpful annotations, the description adequately explains what an incident record contains (severity, models, detection time, resolution status). It doesn't need to explain return values further, and the only minor gap is the absence of explicit sorting or pagination context beyond the schema's note that limit defaults to 10 newest-first.

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 fully documents the limit, provider, and open_only parameters. The description does not add any parameter-level meaning beyond what the schema provides, so the baseline score 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 states a specific resource (recent incidents) and enumerates the key fields: provider-wide degradations, model-level problems, severity, affected models, detection and resolution times. It clearly distinguishes this from general status or drift tools, though it doesn't 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?

No when-to-use, when-not-to-use, or alternative-routing guidance is provided. The description merely describes the payload, leaving the agent to infer that this tool is for viewing incidents rather than, say, provider status or drift.

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 establish readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds genuinely new context: the 0-100 score scale and the per-row contents (score, trend, status, stability, last updated), which matters 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?

Two sentences, front-loaded with the identity and scale of the resource before the use cases and row contents. Efficient, though the parenthetical vendor list is borderline redundant with the schema's vendor parameter.

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

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

With no output schema, the description usefully compensates by enumerating the fields each row contains. Purpose, usage and output shape are all covered; only cross-tool routing details and pagination-like behavior are absent, which is minor for a read-only listing tool.

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

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

Schema description coverage is 100%, so the schema already documents limit, period, vendor and sort_by thoroughly, including defaults and the paid-key requirement for 'latest'. The description echoes the ranking dimensions (coding, reasoning, tool use) but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

The description states a concrete resource (a ranking of tracked LLM APIs) and a concrete output (benchmark score 0-100), and it distinguishes itself from siblings by noting it supplies the model ids the other tools accept. An agent can tell this apart from get_model or get_recommendations without opening a 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 explicit usage contexts: finding the best model overall or for coding/reasoning/tool use, comparing models, and obtaining model ids for other tools. It does not name alternatives or state when not to use it, but the routing intent 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 the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is low, and the description clears it by disclosing a real behavioral quirk: the leaderboard row is present only 'when one has been fetched', i.e. conditionally populated. That is non-obvious and useful, though permissions and error behavior go unstated.

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

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

One sentence, front-loaded with purpose before the field inventory, and every listed field earns its place by telling the agent what it can rely on being returned. The enumeration is long 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?

With no output schema, the description carries the burden of describing the return shape and does so by enumerating the fields, including the conditional leaderboard row. Remaining gaps (resolution when a name is ambiguous, behavior for an untracked model) are minor for a single-parameter 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?

Schema description coverage is 100% and the schema already documents the single 'model' parameter including example names and the get_leaderboard pointer, so the description correctly adds nothing further. Baseline 3 when structured data 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 gives a specific verb (retrieves details) and a tightly scoped resource: one tracked LLM, with the exact fields returned enumerated. It does not name the nearest sibling, get_model_history, so an agent could still confuse a current snapshot with a history lookup.

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 explicit when-to-use or when-not-to-use statement, and no alternative is named (get_model_history is the obvious ambiguity). Usage is only implied via the practical pointer to get_leaderboard for locating a model's id.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered; the description goes further by disclosing the response composition (per-run scores plus per-axis breakdown for the newest run only). It does not mention the free-vs-paid key restrictions on 'latest', though that lives in the schema.

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

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

Two tight sentences: the first front-loads what is returned, the second front-loads the use case. No filler, no repetition of the title.

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 usefully carries the return-shape burden by naming the run-level scores and the per-axis breakdown. It stops short of describing ordering (newest first), listing limits, or how the summary relates to max_points, which the schema covers but the description could tie together.

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 every parameter (model, period, max_points) is already fully documented in the schema, including the 24h/latest key defaults. The description adds only the loose notion of a 'window', so the baseline 3 applies.

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

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

States a specific verb and resource — 'Score history of one LLM on AI Stupid Level' — and spells out what the payload contains (each run with its score, plus the newest run's per-axis results). It is unmistakably distinct from siblings like get_leaderboard or get_model.

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

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

'Use it to see whether a model got better or worse over time' gives intended usage, but there is no explicit when-not and no named alternative (e.g. use get_leaderboard to compare models rather than track one). Routing guidance is implied rather than stated, leaving the agent to infer the boundary with get_leaderboard/get_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 cover the safety profile (readOnly, idempotent, openWorld, non-destructive), so the description's job is to add context beyond that. It does: it discloses the data shape (operational or not, probe response time, last error, last-checked timestamp) and, importantly, that the view is probe-derived rather than authoritative. No rate limits or caching behavior is mentioned.

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 payload description is front-loaded, the provider list is relevant scope information, and the final sentence handles routing to the sibling tool.

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

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

With no parameters and no output schema, the description carries the return-value burden and does so: it enumerates the fields an agent will receive and clarifies the data source. Nothing needed to call or interpret 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?

The tool takes zero parameters, so per the rubric the baseline is 4. The description correctly adds no parameter semantics, since there are none to describe, and instead spends its words on return content.

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

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

States a specific verb+resource ('Current status of each LLM provider's API'), enumerates the covered providers, and names the perspective ('as AI Stupid Level's health probes see it'), which distinguishes it from get_incidents and get_drift_status without opening either 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?

Explicitly routes the adjacent case away ('For past outages use get_incidents'), giving a clear when-to-use-this-vs-that signal. It stops short of stating any exclusions or prerequisites for this tool itself (e.g., that it is a live snapshot, not historical), so it is not a full 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 declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description adds only that each pick carries its reason and evidence, which hints at response content but reveals nothing about freshness, caching, auth needs, or rate limits beyond what the schema states for 'latest'.

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

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

Two sentences, front-loaded with the list of pick categories, and the parenthetical glosses (e.g. 'most points per measured dollar among near-top models') earn their space by disambiguating the picks. The trailing question is slightly awkward but functional.

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

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

With no output schema, the description carries the burden of describing what comes back, and it does so well by listing the pick categories plus the attached reason and evidence. The only real gap is the absence of any pointer to or contrast with sibling tools for an agent choosing between this and get_leaderboard.

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% and the single 'period' enum is documented in detail there, including the free-vs-paid key defaults. The description says nothing about the period parameter, so it adds no meaning beyond the schema; baseline 3 applies.

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

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

The description enumerates exactly what the tool returns: coding pick, steadiest score, fastest, best value, overpriced models, and models to avoid, each with reason and evidence. That is far more specific than its siblings' surface (e.g. get_leaderboard), though it never states the verb explicitly, relying on 'current picks' and the trailing usage question to imply retrieval.

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?

'Use it for "which model should I use?"' gives a clear selection context that separates it from raw-data siblings like get_leaderboard or get_model. It offers no explicit exclusions or named alternatives, so an agent must infer that this is the curated layer rather than the underlying data.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds meaningful context beyond that: it reads only the *configured* router and data keys (no parameterization, uses ambient credentials) and surfaces limit/quota state, which explains its diagnostic role.

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

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

Front-loaded with the primary payload (Smart Router usage), then the secondary one (Data API requests), then a compact usage clause. The first sentence is dense with parenthetical enumerations but every element maps to returned data, so little 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?

With no output schema, the description carries the burden of describing returns and does so adequately by listing the usage fields. It stops short of describing the response shape or what happens when a configured key is missing or invalid, which matters given the stated 'check the keys work' use case.

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

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

Zero parameters, so the baseline of 4 applies. The description correctly implies the tool is parameterless by referring to 'the configured router key' and 'the configured data key' rather than any caller-supplied identifiers.

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

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

States a specific verb and resource (get usage/limits) and enumerates exactly what is returned: this month's Smart Router requests used and left, prepaid credits, the key's budget, and Data API requests left today. This clearly distinguishes it from siblings like get_provider_status, get_leaderboard, or get_incidents.

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

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

Gives two concrete trigger conditions: 'when a tool reports a limit' and 'to check the keys work.' That is clear when-to-use guidance, though it names no alternative tool or a when-not condition, and no sibling overlaps enough to require explicit routing.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description reinforces this by confirming no model is called and nothing is counted or billed. It also surfaces the auth requirement (ASL_ROUTER_KEY), which annotations cannot express. It doesn't elaborate on failure modes (e.g. missing key behavior) beyond the sandbox note.

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

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

Front-loads the outcome (which model and why) before the safety constraint and key requirement. The opening sentence is dense but every clause maps to a distinct return field; the two short follow-up sentences are pure value.

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

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

There is no output schema, so the description compensates by enumerating the returned decision details, and it covers the no-side-effect guarantee and the credential prerequisite. An agent has everything needed to call this correctly and interpret the result.

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

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

Schema description coverage is 100%, including a fully enumerated mode list, so the schema carries parameter meaning. The description adds no per-parameter syntax or defaults beyond what the schema already documents, so baseline 3 applies.

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

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

States a specific verb-scope (preview the routing decision) and enumerates the exact outputs: strategy, chosen model/provider with benchmark and estimated cost, and fallback chain. This clearly separates it from ask_router, which actually dispatches the prompt.

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?

"Nothing is sent to a model and nothing is counted" clearly frames it as the safe dry-run alternative to actually asking the router, and the router-key prerequisite is stated. It stops short of naming ask_router explicitly as the contrasting sibling, so the routing choice is implied rather than spelled out.

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