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 does so: it declares the tool advisory-only and that it 'never switches or reroutes anything', spells out authentication requirements (x-api-key or Bearer on the MCP connection) and the org_id matching constraint. It also discloses the empty-result behavior and how the recommendation is derived (same engine as POST /router/recommend).

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 dense paragraph that is front-loaded with the core purpose and output shape, followed by the recommendation mechanics and then the safety/auth caveats. Every clause adds information, though the length pushes the auth and advisory notes far from the opening.

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 describe returns — and it does precisely: token totals, actual cost, per-model breakdown conditional on multiple models, recommendation with dollar delta, and has_data: false. Auth prerequisites and the advisory-only guarantee round out what an agent needs 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 both parameters are already documented in the schema, and the description largely restates those same semantics (session_id from record_usage, org_id defaulting to and matching the key's org). Baseline 3 applies since the schema does the heavy lifting.

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

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

States a specific verb and resource — analyze one session's recorded LLM usage — and enumerates the concrete outputs (input/output tokens, actual cost, per-model breakdown, routing recommendation with estimated savings). It distinguishes itself from siblings by tying session_id to record_usage and naming the shared routing engine behind recommend_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?

Usage context is clear: use it 'on demand' for a single session that was tagged via record_usage's session_id, and it produces either a recommendation or a confirmation the current choice is optimal. It also states the negative case (has_data: false when no usage recorded), but never explicitly says when to prefer recommend_model or get_usage_summary instead.

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 burden and does add real behavioral context: every named model is priced regardless of client, and client only annotates rather than filters. This usefully corrects the misleading 'only models it can run are considered' phrasing in the schema. It still omits return shape and currency-conversion behavior.

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 front-loaded purpose and the client semantics are efficient, but the third sentence enumerates all 15 recognised clients, duplicating the schema enum verbatim and bloating the description without adding information. Roughly a third of the text is redundant.

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 6-parameter tool with no output schema and no annotations, the description covers only model_names and client. It says nothing about what the comparison returns (per-model cost breakdowns, currency conversion via country/currency, fallback flags), leaving the agent to infer 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 coverage is 100%, so baseline is 3, but the description adds the crucial nuance that client never filters results — the opposite of what the schema text implies — which materially changes how an agent interprets the output. Country/currency parameters are left entirely to the schema.

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

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

The description opens with a specific verb+resource ('Compare costs for multiple LLM models') that separates it from single-cost siblings like estimate_cost or predict_cost. It does not name those siblings explicitly, so differentiation is implied by 'multiple' rather than stated.

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: use this when you have several model names and want side-by-side pricing. The client argument's role is clarified ('also flag each model runnable_in_client'), but there is no explicit when-not or named alternative such as estimate_cost for a single 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?

With no annotations, the description does disclose two important behaviors: API-key auth on the MCP connection and cross-org IDs reading as not found. However, it does not state that deletion is irreversible, whether confirmation is required, or what the deletion returns, so it does not fully carry the behavioral burden 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?

Two tight sentences, front-loaded with the action and with the auth/error constraints following. No repetition or 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 tool with no output schema and no annotations, the description covers the key invocation constraints: required API key, org-scoped IDs, and not-found behavior for cross-org IDs. The main omission is irreversibility/return behavior, which keeps it from a 5.

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

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

Schema coverage is already 100%, so baseline is 3; the description adds meaningful org-scoping semantics for alert_id by saying another org's ID reads as not found. It still does not add format/type details, but those are in 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?

Names the specific verb (delete) and resource (budget-spend alerts) and scopes it to the caller's org and an ID. That is enough to distinguish it from delete_price_alert (price alerts) and from list/register budget-alert 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 explicit when-to-use guidance, no when-not-to-use, and no named alternative for obtaining the ID or for price-alert deletion. The agent must infer usage from the tool name and schema.

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 operator-key requirement, accepted auth headers, and the operator_key_required error. It states what is deleted but does not explicitly mention irreversibility or confirmation behavior.

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 efficient sentences with no waste. The core purpose is front-loaded, followed by usage guidance and then the critical auth constraint.

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

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

The description is complete for a single-parameter destructive tool with no output schema: it covers purpose, usage, prerequisitive lookup, auth, and the expected error. The main remaining gap is that it does not state whether deletion is permanent or what a successful response looks like.

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

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

The schema already fully documents conversation_id, so the baseline would be 3. The description adds useful procedural meaning by telling the agent to use list_conversations first to find the ID.

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

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

The description states a specific verb and resource: delete a specific chat conversation by its ID. It clearly distinguishes this from list_conversations, which is named as the way to obtain the ID.

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

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

It explicitly says when to use the tool (user asks to delete, clear, or remove a past conversation) and names list_conversations as the prerequisite lookup. It also gives a clear operator-only precondition with the expected auth mechanisms and failure code.

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 well: it discloses the exact authentication requirement, accepted header forms, and the error code for unauthorized callers. It does not explicitly state that deletion is permanent or irreversible, which is the main remaining behavioral gap 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?

The description is front-loaded with the core action, then adds the crucial operator restriction and the alternative routing in later sentences. Every sentence contributes distinct information, and there is no redundant restatement of the tool 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?

For a one-parameter destructive tool with no annotations or output schema, the description covers the main operational requirements: authentication, caller restrictions, error behavior, and routing to manage_price_alert. It could be slightly more complete by stating that deletion is permanent, but otherwise it gives an agent enough to invoke the tool 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 coverage is 100%, so the alert_id parameter and its source are already documented by the input schema. The description says deletion is by ID but adds no further syntax, constraints, or format details beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

States a specific verb and resource: delete a registered price-change alert by ID. It also distinguishes the operator-only path from the self-service path via manage_price_alert, so an agent can tell when this tool applies rather than guessing 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?

Explicitly names the required operator key and says any other caller, including the chat agent and local STDIO server, will receive operator_key_required. It also names the correct alternative for self-registered alerts: manage_price_alert with the registration alert_token.

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 thoroughly: it discloses real spend to the caller's provider keys, org-level billing, required auth (x-api-key / Bearer), specific failure codes (dispatch_requires_api_key, dispatch_requires_hosted_mcp), refusal parity with HTTP, and non-streaming/text-only limits. It also warns about latency with failover and names the exact knobs (failover.timeout_ms, max_attempts, LLM_PRICING_MCP_TIMEOUT_MS) to bound it.

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 the tool does and what it returns before drilling into auth and limits, and nearly every sentence carries operational information. It is dense and long — the final npx-bridge timeout sentence is crammed in and slightly reads as an appendix — but no sentence is pure 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 paid, network-bound, policy-driven tool with no annotations and no output schema, the description supplies everything an agent needs before calling: cost implications, credential requirements, return payload shape, and latency-control parameters. Nothing critical is left to inference, and the receipt contents are enumerated so a missing output schema is not a 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 baseline is 3, but the description adds real value: the prompt-vs-messages mutual exclusivity, 'system' only valid with prompt, and the key default that omitting `dispatch` yields the balanced objective with failover on. The nested dispatch object also gains the pointer that it is identical to the HTTP body field. It stops short of explaining tradeoffs among objectives or the shadow behavior beyond what the schema states.

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

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

States a specific verb+resource ('Send a text chat request through the dispatch gateway'), then explains the mechanism (policy -> best eligible model) and the exact return payload (completion, usage, dispatch_receipt with chosen model/reason/cost/savings/attempts). It also anchors the tool to its HTTP equivalent (POST /v1/chat/completions with a `dispatch` object), which immediately separates it from the read-only pricing/analytics siblings like estimate_cost or compare_costs.

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 use conditions ('This makes a REAL model call billed to your own provider keys') that implicitly route estimation/analysis work to the sibling cost tools, plus explicit exclusions ('Text-only, single-choice, non-streaming; no tools/functions'). It does not name any sibling tool by name or state a when-not against a specific alternative, which keeps it 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?

With no annotations, the description carries full burden but only restates the basic purpose. It does not disclose important behaviors like currency fallback, handling of unsupported models, or what the response includes, leaving the agent to infer from the schema alone.

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, front-loaded sentence with no wasted words. It is efficient, though its extreme brevity leaves gaps that could be filled without sacrificing 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?

Given the tool has 5 parameters, 3 required, and no output schema, the description is too sparse. It does not explain return values, currency handling, or edge cases like unsupported models, which an agent would need to know for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional meaning beyond what the schema provides, which is acceptable given the high coverage.

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

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

The description states a specific verb ('Estimate') and resource ('cost of using a specific LLM model'), making the core action clear. However, it does not differentiate this tool from siblings like predict_cost or compare_costs, which also deal with cost estimation.

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 alternatives such as predict_cost, compare_costs, or get_all_pricing. No exclusions, prerequisites, or context for selection 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?

With no annotations, the description carries the full behavioral burden, but it only says pricing is 'current'. It does not disclose freshness guarantees, caching behavior, authentication requirements, rate limits, or what the returned data looks like. It is not misleading, but it is thin for a tool with no structured behavioral hints.

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 front-loaded sentence with no wasted words. It is appropriately sized for a simple read operation.

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 low-complexity pricing lookup, the description is adequate but incomplete. It does not explain the return shape or clarify sibling boundaries, and because there is no output schema and no annotations, those gaps are more visible.

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 fully documents the optional country and currency parameters, including enum values and fallback behavior. The description adds no parameter-level meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description gives a clear verb and resource ('Get current pricing') and scopes it to 'all LLM models from all providers'. That scope implicitly distinguishes it from narrower siblings like get_ide_pricing or get_pricing_history, but it does not explicitly name any alternative tool.

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

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

The description gives no explicit guidance on when to use this tool versus the many pricing-related siblings such as check_price_drift, get_pricing_history, compare_costs, or get_ide_pricing. Usage is only implied by the broad scope of the tool.

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?

With no annotations, the description carries the burden and does most of it: it discloses the auth requirement (x-api-key or Bearer), the data source (usage events logged via record_usage, so empty until that runs), and the org scoping constraint that org_id must match the key's org. It does not mention pagination, rate limits, or behavior on an empty window, which keeps it from 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?

Three sentences with zero filler, front-loaded with what is returned before the usage guidance and then the auth prerequisite. Every sentence carries distinct information an agent needs.

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, but the description enumerates the return content (total cost, request count, per-model and per-provider breakdowns), and prerequisites are covered. For a two-optional-parameter read tool, nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, so both parameters are already documented with defaults, bounds, and org scoping. The description restates the org_id default/must-match rule but adds no format or syntax detail beyond 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?

Specific verb+resource ('Get a summary of actual recorded LLM spend') plus the exact contents (total cost, request count, breakdowns by model and provider). It explicitly distinguishes itself from estimate_cost by naming the contrast case (hypothetical cost estimate) and identifies record_usage as the data 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?

States the trigger condition directly: 'Use when the user asks what they've actually spent, as opposed to a hypothetical cost estimate.' That is an explicit when-to-use plus an explicit alternative, so an agent can route between get_usage_summary and estimate_cost/compare_costs without opening either schema.

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. 'Get' implies a read operation, but the description does not disclose return format, filtering behavior, currency conversion effects, or any other operational details.

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, front-loaded sentence with no wasted words. It is appropriately sized for a simple retrieval 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?

There is no output schema, and the description only broadly indicates that recommendations and strengths are returned. It omits important context implied by the schema, such as price conversion via country/currency and provider 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 description coverage is 100%, so the country, currency, and provider parameters are already well documented in the schema. The description adds no parameter-specific meaning beyond that baseline.

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

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

The description states a clear verb and resource: 'Get recommended use cases and strengths for LLM models.' It identifies the content returned, but does not differentiate this tool from siblings such as recommend_model.

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

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

It gives no explicit guidance on when to use this tool versus alternatives like recommend_model or compare_costs. The only implied usage is needing model use cases and strengths, with no exclusions or prerequisites.

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: server-side cost computation never trusted from the caller, per-entry failure isolation that does not fail the batch, and precise idempotency semantics including the derived key when request_id is omitted. It also discloses auth requirements (x-api-key or Bearer, org_id must match key's org) and the 1,000,000-byte body cap with 413 behavior plus a splitting workaround — behavioral facts an agent cannot infer 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?

Front-loaded with purpose and counterpart relationship, and every sentence carries a distinct fact. It is, however, one dense wall of prose running to dozens of clauses, and the size-cap guidance at the end reads as a second paragraph crammed into the first.

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 mutation tool with no annotations and no output schema, everything an agent needs is present: auth, org scoping, per-entry error behavior, idempotency, payload limits with a batching strategy, and where the imported data becomes visible afterward. Nothing material is left to inference.

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 earns a bump by explaining the interaction between fields — one shared session_id across entries, and each entry resolving input/output tokens independently from exact counts or by estimation from raw text. It also clarifies that the idempotency key is derived from session_id/model/occurred_at/token-or-text, though this partially restates 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 and resource ("Bulk-import a completed session's usage") and immediately positions itself relative to a sibling ("the retroactive counterpart to record_usage"). An agent can distinguish it from record_usage and analyze_session_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: a session wasn't instrumented live, and the caller already holds turn-by-turn history locally (e.g. VS Code Copilot Chat). It also names the alternative (record_usage) and the downstream read path (analyze_session_usage, GET /usage/session/{id}), so both the trigger and the follow-on are unambiguous.

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 reasonably well: it discloses the auth mechanisms accepted, the org-scoping of results, and what the response contains (alert IDs and settings). It stops short of stating that the call is read-only, how results are ordered, whether pagination applies, or what an empty result means.

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 earning their place: the first states the action and returned content, the second states the auth prerequisite and scoping rule. The primary purpose is front-loaded with no redundant name restatement.

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

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

For a zero-parameter read tool with no output schema, the description covers the essentials an agent needs: auth requirements, result scoping, and the shape of returned data. It could be complete with a note on ordering/pagination behavior or empty-result handling, but nothing critical is missing for correct invocation.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain; baseline 4 applies. The description correctly implies no filtering arguments are needed because scoping is derived from the connection's API key.

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: listing the org's registered budget-spend webhook alerts, including IDs and settings. It is distinguishable from the closest sibling, list_price_alerts, by the explicit 'budget-spend' qualifier, but the description never names or contrasts that sibling, so differentiation is inferred rather than stated.

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 precondition that a service API key must be present on the connection (x-api-key or Bearer) is useful usage context, and it implies only that org's alerts come back. However, there is no explicit when-to-use guidance, no mention of when not to use it, and no reference to alternatives such as list_price_alerts or the register/delete_budget_alert 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 and does well: it discloses the authentication requirement (MCP_API_KEY via x-api-key or Bearer), the exact failure mode (error_code operator_key_required), and that the chat agent and local STDIO server are excluded. It omits ordering of results and pagination behavior, which an agent would want for a list 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?

Three tight sentences: purpose and return fields first, usage trigger second, access constraint third. No filler, and the most decision-relevant information is front-loaded.

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

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

No output schema exists, and the description compensates by listing the returned fields. Auth and error behavior are covered. The main gap is result ordering and whether more than 100 conversations require paging, minor for a single-parameter list tool.

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

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

Schema coverage is 100% and the only parameter (limit, default 20, max 100) is fully documented in the schema. The description adds no parameter-level detail such as ordering or cursor behavior, 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 (list stored chat conversation sessions) and enumerates exactly what each entry contains: ID, last-updated timestamp, turn count, and a preview of the most recent user message. This distinguishes it clearly from destructive siblings like delete_conversation and from analytics siblings like analyze_session_usage.

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 says when to use it: 'when the user asks to see their past conversations or chat history.' The operator-only constraint is a strong gating condition, though no alternative tool is named for the non-operator case, leaving the fallback route implicit.

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 discloses important operational behavior: it requires MCP_API_KEY on the MCP connection via x-api-key or Bearer authorization, and non-operator callers receive error_code operator_key_required. It does not explicitly state that the operation is read-only, nor does it describe pagination or the exact shape of the returned settings.

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 tightly written sentences: the first defines the resource and returned fields, and the second covers access control. There is no filler, and the main purpose is front-loaded.

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

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

For a zero-parameter listing tool with no output schema, the description provides enough to call it correctly: what it lists, what is returned in principle, who may call it, how authentication is supplied, and what error unauthorized callers see.

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

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

The tool has zero input parameters, so the baseline is 4. The description adds no parameter information, but none is needed for this 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 gives a specific verb-resource pair: list registered price-change webhook alerts, including their IDs and settings. This clearly distinguishes it from sibling alert tools such as list_budget_alerts, which concerns a different 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?

The description establishes an operator-only usage condition and explains which callers are rejected, but it does not explicitly compare this tool with alternatives such as list_budget_alerts or describe when to use listing versus registering or deleting price alerts. Usage is therefore implied rather than fully guided.

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 zero annotations the description carries the full burden, and it does substantial work: authentication model (token as credential, scoped to exactly that alert), the fields 'view' returns, that 'delete' stops the alert, and a deliberate non-enumerable error behavior ('same invalid_alert_token refusal whether or not any alert exists'). It loses a point for not stating whether deletion is permanent or recoverable.

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 verb-and-resource plus the credential model, then layered with return fields, security behavior, and legacy handling. Dense and mostly waste-free; the enumeration of returned fields is the one sentence that could arguably compress given the action 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 annotations and no output schema, so the description correctly compensates by naming the return fields for 'view' and the effect of 'delete'. Authentication, token provenance, error-shape, and legacy-alert handling are all covered. The only real omission is deletion permanence/irreversibility.

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 both parameters are already documented, including the enum semantics and the 'never put it in a URL' warning, so the description mostly restates existing text. The provenance note ('returned once') and the scoping claim add marginal enrichment, but this is the baseline-3 case where the schema does the heavy lifting.

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

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

States a specific verb pair and resource: view or delete a stored price-change alert, authenticated by the alert_token issued by register_price_alert. The credential/scope framing makes the tool's nature unmistakable. It stops short of a 5 because it never acknowledges the sibling delete_price_alert or list_price_alerts, so an agent must still infer why this token-scoped path exists alongside 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 clear operational context ('No API key needed: the alert_token is the credential') and one real exclusion ('Alerts registered before v1.81.0 have no token and are removed via the operator'). However, 'via the operator' is undefined, and it offers no guidance on when to reach for its 'delete' action versus the delete_price_alert sibling, leaving the main routing decision implicit.

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 and does well: it discloses the return payload (per-task allocation, total monthly cost, saving versus best single-model deployment), the budget behaviour (leftover headroom spent on cost-efficient quality upgrades), and the client-resolution precedence including fallback to MCP handshake inference and the unfiltered-result fallback for unknown names. Auth, rate limits and caching behaviour are not mentioned, which is the only 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?

The core value and usage trigger are front-loaded, but the description then repeats the entire 15-item client list and the precedence chain that the schema's client parameter already spells out verbatim. That redundancy is roughly a third of the text and does not earn 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, so the description must explain returns — and it does, naming all three output components plus the budget-driven upgrade behaviour. For a 4-param analysis tool with no annotations, nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the schema already documents client, workloads, budget and quality floors. The description restates the client precedence and budget-usage semantics rather than adding new syntax or format detail, so it sits at the baseline for a fully documented 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 (optimise/assign) and resource (multi-task LLM workload) and explicitly contrasts with the alternative of 'running everything through one model', which separates it from siblings like recommend_model, compare_costs and estimate_cost. The first sentence alone tells an agent exactly what the tool produces.

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 how to cut LLM spend across several task types, or whether tiered model routing is worth it.' It does not name sibling tools to avoid (e.g. recommend_model for single-task decisions), so routing is clear but not fully bounded.

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 does so: it declares 'Read-only', discloses the ranking method (live pricing + benchmark quality, hard filters, quality-per-dollar scoring), the return shape (best match plus up to 3 alternatives), and non-obvious fallback behavior — client restriction is a filter not a boost, explicit client wins, omission triggers handshake inference, and unknown names return an unfiltered result plus a 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?

Purpose and alternatives are correctly front-loaded, but the paragraph is dense and includes a full enumeration of 14 recognised client names that the client parameter's schema description already lists in greater detail — roughly a fifth of the text is redundant. It is informative rather than padded, but it is longer than it needs to be.

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 16-parameter, no-annotation, no-output-schema tool, the description covers what matters most: purpose, alternatives, read-only safety, ranking method, and return shape. The remaining gap is that the cost/currency/budget parameters are left entirely to the schema, which is acceptable given 100% schema coverage but means the description alone would not tell an agent the tool supports currency conversion or budget hard-filters.

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 earns above that by explaining the semantics an agent would otherwise get wrong — that client restricts rather than boosts the candidate set, the precedence order, and that omitting it degrades to every priceable model. It does not touch the other 13 parameters (budget, currency, token averages), but the schema already documents those fully.

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?

Opens with a specific verb+resource ('Recommend the optimal LLM model') and immediately names the mechanism (classifies free-text into task_type, runs it through the same routing engine behind /router/recommend). It explicitly distinguishes itself from the two nearest siblings, predict_cost and optimize_workload, so an agent can choose 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 explicit when-to-use-this vs when-to-use-alternatives routing: '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.' It also states the input precondition (free-text description, no need to know the task_type vocabulary) and how to get a filtered vs unfiltered answer via client.

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 supplied, and the description carries the full burden well: it discloses that cost is computed server-side and never trusted from the caller, that duplicate request_ids are a no-op, that usage is attributed to the caller's org, and what credentials the MCP connection must carry. That is exactly the mutation/auth/idempotency context an agent needs before writing data.

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

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

Front-loaded with purpose and the estimate_cost contrast, which is the highest-value sentence. A few clauses are redundant with the schema (org attribution repeated twice), costing a little density, but every sentence still contributes.

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 write tool with no annotations, the description covers purpose, auth, idempotency, and attribution. It stops short of stating what is returned (e.g. a computed cost value) and omits the session_id grouping hint that matters for the analyze_session_usage workflow, leaving a small 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 every parameter is already described in the schema, and the description largely restates those (org_id defaulting/matching, request_id idempotency). It adds no format or range guidance for input_tokens/output_tokens and never mentions session_id or occurred_at, so no credit above the baseline.

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 immediately scopes it against the sibling estimate_cost ("the 'actual spend' counterpart to estimate_cost's hypothetical numbers"). An agent can distinguish this from estimate_cost, compare_costs, and import_session_usage 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?

Explicit trigger ("Use when the user wants to log or track real LLM spend, not just estimate it") plus an explicit exclusion pointing at the alternative. The idempotency note also tells the agent it is safe to retry with the same request_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?

With no annotations, the description carries the full burden and does well: it discloses the fire-once-per-period_days deduplication behavior, the auth requirement (service API key via x-api-key or Bearer), the org-scoping constraint, and that it returns an alert ID. It omits what happens on re-registering an existing URL (duplicate vs. update) and webhook retry/delivery semantics.

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, followed by firing behavior, return value, and auth prerequisites — no filler and nothing buried.

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 it returns the alert ID; auth and org scoping are also covered, which is essential given zero annotations. The remaining gap is lifecycle behavior for an already-registered URL, which matters for a create tool the agent may call repeatedly.

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 schema already explains period_days as a rolling look-back and org_id's default-and-match rule. The description reinforces the record_usage linkage behind threshold_usd but adds no new syntax, format, or unit detail beyond the structured fields.

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?

Specific verb+resource: registers a webhook URL that notifies when actual spend recorded via record_usage crosses a USD threshold. It names the data source (record_usage) and the monitored object (org spend), which cleanly separates it from record_usage and from sibling alert tools like register_price_alert.

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 states the condition that makes this the right tool — you want notification when real recorded spend crosses a threshold in a rolling window — and points at record_usage as the spend source. It does not explicitly contrast with register_price_alert or list_budget_alerts, so the agent must infer the boundary from names.

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 meaningful work: it discloses that the URL receives a POST, that registration yields an alert ID plus a one-time alert_token, and that the token is required to manage the alert afterward. It omits auth requirements, duplicate-registration behavior, and 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?

Three front-loaded sentences: purpose, optional scoping, then return value and lifecycle pointer. No filler, but the scoping sentence largely restates schema fields and could have been folded into the first to tighten the definition.

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 the description compensates by naming both return values (alert ID and one-time alert_token) and where they are consumed. For a four-parameter creation tool with fully documented parameters, only missing auth/duplicate-handling context keeps it from 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% and already covers the webhook constraints, provider/model scoping, and the threshold default. The description only paraphrases that scoping in prose ('Optionally scope the alert to a specific provider or model'), adding no format, enum, or edge-case detail beyond what the schema provides, so the baseline 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?

Specific verb+resource ('Register a webhook URL') with the trigger condition (price change beyond a percentage) stated up front. The second sentence narrows scope and the third names the sibling (manage_price_alert) that handles later lifecycle, so an agent can distinguish it from list_price_alerts and check_price_drift without inspecting 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 says the provider/model scoping is optional and directs follow-up operations (view/delete) to manage_price_alert, which is the key routing decision for this family of tools. It stops short of saying when *not* to register, e.g. versus check_price_drift for one-off inspection, so it is clear context without full 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?

With no annotations present, the description carries the full burden and does so: it discloses the answer corpus (FAQ + plan catalogue + caller's account), identity-awareness via x-api-key/Authorization header, the read-only guarantee ("never reveals keys or other customers' data, never changes billing"), a per-caller daily cap whose breach returns a non-LLM fallback with FAQ links, and the local STDIO refusal path.

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 and topic list, then the constraints — the ordering is right and essentially every clause carries information an agent needs. It is still a single dense run-on paragraph of prohibitions and edge cases that would scan better as structured clauses, which keeps it off 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?

For a chat tool with no annotations and no output schema, the description covers sourcing, escalation, identity modes, limits and failure modes — nearly everything an agent needs to call it safely. It never sketches the reply shape (answer text plus a conversation_id to continue), leaving that to be discovered at runtime.

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 both parameters are documented there, including the 10,000-character limit and that conversation_id comes from an earlier reply. The description adds no syntax or usage detail about these two fields, so the schema does the work — 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?

Opens with a specific verb+resource ("Ask the customer support assistant") scoped to THIS service, then enumerates the covered topics (plans, invoices, API keys, rate limits, MCP/REST, data accuracy, owner contact). The scope is unmistakable, but it never names the obvious sibling `ask_agent` or explains how it differs, so an agent facing both must infer the split.

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 (service/plan/billing/API-key questions) and explicitly enumerates what falls outside its remit — refunds, credits, disputes, lost key without current key, human handoff, security reports — all of which get escalated to the owner with a reference. It also states the STDIO precondition. What's missing is an explicit "use X instead" routing to sibling tools for non-support questions.

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