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

Annotations already establish read-only, idempotent, open-world behavior, so the bar is lower. The description adds genuinely useful context beyond them: it costs 0 units and still works once the quota is spent, which is the key operational fact for an agent managing a usage allowance.

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

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

Three short clauses carry the purpose, cost model, and invocation advice with no filler. The most actionable instruction ('call this first if unsure') is placed last for emphasis after the cost reassurance.

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 takes on the burden of describing the return by naming the three things it reports (plan, units used, unlocked tools). Combined with the zero-parameter schema, an agent has everything needed to call and interpret it.

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

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

The tool takes zero parameters, so the baseline is 4. There is no parameter surface for the description to explain, and it correctly does not invent one.

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?

It states a specific resource (the Flipzi plan/account) and enumerates exactly what is returned: plan, units used this month, and which tools the plan unlocks. This clearly separates it from the flipzi_list_*/get_* siblings, which all deal with cards, sets, or prices rather than account state.

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 guidance is given in both directions: call it first when uncertain about capabilities, and it remains callable even when the allowance is exhausted. The agent knows both when to reach for it and why it is safe to do so early.

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?

Goes well beyond the readOnly/idempotent/openWorld annotations by disclosing the price source (CardMarket EUR), the low/base/high range structure, the estimation caveat (pull rates are estimates, not a promise), the plan gate, and the per-call cost of 1 unit.

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

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

Front-loads the core comparison and keeps the multi-mode behavior, caveats, plan requirement, and cost tight. Dense parentheticals but no wasted sentences; each clause carries information.

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

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

With no output schema, the description compensates by describing return shape (range values, top cards, history) and data provenance. Annotations cover the safety profile and the plan/cost caveats are stated, leaving nothing essential for 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 coverage is 100%, so the baseline is 3. The description adds real semantics beyond the schema by explaining what each mode returns: listing all boxes vs. top cards and history for a specific slug. The default of 90 for history_days is already covered by 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 concrete verb+resource: comparing sealed booster-box price against the estimated value of cards inside, with a clear scope (English Pokemon boxes passing Flipzi checks). It is implicitly distinguishable from card-level siblings like flipzi_get_price and flipzi_get_sold_comps, 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 explicit mode selection: omit `set` to list every published box, pass a slug (from the list) to get top cards and history. Also states the plan prerequisite (pro or higher) and cost (1 unit). No explicit exclusions against alternative tools, but the when-to-use conditions are clear.

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

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

Annotations already establish readOnly/idempotent/openWorld, so the description's real contribution is operational: it is free-plan eligible and costs 1 unit. Billing and plan eligibility are behavioral traits the annotations cannot express, which is genuine added value, though nothing is said about response size or rate limits.

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

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

Three short sentences, each carrying distinct information (scope, plan, cost), with the content-defining scope statement front-loaded and zero filler.

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

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

No output schema exists, so the description must hint at the return shape; 'card metadata and variants' plus the price exclusion does that at a high level for a low-complexity, single-required-param getter, and plan/cost context is supplied. It stops short of enumerating what 'metadata' contains.

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 a single well-documented card_id whose description even names where to obtain it. The tool description adds nothing further about the parameter, 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 — card metadata plus variants — and immediately scopes it with '(no prices)', which separates it from flipzi_get_price and the pricing siblings. It does not name an alternative tool outright, but the resource is unambiguous.

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 '(no prices)' carve-out implies that price lookups belong to flipzi_get_price, and the schema routes card_id acquisition to flipzi_search_cards / flipzi_list_set_cards, but the description itself never states when to choose this tool over those 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?

Annotations already cover the safety profile (readOnly, idempotent, openWorld). The description adds real operational context beyond them: plan-tier gating, the depth ceiling that varies by plan, and an explicit per-call cost of 1 unit. It stops short of describing what the "summary" portion returns, but this is solid added value.

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

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

Three short, front-loaded sentences with no filler: purpose first, then the gating constraint, then cost. Every clause carries information, though the telegraphic phrasing reads slightly compressed.

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 parameterized read-only tool with no output schema, the definition covers access requirements, depth limits, and cost – the practical things an agent needs before calling. It is missing only a description of the returned series/summary shape, which a lack of output schema makes slightly more noticeable.

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 75%, giving a baseline of 3, and the description goes further by explaining that the history depth (and therefore valid period values like 90d/1y/all) is capped by plan tier. That constraint is not encoded in the enum schema alone, so it materially improves parameter interpretation. The grade parameter remains unexplained in both places.

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?

