LLM Pricing

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

With no annotations, the description carries the full burden and largely succeeds: it discloses the edge case ('Returns has_data: false with no recommendation if the session_id has no recorded usage') and the side-effect profile ('Advisory only — never switches or reroutes anything'). It does not cover auth/permission needs or rate limits, keeping it short of a 5.

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 core purpose is front-loaded in the opening clause, and the parenthetical cross-references are informative rather than wasteful. It is dense for a single paragraph but every clause (data source, return shape, edge case, advisory nature) 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?

No output schema exists, and the description compensates by explaining the return payload (tokens, cost, per-model breakdown, recommendation, savings/increase) and the no-data case. For a moderately complex analysis tool this is close to complete, lacking only permissions and pagination/format details.

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

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

Schema description coverage is 100%, so both parameters are already documented, and the schema's session_id text ('previously used when calling record_usage') mirrors the description. The description adds only marginal framing ('tagged via record_usage's session_id'), so the 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+resource ('Analyze one specific session's actual recorded LLM usage') and enumerates exactly what it returns (input/output tokens, actual cost, per-model breakdown, and a grounded recommendation). It clearly distinguishes itself from siblings by naming record_usage (the data source), recommend_model (the shared engine), and get_usage_summary's org_id semantics.

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?

Establishes clear context — 'on demand' analysis of a session previously tagged via record_usage's session_id, with a cross-reference to recommend_model for the routing logic. However it stops short of explicit when-to-use/when-not-to-use rules or exclusions versus siblings like get_usage_summary.

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

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

No annotations are provided, so the description carries the full behavioral burden, but it does not disclose whether the agent is read-only, whether autonomous mode performs actions, how conversation state persists, or what cost/latency to expect. It only states that the tool benefits from multi-step reasoning, leaving key behavioral traits undocumented.

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

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

The description is two sentences, front-loaded with the core action and followed by usage guidance. There is no redundant or wasted text.

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?

It adequately covers purpose and typical use cases for a three-parameter agent-routing tool. However, with no annotations and no output schema, it should provide more detail about autonomous mode behavior, conversation continuation, and the nature of the 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?

Schema description coverage is 100%, so the schema already documents message, autonomous, and conversation_id. The description adds some context for the main message parameter by framing it as natural-language complex queries, but it does not explain autonomous mode or conversation continuation beyond what the schema says.

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

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

The description uses a specific verb and resource: asking the LLM Pricing AI agent a question in natural language. It implicitly distinguishes itself from direct pricing tools by saying it is for complex, multi-step queries, though it does not name sibling tools explicitly.

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

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

It gives clear usage conditions: complex pricing queries, model recommendations, cost optimisation advice, and multi-step reasoning. It lacks explicit exclusions or named alternatives, so an agent must infer that simpler direct tools should be used otherwise.

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

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

With no annotations, the description carries the full burden and does so well: it discloses that prices are hand-maintained, go stale silently, are automatically withheld from serving on threshold breach, and that the registry never overwrites the price value. Missing only return-shape and permission details, which is a modest gap.

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

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

Four tight sentences, front-loaded with what the tool does, then the behavioral caveats, then the usage trigger. No filler and nothing repeated from the schema.

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

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

For a read-only audit tool with no annotations and no output schema, the description covers purpose, mechanism, side effects and usage triggers. It stops short of describing the shape of the returned findings, which an agent would have to discover at call time.

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 adds genuine meaning by tying the threshold to the withholding mechanism ('a price that disagrees with the registry by more than the threshold'), clarifying intent beyond the schema's 'minimum % difference to report'.

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: auditing this server's own pricing data against an external reference registry. An agent can immediately distinguish it from siblings like get_all_pricing or get_data_quality, which just read data rather than compare it against an external source.

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 explicit trigger conditions: 'Use when the user asks whether the pricing data is accurate or up to date, or wants to audit a specific provider's rates.' It does not name a competing sibling tool to redirect to, but the context is clear enough to select 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?

With no annotations, the description carries the full behavioral burden but says nothing about pricing source or freshness, behavior for unknown model names, or whether the comparison is computed on a single token workload. For a mutation-free but analysis-heavy tool, the agent learns only the bare 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?

A single compact sentence with the operation front-loaded and zero filler. It is efficient, but the brevity comes at the cost of content rather than trimming 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?

There is no output schema and no annotations, so the description should explain the return shape (e.g., per-model cost comparison) and any error behavior for invalid models. Instead it leaves an agent unable to anticipate the result 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 description coverage is 100%, so all three parameters (model_names, input_tokens, output_tokens) are already documented in the schema. The description adds no extra meaning such as whether model names must match a known pricing catalog or whether token counts are per-model or shared.

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 (compare) and resource (costs for multiple LLM models), and the plural 'multiple models' signals the batch nature of the operation. It does not, however, distinguish itself from close siblings like estimate_cost, predict_cost, or get_all_pricing, so an agent must infer the boundary.

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

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

There is no guidance on when to use this instead of estimate_cost (single-model cost), predict_cost (forecasting), or get_all_pricing (raw price listing). The description provides no prerequisites, no exclusions, and no routing cues among a crowded set of cost/pricing siblings.

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

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

With no annotations, the description carries the full burden for a destructive operation. It never says whether deletion is permanent, what happens if the ID does not exist, whether confirmation or special permissions are needed, or what is returned.

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?

A single front-loaded sentence that names the action and the selector with zero 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 one-parameter tool this is close to adequate, but a destructive tool with no annotations and no output schema should at least note irreversibility and error behavior on an invalid or already-deleted ID.

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?

Only one parameter and the schema documents it fully at 100% coverage, including provenance (list_budget_alerts or register_budget_alert). The description merely restates 'by its ID' and adds nothing beyond the schema, so the baseline of 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 (delete), a specific resource (budget-spend alert), and the selector (ID). It implicitly distinguishes itself from delete_price_alert and delete_conversation by naming the resource, though it never explicitly routes against those siblings.

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

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

No explicit when-to-use or when-not guidance, but usage is clearly implied and the schema points to list_budget_alerts and register_budget_alert as ID sources, which is real context for locating the target.

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

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

No annotations are provided, so the description carries the full behavioral burden. For a destructive mutation it omits whether deletion is permanent/irreversible, whether confirmation is required, what permissions are needed, and what happens to related data — none of which can be inferred from 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?

Three short sentences, action front-loaded, with the trigger phrasing and prerequisite following in order of agent need. 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 one-parameter delete with no output schema and no annotations, the description covers purpose, trigger, and ID sourcing adequately. The notable gap is the destructive/irreversibility profile, which an agent would want before calling a delete 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?

Single parameter with 100% schema description coverage ('The ID of the conversation to delete'), so the schema already does the work. The description only restates that the delete is keyed by ID and adds no format or sourcing detail beyond 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?

States a specific verb (delete) and resource (chat conversation), and scopes it by ID. It also references the sibling list_conversations, so an agent can distinguish this from list/read tools without opening schemas.

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 names the trigger conditions ('delete, clear, or remove a past conversation') and prescribes a prerequisite step ('Use list_conversations first to find the conversation ID'). It does not state any when-not condition or what to do if the ID is unknown/invalid, so it falls just short of 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?

With no annotations, the description carries the full behavioral burden. It says an alert is deleted but never states that the deletion is permanent/irreversible, whether the alert must exist, or whether any permission is required — key facts for a destructive 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?

A single short sentence with the action and target front-loaded and no filler. Nothing could be trimmed without losing meaning.

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 one-parameter tool with a fully documented schema and no output schema, the description is minimally sufficient. However, an irreversible delete with zero annotation coverage would benefit from a caution or return-behavior note, leaving a noticeable gap.

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

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

Schema description coverage is 100% and the schema already documents alert_id and its source tools, so the baseline of 3 applies. The description's 'by its ID' adds no meaning beyond 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?

States a specific verb (Delete) and resource (registered price-change alert) plus the lookup key (ID), which implicitly separates it from the sibling delete_budget_alert. It is clear but makes no explicit sibling differentiation or scope statement.

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 prerequisite guidance is given. The only hint about where the ID comes from lives in the schema property description, not the tool description, so the agent gets no usage routing from this text.

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

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

No annotations are provided, so the description carries the full burden. It implies a pure read/computation with no side effects but never says so, and it discloses nothing about the pricing source, currency, whether the result is a total or a breakdown, or how caching or tiered pricing is handled.

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?

A single front-loaded sentence with no wasted words. It is efficient, though its brevity edges toward under-specification rather than true conciseness.

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 annotations and no output schema, the description should explain what comes back (a dollar figure, a breakdown per token type, currency) and how it relates to predict_cost/compare_costs. For a three-parameter computation tool, this leaves an agent under-informed.

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 all three parameters (model_name, input_tokens, output_tokens) are already documented with examples and minimums. The description adds no format or unit details beyond that, making the baseline 3 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 ('Estimate') and resource ('cost of using a specific LLM model'), so the agent knows exactly what the tool computes. It does not, however, distinguish itself from close siblings like predict_cost, compare_costs, or get_all_pricing, leaving the agent to guess which cost tool applies.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives. With siblings such as predict_cost and compare_costs in the same namespace, the absence of routing guidance is a real gap.

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

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

No annotations are provided, so the description carries the full burden, and it discloses only the breadth and currentness of the result. Nothing is said about response size, caching/freshness guarantees, auth requirements, or whether the whole catalog is always returned unmodified.

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?

A single front-loaded sentence with no filler or repetition. It is efficient, though it spends no words on scoping or differentiation that would help selection.

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-argument read tool with no output schema, the description is adequate to invoke the tool but does not describe the shape of the returned pricing data (model identifiers, per-token vs per-unit costs, currency). Given the crowded pricing sibling set, slightly more scoping would make this 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 tool takes zero parameters, so the baseline is 4. The description adds nothing about parameterization, but there is nothing to parameterize, and it correctly implies no filtering inputs 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?

States a specific verb and resource ('Get current pricing') with explicit scope: all LLM models, all providers. It does not differentiate itself from close siblings like get_pricing_history, get_pricing_trends, or get_ide_pricing, though 'current' hints at the boundary against historical tools.

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 guidance and no mention of alternatives. The description implies this is the unfiltered, comprehensive option versus the many scoped pricing siblings, but nothing states when an agent should pick this over get_ide_pricing or estimate_cost.

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

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

With no annotations, the description carries the full burden and does: it discloses that counts reset on process restart, that reading is non-mutating ('reading them never changes them'), and that the two series are never merged — all behavior an agent could not infer from the empty 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?

Front-loaded with what is reported before scope and caveats, and every clause adds information (separation rule, restart behavior, read-only nature). The single dense block is slightly long, but no sentence 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?

No output schema exists, and the description supplies the return shape (hit/miss counts, total lookups, hit rate, per-tool breakdown), so an agent knows what it will get without needing a schema.

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

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

Zero parameters, so the baseline is 4; there is nothing for the description to clarify, and it does not fabricate 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?

States a specific verb and resource ('Report ... hit/miss counts, total lookups, and hit rate') plus the exact scope (the ~5-minute recommendation cache) and the split granularity (recommend_model vs POST /router/recommend, never combined). An agent can distinguish it cleanly from pricing and telemetry 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?

Explicitly frames the use case ('confirming the cache is reducing recomputation in production') and excludes a whole class of alternatives ('not a pricing question'), which steers agents away from compare_costs/estimate_cost. It stops short of naming specific alternative tools for other cache/inspection needs, so it is clear context rather than a full when/when-not map.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose that this is a read-only aggregate trust signal whose output is counts and percentages rather than a list. It also discloses the drift-withholding and 90-day freshness semantics, which are behavioral, not just structural. It stops short of stating permissions or any rate/scope caveats, so it is strong but not exhaustive.

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 plus a routing sentence, all front-loaded: the metric enumeration comes first, then the sibling differentiation, then the usage trigger. The enumeration is dense but every clause maps to a distinct returned metric, so nothing is padding given the absence of an output schema.

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

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

No output schema exists, so the description must convey the return content, and it does so by naming all four aggregate figures. With zero parameters and no synchronization or mutation concerns, there is nothing an agent needs in order to call this correctly that 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 the baseline is 4. The description correctly implies a whole-catalogue, unfiltered scope rather than adding parameter detail that does 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?

States a specific verb (report) and resource (aggregate accuracy summary for the pricing catalogue) and enumerates the exact metrics produced: percent with fresh confirmed price, count withheld for drift, count newly discovered/unpriced, count of confirmed prices older than 90 days. It explicitly distinguishes itself from the sibling check_price_drift, so an agent can route between them 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?

Gives an explicit when-to-use trigger ("Use when the user asks how accurate or trustworthy the pricing data is, overall") and names the alternative tool, check_price_drift, with the condition that separates them (aggregate vs. individual disputes). No inference is required.

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

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

No annotations are provided, so the description carries the full burden. It discloses the return payload (monthly cost, inline completion support, context window, strengths), which is genuinely useful given there is no output schema, and 'Get' implies a safe read. It does not, however, explicitly state read-only behavior, data freshness/caching, or any auth requirements.

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

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

Two sentences, front-loaded with scope and coverage, then the usage trigger. The provider enumeration is dense but earns its place by making the tool's coverage boundary explicit.

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, zero-required-parameter lookup with a fully documented schema, the description supplies the scope, coverage and return fields an agent needs; there is no output schema to compensate for. The only shortfall is the absence of sibling routing and explicit read-only/freshness disclosure.

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 provider, inline_only and max_monthly are already fully documented with examples and defaults. The description adds no filter semantics 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?

States a specific verb and resource ('Get subscription pricing for AI coding IDE tools') and enumerates the exact providers covered, which cleanly separates it from siblings like get_all_pricing and compare_costs. An agent can tell what this returns without opening the schema.

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

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

The description gives a clear when-to-use clause: comparing IDE AI tools, subscription-based coding assistants, or budget fit. However, it never names the alternative sibling tools (e.g. compare_costs, get_all_pricing, check_price_drift) or states when NOT to use it, so routing between the pricing siblings is left partly to inference.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read but never states read-only behavior, rate limits, auth requirements, or whether results are scoped to configured providers. Given the crowded sibling set of read tools, this is a significant disclosure gap.

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?

A single front-loaded sentence with the verb, resource, and returned metric types; 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?

With no output schema and no annotations, an agent would benefit from knowing the response shape or which model set is covered by default. The description is minimally viable for a simple optional-filter read tool but leaves the agent to infer the defaults.

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 both optional parameters (provider, include_cost) are already documented in the schema with examples and defaults. The description adds no syntax or behavioral 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?

States a specific verb (Get) and resource (performance metrics) and enumerates the metric types returned (throughput, latency, context window), so the agent knows exactly what data comes back. It does not, however, distinguish itself from siblings like get_telemetry or get_usage_summary, which could plausibly return overlapping data.

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

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

There is no guidance on when to use this tool versus the many sibling metric/telemetry/pricing tools. No prerequisites, no exclusions, and no mention of the optional provider filter's effect on the result.

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

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

With no annotations, the description carries the full behavioral burden and does disclose the key non-obvious trait: the tool returns a URL the user opens in a browser rather than the data itself, and that output is CSV or JSON. It omits secondary traits such as URL expiry or permission requirements, keeping it short of a 5.

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

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

Two sentences, no waste, and the core behavior (URL generation) is front-loaded before the usage condition. Every sentence earns its place.

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

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

Despite no output schema, the description explains what is returned (an openable download URL in CSV or JSON), and the filter/limit parameters are fully covered in the schema. It is nearly complete; only edge-case behavior like URL lifetime is 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?

Schema description coverage is 100%, so defaults, ranges, and the format enum are already documented. The description only adds framing for format ('CSV for spreadsheets, JSON for code'), which is a marginal value-over-schema contribution, matching the baseline 3.

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: 'Generate a download URL for the pricing history export.' This clearly distinguishes it from the sibling get_pricing_history, which returns data rather than a downloadable artifact, so an agent can pick correctly without opening schemas.

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 this when the user asks to export, download, or save pricing data' gives an explicit triggering condition. It stops short of naming alternatives (e.g., when to use get_pricing_history instead of exporting), so it is clear context without exclusions.

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

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

No annotations are provided, so the description carries the full burden. It conveys that this is a read-only lookup of recorded data, but says nothing about result volume behavior (limit/max 500), whether older snapshots may be missing, or auth needs. Adequate but not rich.

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

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

Two sentences, purpose first then usage, no filler. 'Recorded over time' is mildly redundant with 'historical', keeping it just below perfect.

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 query tool with no output schema, no required parameters and fully documented properties, the description covers what the tool returns at a conceptual level and when to reach for it. Only return-shape and pagination cues are absent.

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

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

Schema description coverage is 100%, with defaults, min/max and example values for every parameter, so the baseline is 3. The description only loosely gestures at the days window and provider/model filtering without adding format or combination semantics.

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: query historical pricing snapshots. The word 'historical' and 'recorded over time' implicitly separate it from siblings like get_all_pricing (current prices) or check_price_drift, though no sibling is named explicitly.

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 clear usage contexts: look up past prices for a model or provider, or see price changes over a number of days. Missing explicit when-not guidance or a named alternative (e.g. get_pricing_trends for trend analysis), so it stops short of 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?

Without annotations, the description carries the full burden. It discloses the return format (sorted by absolute percentage change with direction labels), which is useful. However, it omits other behavioral details such as permissions, rate limits, or whether the data is live or cached, leaving some gaps.

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: purpose, return format, and usage examples. It is front-loaded with the core function and every sentence earns its place by adding distinct value for an agent.

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 query tool with rich schema documentation and no output schema, the description covers purpose, return format, and usage. It lacks only minor details like default values (already in schema) or read-only nature, but it is largely 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?

Schema description coverage is 100%, so the schema already fully documents both parameters. The description only indirectly references the 'given period' (mapping to the 'days' parameter) and adds no new parameter semantics, making the baseline 3 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 verb ('Find') and resource ('models whose prices changed the most') and clarifies the output ordering. However, it does not explicitly differentiate from sibling tools like check_price_drift or get_pricing_history, leaving the agent to infer that this tool focuses on ranking by absolute change over a period.

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 provides clear usage context with example questions ('which models got cheaper this month?'), which effectively signals when to use the tool. It does not offer explicit when-not-to-use guidance or name alternatives, so it falls short of 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?

No annotations are provided, so the description carries the full burden. The naming and verb strongly imply a read-only stats fetch, and enumerating the tracked dimensions (tool usage, response times, error rates) adds real context, but there is no disclosure of scope, auth requirements, or whether the data is live vs. aggregated. Adequate but thin for a tool with zero annotation coverage.

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?

A single sentence, front-loaded with the verb and resource followed by the content areas. No filler, no repetition of the title or schema.

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

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

With no output schema, the description partly compensates by naming the statistic categories returned, and both parameters are fully specified in the schema. It stops short of describing the shape or grouping of results (the 'per category' limit suggests aggregation the description never explains), which is a minor remaining gap.

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

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

Schema description coverage is 100%: both 'limit' (default/max) and 'include_details' are fully documented in the schema, and the description adds nothing about either. The baseline of 3 is appropriate when the schema does all the 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?

States a specific verb ('Get') and resource ('MCP server telemetry and usage statistics') and enumerates the three content areas covered (tool usage, response times, error rates). However, it offers no differentiation from close siblings such as get_performance_metrics, get_cache_stats, or get_usage_summary, so an agent cannot tell from the description which telemetry source to pick.

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 contains no when-to-use statement, no prerequisites, and no named alternatives. With siblings like get_performance_metrics and get_usage_summary in the same family, the absence of any routing guidance leaves selection entirely to inference from the name.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the data source (previously logged usage events via record_usage), implying it returns only recorded spend and not live provider billing, but it says nothing about permissions, empty-state behavior when nothing has been logged, or aggregation semantics for the look-back window.

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 first states what is returned and its provenance, the second states the usage condition. The purpose is front-loaded before the when-to-use clause.

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 correctly compensates by naming the return contents (total cost, request count, model and provider breakdowns). With only two fully documented optional parameters and no mutation involved, this is nearly complete; the only gap is scope behavior for the days window and org filtering.

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% with both parameters (days, org_id) fully described including default and max, so the schema already does the heavy lifting. The description adds no syntax or scoping detail beyond mentioning model/provider breakdowns, which are not themselves parameters. 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+resource (get a summary of recorded LLM spend) and enumerates the returned dimensions: total cost, request count, and breakdowns by model and provider. It also names the upstream sibling record_usage as the data source, so an agent can tell exactly what population this reads from.

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 an explicit selection rule: 'Use when the user asks what they've actually spent, as opposed to a hypothetical cost estimate.' This cleanly separates it from estimate_cost/predict_cost in the sibling list. It stops short of naming the alternative tool or stating exclusions (e.g. session-scoped usage), so it is clear context rather than a full routing table.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It never states that this is a read-only lookup, whether results are scoped per model or aggregated, or how the provider filter affects output, so an agent learns very little beyond the one-line purpose.

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?

A single front-loaded sentence with no filler. The purpose is stated immediately and 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 discovery tool with no annotations and no output schema, the description should at least sketch the return shape (e.g., per-model strengths) and the effect of the provider filter. It does neither, leaving the agent under-informed about its output.

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 there is only one optional param, so the schema already documents the provider filter; the baseline of 3 applies. The description notably fails to mention the provider parameter at all, adding no meaning on top of 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?

States a clear verb+resource: fetching use cases and strengths for LLM models. However, it does not differentiate from nearby siblings such as recommend_model or get_performance_metrics, so an agent cannot tell from the description alone which sibling to pick.

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

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

There is no when-to-use guidance, no exclusions, and no mention of the closest alternative (recommend_model). The optional provider filter's purpose is left implicit rather than explained as a selection aid.

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

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

No annotations are provided, so the description carries the full behavioral burden and does so: server-side-only cost computation ('never trusted from the caller'), per-entry failure isolation that does not fail the batch, and detailed idempotency semantics including the derived key when request_id is omitted. These are exactly the traits an agent needs and cannot get from structured fields.

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 key routing constraint is front-loaded and every sentence carries information, but the passage is long and a couple of clauses (the read-back endpoints, batch-cap detail) could be trimmed without loss. Dense rather than padded, so a 4 rather than a 5.

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 naming exactly where the imported data becomes readable ('analyze_session_usage and GET /usage/session/{session_id}'). Idempotency, failure mode, token resolution, and cost provenance are all covered for a mutation-shaped, unannotated 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 baseline is 3; the description adds genuine semantic value by explaining how the two token fields interact with the two text fields (exact counts vs. estimation via the server's counter) and the shared session_id tagging of every entry. It stops short of enumerating every field, but the schema already covers those.

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 ('Bulk-import a completed session's usage in a single call') and immediately positions itself relative to a sibling ('the retroactive counterpart to record_usage'). An agent can distinguish it from record_usage without opening any 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?

Gives an explicit when-to-use scenario ('when a calling agent ... already has a session's turn-by-turn history in its own local store') and names the alternative it complements (record_usage, with analyze_session_usage as the read path). Nothing is left to inference about when this tool applies versus live recording.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'List' implies a read-only operation and it hints that IDs and settings are returned, but it says nothing about pagination, result limits, whether disabled or webhook-less alerts are included, or any auth requirement. For a zero-annotation tool this is a real gap.

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?

A single front-loaded sentence with no filler; the verb and resource come first and the return content follows. It is efficient, though it is so terse that it omits information the agent would benefit from.

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, no annotations, and no parameters, the description is almost the only source of information, and it covers purpose plus a partial view of the return payload. It omits pagination/result-shape behavior and does not disambiguate from the price-alert list tool, leaving it adequate but thin for the surrounding toolset.

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 document and the baseline of 4 applies. Nothing in the schema or description is missing on this dimension.

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 (list) and a precisely scoped resource (budget-spend webhook alerts), and even previews the payload ('IDs and settings'). The 'budget-spend' qualifier implicitly separates it from list_price_alerts, but it never names that sibling, so the agent must infer the distinction from the name alone.

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

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

There is no when-to-use guidance, no stated conditions, and no mention of the closely related siblings (list_price_alerts, register_budget_alert, delete_budget_alert). The listing intent is inferable from the verb, but nothing tells the agent when this is the right call versus the price-alert equivalent.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the returned fields, implying a safe read operation, but says nothing about sort order, pagination behavior beyond the limit cap, or whether any auth is required. Adequate but with real gaps.

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 gives the usage trigger. No filler, no repetition of the schema.

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

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

A simple read-only listing tool with one fully documented optional parameter, and the description explains the result shape in the absence of an output schema. Ordering/pagination behavior is the only notable omission, which is minor for this complexity.

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

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

Schema description coverage is 100% and the single 'limit' parameter is fully documented in the schema with default and min/max. The description adds no parameter-level detail, 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 (List) and resource (chat conversation sessions), and enumerates what each entry contains (IDs, timestamp, turn count, message preview). It is clearly distinguishable from delete_conversation in practice, but it never names a sibling or explicitly delimits its scope against them.

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 an explicit trigger condition: 'Use this when the user asks to see their past conversations or chat history.' That is clear usage context, but there are no exclusions or pointers to related tools (e.g., delete_conversation for cleanup), so it stops short of full when/when-not guidance.

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

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

With no annotations, the description carries the full burden. It usefully discloses that the alerts are webhook-based and that output includes IDs and settings, but says nothing about auth requirements, pagination, ordering, or whether inactive alerts are included. The read-only nature is only implied by the verb 'List'.

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?

A single front-loaded sentence with no filler; the verb and resource lead, and the return content trails as supporting detail.

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

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

For a zero-parameter, no-output-schema list tool, the description covers the entity and the returned fields, which is nearly everything an agent needs. Minor gaps remain around pagination or scope (e.g., whether disabled alerts appear).

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 nothing for the description to clarify; the baseline of 4 applies. The description correctly implies no filtering arguments are needed since it returns all registered alerts.

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 (List) and resource (registered price-change webhook alerts) plus what is returned (IDs and settings). The resource is clearly distinct from siblings like list_budget_alerts, though the description never names or contrasts those siblings explicitly.

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

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

No guidance on when to use this versus list_budget_alerts, register_price_alert, delete_price_alert, or check_price_drift. The agent must infer the use case purely from the resource name.

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

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

No annotations are provided, so the description carries the full burden, and it does substantial work: it discloses the optimiser's strategy (cheapest qualifying model per task), the budget heuristic (leftover headroom spent on cost-efficient quality upgrades), and that vision/function-calling requirements gate model selection. It does not state whether the result is deterministic or how ties/constraints are handled, but for a read-only computation tool this is solid coverage.

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 core purpose, then inputs, then return values, then usage. Four sentences with no filler, and each one adds a distinct piece of information rather than 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?

There is no output schema, so the description must explain what comes back, and it does: per-task model allocation, total monthly cost, and savings versus the best single-model deployment. Combined with the input description and budget behaviour, an agent has everything needed to call it 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%, so the schema already documents every parameter, and the description's summary of inputs ('task type + monthly volume + optional quality floor and capability requirements') mostly restates it. The budget-headroom behaviour it mentions is also already written into the monthly_budget_usd schema description, so the value added beyond structured fields is limited; baseline 3.

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 (optimise) and resource (multi-task LLM workload) plus the actual mechanism: assigning the cheapest qualifying model per task rather than one model for everything. This distinguishes it from siblings like recommend_model (single model) and estimate_cost/predict_cost (cost estimation), so an agent can route correctly without opening the schema.

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

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

Explicitly names the trigger conditions: cutting LLM spend across several task types, or evaluating whether tiered routing is worth it. The 'several task types' framing implicitly excludes single-task cases, but it never names an alternative tool (e.g. recommend_model) for those cases, so the exclusion is left to inference.

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

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

With no annotations, the description carries the full burden and does well: it discloses the computation model (tokens counted locally, task type inferred or explicit, output length from empirical I/O profiles) and the shape of the result (models ranked cheapest-first, effective cost after prompt-cache savings, best quality-per-dollar pick). It does not state permissions, rate limits, or failure behavior, but for a local estimation tool those are low-stakes.

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 core verb and resource, then the mechanism, then the return shape, then the usage cue. The sentences are information-dense with little padding, though the enumeration of internal steps is slightly longer than strictly necessary.

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?

No output schema exists, and the description compensates by describing the return structure (ranked model list, effective cost, quality-per-dollar pick). For a seven-parameter read-only estimation tool with no annotations, this covers what an agent needs to invoke it correctly.

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

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

Schema description coverage is 100%, so all seven parameters are already documented, including the task_type enum and the cache_hit_ratio semantics. The description reinforces the cache-savings and task-inference behavior 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?

States a specific verb and resource: predict the real cost of an LLM call from prompt text, and enumerates the internal steps (local token counting, task-type inference, output-length estimation, cheapest-first ranking). The purpose is unambiguous. It does not, however, differentiate itself from the sibling estimate_cost, which an agent may reasonably confuse it 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?

Gives a clear usage context: 'Use this before making any LLM API call to avoid surprise bills.' That is a concrete when-to-use. It offers no when-not guidance and never names the alternative siblings (estimate_cost, compare_costs, recommend_model), so selection between closely related cost tools is left to inference.

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

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

No annotations exist, so the description carries the full burden, and it discloses a lot: read-only, the internal classify-then-route pipeline, live pricing plus benchmark quality, hard filters, quality-per-dollar scoring, and the return shape (best match + up to 3 alternatives). It lacks auth, rate-limit, or failure-mode detail, keeping it short of a 5 for a no-annotation tool.

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 core purpose and benefit, then behavior, then routing to siblings. It is a dense single paragraph and slightly long, but essentially every clause carries distinct information; no filler sentences.

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 13 parameters, the description steps in to describe the return value (best match plus alternatives) and the decision pipeline. Combined with 100% schema coverage, an agent has everything needed to call it correctly.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds genuine meaning: it explains that task_type is an optional explicit override of the auto-classification, and ties the hard-filter params (cost/quality/context window) to the routing behavior. That exceeds what the schema alone conveys.

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 (recommend) and resource (LLM model) and immediately scopes it: from a free-text use-case description, without needing the task_type vocabulary. It is cleanly distinguishable from predict_cost and optimize_workload, which it names.

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: 'use predict_cost first if you also want per-model cost estimates for an actual prompt, and optimize_workload if you have several distinct task types to route at once.' The conditions selecting each alternative are stated, not implied.

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

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

With no annotations, the description usefully discloses that cost is computed server-side and never trusted from the caller, plus that resubmitting the same request_id is a no-op — non-obvious behavioral traits. It omits auth requirements and whether a mutation like this is reversible or returns the computed cost, leaving a gap.

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 core action and dense with useful detail across four sentences. Minor redundancy ('not just estimate it' echoes the earlier estimate_cost contrast), but 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?

Given seven parameters with no annotations and no output schema, the description covers the important behavior (server-side cost, idempotency, org scoping). The return value — presumably the recorded usage with computed cost — is not described, which is the main remaining gap.

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

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

Schema coverage is 100%, so the schema already documents all seven parameters including org_id scoping and request_id idempotency. The description's mention of org_id scoping largely restates the schema, 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 and resource ('Record actual token usage for a completed LLM call') and explicitly positions itself as the 'actual spend' counterpart to estimate_cost, distinguishing it from a sibling tool by name.

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

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

Explicitly states when to use it ('when the user wants to log or track real LLM spend, not just estimate it') and names the alternative (estimate_cost) with the condition that selects 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?

With no annotations, the description carries the burden well: it discloses the firing semantics (at most once per period_days while spend stays over threshold), the webhook POST delivery, and the return value. It omits auth/permission requirements and webhook failure/retry behavior, which an agent configuring an endpoint would benefit from knowing.

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 that front-load the core action and trigger, then scoping, then firing cadence, then return value. No filler or restatement of the name.

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?

No output schema, but the description supplies the return value (alert ID) and the key operational semantics. Combined with 100% schema coverage, an agent has enough to invoke it correctly; only auth/prerequisite context and webhook failure handling are 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%, so the baseline is 3. The description reinforces the semantics of org_id (omit for total) and the threshold/period interaction, but adds little that the schema's own parameter descriptions do not already state.

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 ("Register a webhook URL to receive notifications") plus the exact trigger condition — recorded spend from record_usage crossing a USD threshold in a rolling window. This is clearly distinguishable from register_price_alert, list_budget_alerts, and delete_budget_alert by naming the data source and alert type.

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 clear selection context: use org_id to scope to one organisation, omit it to monitor total spend, and the alert fires at most once per period_days. It doesn't explicitly name sibling alternatives (register_price_alert for price drift, list_budget_alerts for review), so the routing guidance stops short of full when-not coverage.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose meaningful traits: the alert fires a POST to the given URL, the threshold is an absolute percentage change (default 5), scoping is optional, and it returns an alert ID. It omits auth/permission requirements, webhook retry or failure behavior, whether registration is idempotent, and the alert's lifecycle (removed via delete_price_alert), which matter for a mutation that triggers external callbacks.

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 tight sentences, zero filler, with the core action and trigger condition front-loaded before the optional scoping. The final sentence about the alert ID is short but earns its place only because no output schema exists. It could drop the redundant repetition of 'notifications' detail but is broadly efficient.

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

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

No output schema exists, and the description compensates by stating the return value (alert ID). For a simple registration tool it covers the trigger condition, optional filtering, and result. The remaining gaps (auth needs, alert lifecycle, failure handling) are real but modest given the tool's simplicity and the absence of a nested schema.

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

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

Schema description coverage is 100%, so all four parameters are already documented in the schema, including the default threshold and the 'omit for all' scoping semantics. The description restates the scoping and threshold behavior without adding syntax, ranges, or format detail beyond what the schema provides, so the baseline of 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 gives a specific verb (register) plus resource (price alert) and states the trigger semantics precisely: a webhook URL notified when a model's price moves beyond a percentage threshold, with optional provider/model scoping. This clearly separates it from delete_price_alert and list_price_alerts, though it never explicitly names the analogous sibling register_budget_alert to disambiguate the 'price vs budget' distinction.

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?

Usage is implied — you call this when you want push notifications on price changes — but there is no explicit when-to-use statement, no exclusions, and no pointer to the sibling tools for listing or removing existing alerts. An agent can infer the context but is not routed to alternatives.

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