"Daily price history and summary" states a specific resource (price history) and the cadence (daily), which tells the agent it is a time-series tool rather than a spot lookup. However, it never distinguishes itself from the sibling flipzi_get_price or flipzi_get_sold_comps, leaving the agent to guess which history/pricing tool 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 plan prerequisite ("Requires the basic plan or higher") and the depth caps are stated, which tells the agent when the tool is callable at all. But there is no guidance on when to prefer this over flipzi_get_price for a single quote, so the use case is only implied.

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

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

Annotations already cover safety (readOnly, idempotent, openWorld), but the description adds two things they don't: a per-call cost of 5 units and an 'ultra plan or higher' entitlement requirement. That materially affects invocation decisions. It loses a point for restating the cost twice and saying nothing about pagination or what a full response contains.

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, which is good, but the cost is stated twice ('Costs 5 units per call' and 'Cost: 5 units.'), so the last sentence is pure waste. The three sentences are short but not all earn their place.

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

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

For a six-parameter tool with no output schema, the description should say more about the shape of results (e.g. that limit applies per direction, which direction defaults to). The entitlement and cost details are covered, but return semantics and the meaning of set_id/direction are left entirely to the schema.

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

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

Schema coverage is 67%, so several parameters are already documented. The description only obliquely touches parameters via 'over a window' and 'gainers/losers', but adds no syntax or semantics for set_id (undocumented in the schema) or direction. Baseline 3 fits a description that leaves the schema to do 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-like action and resource: biggest price gainers/losers for a game over a window. It's clearly distinct from siblings like flipzi_get_price or flipzi_get_history, which fetch individual or historical prices rather than ranked movement. It stops short of naming an alternative to differentiate itself, but the resource is unambiguous.

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?

Provides a cost-driven usage constraint ('use sparingly') and a plan prerequisite, which is genuine guidance. However, it never says when to prefer this over flipzi_get_price or flipzi_get_history, nor when a movers query is the wrong tool. Usage is implied rather than routable.

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

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld), so the bar is lower, and the description clears it by disclosing plan gating for graded values, free-plan availability, and a unit cost. That is real non-obvious context an agent needs before calling. It stops short of describing freshness/latency or what happens when a card has no price.

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

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

Three short sentences, front-loaded with what the tool returns. Each sentence carries information, though 'Available on the free plan' and 'Cost: 1 unit' are adjacent gating facts that could be tightened into one clause.

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

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

There is no output schema, so the description properly names the return components (price, market, confidence rating), and it covers the free/Pro split that governs which inputs are legal. Coverage is solid for a 3-param read tool; it lacks only edge-case behavior (no price found, currency conversion semantics).

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 grade, card_id, and currency, including the RAW default and the Pro requirement. The description's 'Raw (ungraded) by default' restates schema content rather than adding new meaning. Baseline 3 is correct when the schema does the heavy lifting.

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

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

States a specific verb+resource ('Current price for a card') and names what comes back (market of origin, confidence rating). It is distinguishable in spirit from siblings like flipzi_get_sold_comps and flipzi_get_history, but it never names an alternative, so it lands just short of 5.

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

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

Usage is only implied by the resource name. The description instead spends its words on plan gating ('graded values need the Pro plan', 'Available on the free plan') and cost, which help selection but are not when-to-use-vs-alternative guidance. No sibling or exclusion is mentioned.

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

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

Annotations already establish read-only, idempotent, open-world behavior, so the description's job is additive — and it delivers: the data source (eBay blended sold comps), the plan tier requirement, and per-call unit cost. It does not describe the shape or volume of results, which would have pushed this higher.

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

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

Three short sentences, zero filler, and the substantive definition ('what buyers actually paid on eBay') is front-loaded before the access constraints. Every clause carries information.

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

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

Covers the sourcing, gating, and cost dimensions well, but with no output schema and two undocumented parameters, an agent still lacks detail on what a 'blended' comp set contains, how grades/languages alter results, and what the response looks like. Adequate but with visible gaps.

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 only 50%, and the description explains none of the parameters. 'grade', 'language', and 'currency' (default eur, enum in schema) carry no meaning beyond the schema, and only card_id has a description. The description does not compensate for the coverage gap.

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 resource and scope: eBay sold comps ('what buyers actually paid ... blended sold comps') for a card. Clearly distinct from flipzi_get_price and flipzi_get_history in intent, though it stops short of naming those siblings explicitly.

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

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

Gives access prerequisites (pro plan or higher) and a cost (1 unit), which is useful gating context, but says nothing about when to prefer this over flipzi_get_price, flipzi_get_history, or flipzi_get_movers. Usage is implied by the resource name only.

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

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

Annotations already declare readOnly, idempotent, and openWorld, so the safety profile is covered. The description adds genuinely new operational context that annotations cannot convey: free-plan availability and a cost of 1 unit, which matters for an agent budgeting calls.

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

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

A single compact sentence with the primary purpose front-loaded and the two metadata facts (plan, cost) appended without padding. Nothing here is redundant with 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?

There is no output schema, but the description compensates by naming what is returned (the games covered) and how the return value is consumed (ids used as `game`). No pagination or result-shape caveats, but for a trivial zero-argument enumerator the coverage is sufficient.

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

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

The tool takes zero parameters, so there is nothing for the description to clarify beyond the schema. Baseline 4 applies for a parameterless listing call.

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 (lists the trading card games Flipzi covers), which is unambiguous on its own. It does not distinguish itself from siblings like flipzi_list_sets or flipzi_list_set_cards, which share the same 'list' pattern, so an agent gets no explicit pointing signal.

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 only implied: the tool is clearly the entry point for discovering game ids. The parenthetical 'use the returned ids as `game` elsewhere' does give real chaining guidance, but there is no statement of when to prefer this over sibling list tools or any prerequisite/order-of-calls advice.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint). The description adds genuinely new operational context — free-plan availability and a 1-unit cost — which is real value. It says nothing about pagination behavior even though page/page_size exist, so it stays at a 3.

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

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

Three short sentences, front-loaded with the operation and ordering, then use case, then the cost/plan constraint. Nothing is padded, though the constraint sentences are a bit clipped.

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 4-parameter read tool with no output schema and read-only annotations, the definition covers the essentials and hints at the return (card ids). It omits pagination semantics despite exposing page and page_size, which an agent must guess at.

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 75%: game, set_id and page_size are documented in the schema, while page is not. The description only implies set scoping and ordering and adds no format or paging detail, so the baseline 3 for high schema coverage 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 ('Lists the cards of one set') plus the ordering ('in number order'), which cleanly separates it from flipzi_list_sets and flipzi_get_card. It does not explicitly name the sibling it should be preferred over, so it falls short of a 5.

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

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

'Use it to get card ids' gives one positive use case and the free-plan/cost note is useful context. There is no guidance on when to prefer flipzi_search_cards or flipzi_get_card instead, nor any prerequisite beyond the implied set_id.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds genuinely new operational context beyond annotations: free-plan availability, a cost of 1 unit, and paginated results.

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 short, front-loaded sentences with no filler; the core purpose leads and the plan/cost constraints follow. Nothing is wasted, though it is terse enough that it borders on under-specification rather than maximal efficiency.

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 paginated list tool with no output schema, the description never characterizes the returned set objects or paging metadata. Annotations cover safety, but the agent lacks detail on what a page contains; the cost/plan notes partially compensate.

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 67%: 'game' and 'page_size' (default 25) are documented in the schema, while 'page' has no description. The description only contributes the word 'paginated', which implies a paging model but adds no format or range detail beyond the schema.

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

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

States a specific verb and resource ('Lists the sets of one game') plus the pagination behavior, which distinguishes it from siblings like flipzi_list_games and flipzi_list_set_cards. It does not explicitly name those siblings, so it falls short of a 5.

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

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

There is no explicit when-to-use/when-not-to-use statement or named alternative among the ten siblings. Usage is only implied by the required 'game' parameter and the schema note that the id comes from flipzi_list_games, which is a weak but present routing hint.

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

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

Annotations declare readOnly/openWorld/idempotent, so the safety bar is already met; the description goes further with the matching algorithm, the plan gate (free plan) and a per-call cost of 1 unit, which is real operational information. It does not describe result shape beyond "card ids" or paging 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?

Four short, front-loaded fragments: purpose, matching rule, downstream dependency, plan/cost. Every sentence earns its place and the most decision-relevant facts come 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 read-only search with no output schema, the description covers purpose, matching behavior, workflow dependency and cost, and the schema covers the parameters. Only the return shape beyond "card ids" and pagination expectations (page/page_size) are left implicit, which is a minor 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 71% and the schema documents q, game, lang, number and page_size. The description adds the one non-obvious rule — last-word prefix matching for q — that the schema omits, which is exactly the kind of extra the description should carry at this coverage level.

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?

"Searches cards by name" is a specific verb+resource, and the parenthetical "(last word prefix-matched)" pins down the matching semantics precisely. It also signals its place in the workflow ("Returns card ids needed by every price tool"), which implicitly separates it from price/history siblings, though it never names a sibling like flipzi_get_card to differentiate lookup-by-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?

Gives clear context for when to reach for it — it is the id-acquisition step that precedes every price tool — plus the constraint that it is on the free plan at a cost of 1 unit. No explicit when-not or named alternative (e.g. use get_card when the id is already known), so it stops just short of full routing guidance.

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