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

No annotations are provided, but the description richly explains behavior: it compares medians, not extremes; it explains why extremes are unreliable (fat-finger, stale listings); and it warns that a median crossing is a lead, not a guaranteed trade. This is exactly the behavioral context an agent needs before invoking the 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?

The description is longer than average, but all detail earns its place: the worked example illuminates a real failure mode)Skip? The text is structured around a clear claim, a concrete example, and an action-guiding caveat. It could drop some anecdotal specifics, but it is not bloated or repetitive.

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 conceptual nuance of median-vs-extreme crossing, the description covers the decision-relevant context thoroughly. It omits parameter-level explanation and return-shape details, but the output schema exists separately and the core invocation context is sufficiently explained.

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 has 0% coverage and the description never mentions limit, league, or min_profit_pct. An agent must infer their meanings from names and defaults alone, with no authoritative explanation of how they interact with the median-crossing logic.

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, measurable goal: 'Find currencies where the median bid exceeds the median ask.' It also explicitly contrasts this tool with stale_extremes, which makes the tool's unique position clear without needing to inspect 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 clearly conveys when to use this tool: when you want genuine median-crossing dislocations rather than extreme-order noise. It warns that extreme crossings are often staleness artifacts and names 'stale_extremes' as the alternative, though it doesn't lay out a full when-to-use/when-not-to-use matrix.

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 it delivers: it discloses the shared 600-search/6h rate budget, states that the server cannot actually send the whisper, explains why (no GGG trade-execution API and ToS), and clarifies that a human must complete the trade. This is exactly the kind of behavioral context agents need beyond 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?

The description is compact, front-loaded with the core purpose, and each additional sentence adds meaningful operational context. There is no filler or repetition of schema-discoverable facts.

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 covers the critical rate budget, alternative tool routing, and whisper-execution constraints, and an output schema exists for return values. The main gap is the absence of parameter semantics, which leaves the agent to rely on names and defaults when constructing a query.

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

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

The input schema has 0% description coverage and the description adds no explanation of the parameters name, type, limit, or league. The parameter names are self-evident to a human, but an agent receives no guidance on what values are valid, how filters combine, or what the limit controls.

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

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

The description opens with a specific verb and resource: "Search live trade listings right now, returning prices and whisper text." It clearly identifies what the tool does and distinguishes it from siblings like get_price and search_items by its live, whisper-returning behavior.

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

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

The description explicitly tells the agent to "prefer get_price when recorded data is good enough," naming an alternative and the condition for choosing it. It also explains the rate-budget tradeoff and that this tool is the path for obtaining a human-executable trade whisper.

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 takes full responsibility for behavioral disclosure. It explains that the tool does no live API calls, that each pair rate already paid its spread, that junk listings are filtered, that min_depth limits pushable amounts, and that trades depend on human counterparties. This is a very transparent explanation of the tool's true nature, going beyond typical simple statements.

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 longer than average, but every sentence adds meaningful detail—purpose, cost model, technical constraints, and execution method. It is front-loaded with the actual purpose and then covers nuanced nuances. The length is justified by the conceptual complexity of multi-step arbitrage, though the redundant mention of the example after the first sentence slightly adds wordiness.

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 existence of an output schema, the description does not need to detail return structures. It covers the core behavior and important cautions. The omission of any parameter-level detail, combined with the phantom 'min_depth' reference, leaves a small but meaningful gap in an otherwise thorough description.

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 has zero parameter descriptions (coverage 0%), and the description does not explain the meaning of any of the five parameters. It mentions 'min_depth', which is not present in the input schema, so an agent cannot be sure whether that refers to an internal value or a missing parameter. The parameter names are somewhat self-explanatory, but the description does nothing to clarify their behavior or defaults.

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–object pair, 'Find profitable trade loops', and gives a concrete example (chaos -> exalted -> divine -> chaos). This clearly distinguishes it from sibling tools like 'find_arbitrage' by showing the multi-hop scope. An agent can tell exactly what the tool does 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?

It provides clear context for when to use the tool: it is pure analysis over already-collected rates, makes no API calls, and can be run freely. It also warns that trades complete via whisper, so results are leads rather than guaranteed executions. However, it does not explicitly mention a comparable sibling or state when to prefer this over a simpler arbitrage tool, so it lacks formal differentiation.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It gives a warning about data sufficiency but does not describe whether the operation is read-only, how results are sorted, whether both gainers and losers are included, or how league/min_sample values affect the behavior. This is only a minimal starting point.

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

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

The description is two sentences with zero filler: the purpose comes first, followed by a single necessary caveat. Every word contributes, and no essential information is buried in a longer block.

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 four parameters fully undocumented in the schema and no annotations, this description does not give an agent enough context to correctly set `league`, `limit`, or `min_samples`. The output schema exists, so return values are not needed, but the input side is insufficiently covered.

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

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

The schema has 0% description coverage, so the description is the only source for parameter meaning. It only touches `days` through the phrase 'over the window' and the condition `days + 1` days, while `limit`, `league`, and `min_samples` receive no explanation at all. This does not compensate for the schema 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?

The description states 'Items with the largest percentage price moves over a window', which clearly identifies the verb (get) and resource (movers) with a scope. It does not explicitly distinguish it from sibling tools like get_price_history or find_listings, so it misses the top score.

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 only guidance is a data requirement: 'Needs at least `days + 1` days of collected history to be meaningful.' This provides a condition to use, but it does not explain when to prefer this tool over alternatives such as get_price_history or find_listings, leaving usage partially implied.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It discloses that it reads only the local database and that 'found: false' indicates the item has not been priced, distinguishing this from unsellable. It also mentions the 'market_status' check, providing important behavioral context beyond what the schema shows.

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 concise and well-structured. It begins with the core purpose in one sentence, then adds a clarifying note about behavior. Every sentence adds value—the first defines the output, the second clarifies a common misunderstanding, and the third suggests an alternative action. No wasted words.

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 quite complete for a simple lookup tool. It mentions the output schema includes 'found', spread, and confidence, which is not in the schema description. It also provides guidance for handle missing data. However, it does not explain the 'league' parameter's role or how to handle empty values, which could be a gap for agents that need to specify league 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 0%, so the description must compensate for parameter meaning. The description explains what 'item_key' refers to (one item) but does not elaborate on the 'league' parameter, its default, or its effect on results. The description adds some value by clarifying the single-item scope but leaves the league parameter unexplained, which could lead to misuse.

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

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

The description clearly states the tool's purpose: it retrieves the latest recorded price for an item, including spread and confidence. It specifies the verb 'get' and the resource 'price' for a 'one item', distinguishing it from sibling tools like 'get_price_history' and 'find_listings'.

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 explains that it reads only the local database, providing context on when to use it. It also notes that 'found: false' is not the same as unsellable, and points to 'market_status' for further verification, which gives clear usage guidance for handling edge cases.

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 transparency burden. It discloses that the tool reads rollup candles and explains how 'auto' resolution behaves (hourly up to 14 days, daily beyond). It could mention output ordering, empty results, or league handling, but what it does share is meaningful.

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 core purpose, followed by the performance note and auto-resolution behavior. No filler or repetition.

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 covers the purpose, performance characteristics, and resolution semantics. It lacks guidance on edge cases such as unknown item keys, empty history, or league requirements, and does not distinguish itself from sibling price-related tools. Still, it is largely self-contained for a read-only history query.

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 provides names and defaults but no descriptions. The description explains the resolution='auto' behavior, which is genuinely useful beyond the schema. But days, league, item_key, and the difference between hourly/daily resolutions are left to the agent to infer.

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 object: 'OHLC price history for one item, for charting or trend analysis.' It clearly names the resource (price history) and scope (one item), though it does not explicitly contrast itself with sibling tools like get_price or get_movers.

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

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

It gives a clear intended use case ('for charting or trend analysis') and even notes that long windows remain fast due to rollup candles. However, it never names alternatives or says when to prefer this over get_price, get_movers, or other sibling tools.

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 behavioral burden. It discloses that each snapshot is valued at the prices in effect when taken, separating quantity changes from price changes. This is substantive context beyond a generic 'returns history'. It omits minor operational details like limits or snapshot cadence, but the core behavior is clear.

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

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

Two sentences, front-loaded with the core purpose, with no filler. The second sentence earns its place by explaining the valuation methodology.

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 output schema covers return shape, but the tool still lacks guidance on league selection and limit semantics, which are the only inputs. Overall it is understandable but leaves parameter-level decisions 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 description coverage is 0%, so the description needed to explain the two parameters, but it mentions neither 'league' nor 'limit'. The names are partially self-explanatory, but no description states that limit caps snapshots or which league's stash is queried.

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 ('Track') and resource ('your stash's total value') with the temporal dimension 'over time'. This clearly distinguishes it from sibling tools like get_stash_value (current value) and get_price_history (item prices).

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 purpose implies use for historical stash valuation, and the snapshot-pricing note helps set expectations, but it never explicitly names when to prefer this over get_stash_value or get_price_history, nor states any 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 provided, the description carries the full burden and does so well: it explicitly says the operation reads public listings with no login, exposes the visibility limitation, explains the account configuration, and describes the refresh behavior versus returning the latest snapshot.

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 a one-sentence purpose, then adds tightly scoped implementation context. There is no fluff or repetition of schema fields; each sentence contributes necessary guidance.

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 output schema exists, so return-format explanation is unnecessary. The description covers authentication, data source, visibility, and refresh behavior, which is strong. However, the league parameter is left undocumented and no guidance is given on valid league values or how the valuation result is expressed, leaving a meaningful 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?

The description explains the refresh parameter clearly but says nothing about league, which is one of only two parameters and has a default that is not meaningful without context. Since schema description coverage is 0%, the description needed to compensate for both parameters but only covered 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?

The description opens with a specific verb and resource: "Value your own stash against collected prices." It clearly identifies the operation as reading an account's public listings, which separates it from siblings like search_items, get_price, or get_stash_history.

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 context for when this tool is the correct path: the authenticated stash API is OAuth-only and closed, so public listings are the working approach. It also states the refresh-vs-snapshot decision. It does not explicitly name alternative sibling tools or say when not to use it.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It reveals that the output includes both the available leagues and their 'collected' status, and that the tool resolves loose league names to exact ids for later calls. This adds meaningful behavioral context beyond the tool name.

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

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

Two sentences with no filler. The purpose is front-loaded, and the usage recommendation follows naturally. 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?

For a zero-parameter listing tool with an output schema present, the description covers all an agent needs: what it lists, why it is useful, and when to call it first. Return value details are handled by the output 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?

The tool has zero parameters and 100% schema coverage by virtue of an empty schema, so there are no parameter meanings to document. The description adds value by explaining that the output contains league ids used by later calls.

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 starts with a specific verb and resource: 'List PoE2 leagues available on the trade API, and which are collected.' This clearly distinguishes it from sibling tools like search_items or find_listings, which operate on different entities.

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

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

The description gives explicit when-to-use guidance: 'Use this first when the user names a league loosely' and explains the benefit ('so later calls pass an exact league id'). It does not name exclusions or specific sibling alternatives, but the context is clear enough for an agent to route correctly.

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

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

With no annotations, the description carries the full burden, and it delivers: snapshot-based reads, stack-grouping behavior, null values for unpriced items, and filter semantics. It is transparent about behaviors an agent would otherwise have to infer or test.

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 thematic paragraphs with front-loaded purpose, a concrete example, and a compact filter list. There is no filler and no repetition of schema defaults.

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 output schema covers return shape, and the description covers behavior and filter usage, so an agent can invoke it correctly with no arguments or with a meaningful filter. Minor gaps such as league default, priced_only semantics, and pagination behavior keep this 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?

The description adds real meaning for group_stacks with a concrete example, plus semantics for search, tab, and rarity. However, with 0% schema coverage and 9 parameters, it leaves sort, limit, offset, league, and priced_only to be inferred from names and defaults.

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 opening states a specific verb and resource: 'List what is actually in your stash: every item, with quantities.' This clearly distinguishes it from priced-only, history, or search-oriented sibling 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?

The description gives clear usage context: it reads the latest snapshot, aggregates stacks by default, and includes unpriced items so the result is a real inventory. It does not explicitly name alternatives such as search_items or get_stash_value, so it stops short of full when/not guidance.

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

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

No annotations are provided, so the description carries the behavioral burden. 'Show' conveys a read-only, non-mutating operationabb, and the listed fields communicate the substance of what the agent will receive. More detail on staleness or data source would be nice, but the description is sufficient for a simple read-only 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?

A single, front-loaded sentence communicates the operation and the three key output facets with no filler. Every element of the description earns its place.

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

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

For a zero-parameter list operation with an output schema present, this description is complete. It tells the agent what the tool does and what aspects of the watchlists will be shown, so no additional context is needed for reliable selection and 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 has zero parameters, which receives a baseline of 4. The description adds relevant semantic color by explaining what the returned watchlist data will contain, even though no parameter documentation is needed.

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 ('Show') and identifies the exact resource ('configured watchlists'), then adds the meaningful output dimensions: scan targets, frequency, and priority. This clearly distinguishes it from sibling tools that operate on other entities like market status, prices, or stash items.

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 makes the selection context clear: use this tool when you need to see configured watchlists and their scanning behavior. It does not name alternative tools, but with zero parameters and no sibling tool covering watchlists, explicit disambiguation is not necessary.

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. 'Report' clearly implies a non-mutating status read, and the description adds interpretive guidance about interpreting empty history. It does not state side effects or access prerequisites, but for a status tool with zero params the key behavioral trait is disclosed.

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 sentences, first gives the core purpose, second gives high-value usage guidance. No filler or repetition.

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

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

For a zero-argument status tool with an output schema present, the description covers what it reports and when to call it. It does not explain how to interpret coverage or budget values, but the output schema likely covers that; it is sufficiently 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?

There are no parameters, so the schema provides complete coverage. The description need not add parameter details; the baseline of 4 applies.

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

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

The description states a clear verb ('Report') and a specific resource ('collector health, database coverage and remaining rate budget'). This unambiguously identifies what the tool does and separates it from the market-data siblings.

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

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

The description gives an explicit when-to-use instruction: check this before concluding missing data means a missing market, with the reasoning that an empty history often indicates a stopped collector. It doesn't name sibling alternatives, but the diagnostic use case is clear and distinct from the data-fetching 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 of behavioral disclosure. It discloses that it cross-checks live asks against history, flags outliers, returns a whisper, and does not contact anyone. This is useful but does not describe side effects, output format, or any other behavioral nuances. The transparency is adequate but not comprehensive.

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 concise, with the primary purpose front-loaded in the first sentence. The second sentence adds relevant cross-checking and non-contact behavior. It is structured well and avoids unnecessary detail, though it could separate behavioral notes more clearly.

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 4 undocumented parameters, no annotations, and an output schema (not visible), the description is incomplete. It does not explain how to fill parameters, what 'best current listing' means, or what the returned whisper contains. An agent would struggle to call this correctly without additional information.

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

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

The input schema has zero description coverage for its 4 parameters (name, league, item_key, max_price), and the description does not explain or define any of them. It mentions 'item' and 'listing' but never maps these to parameters, leaving the agent without any guidance on what values to provide. This is a critical 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?

The description clearly states the tool's purpose: pick the best current listing and return a ready whisper. It also mentions cross-checking against history and that it does not contact anyone, which distinguishes it from potential siblings. However, it doesn't explicitly name alternative tools or contrast with them, so it's not fully differentiating.

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

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

The description implies usage ('before you commit', 'for a human to send') but never explicitly states when to use this tool versus alternatives like find_listings or find_arbitrage. No exclusions or prerequisites are provided, leaving the agent to infer the appropriate context.

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 fully discloses behavior: it bypasses the CDN cache, hits poe.ninja origin, does not touch GGG's trade API, and thus cannot affect the player's in-game trade rate budget. This is exactly the kind of context an agent needs for a mutating-like operation.

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

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

Three short paragraphs, each adding value: core purpose, technical nuance with usage conditions, and safety/caveat. Front-loaded with the main action, no redundant phrasing.

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?

Behavioral context is thorough, but the league parameter is completely undocumented, which is a significant omission for a tool that likely needs to know which league's prices to refresh. The output schema exists, so return format is not needed, but parameter documentation is essential.

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 has one optional parameter 'league' with 0% description coverage, and the description never mentions it. The agent is left to guess what league values are acceptable or whether it's required for the refresh. This is a clear 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?

The description clearly states it fetches currency prices from poe.ninja immediately, bypassing the schedule. It distinguishes itself from the hourly sweep and implies it's a refresh operation, differentiating it from sibling tools like get_price or get_movers which fetch or analyze data rather than force-refreshing.

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

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

Explicitly states when to call: when stale:true appears or after sleep/offline. Also warns that a forced refetch may not yield different data, setting expectations. It doesn't name alternatives but the contrast with the hourly sweep implies when not to use it.

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

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

No annotations are present, so the description carries the behavioral burden. It usefully discloses that the operation is a lookup and that returned keys are stable, which is non-obvious. It does not explain matching semantics, filtering behavior, or side effects, leaving some behavior implicit.

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 sentences, with the first one front-loading the core action and the second adding valuable context about stable keys. There is no filler or duplication 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?

The description clearly positions the tool as the first-step resolver for item names and explains that other tools consume its returned keys. However, with four undocumented optional parameters and no annotations, an agent still has to infer how to use kind, limit, and watchlist. The output schema helps with return shape, so the definition is adequate but not 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 0%, and the description only elaborates the 'by name' aspect, which maps to query. No explanation is given for kind, limit, or watchlist, and the enum values are left to domain knowledge. This is the biggest gap in the definition.

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

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

The description opens with a specific verb-resource pair: 'Find tracked items by name' and adds the key outcome, 'returning the item keys other tools take.' The stable-key framing distinguishes it from price, listing, and watchlist sibling tools, making its role unmistakable.

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

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

The phrase 'Resolve a user's wording to a key here first' is an explicit when-to-use instruction: it is the resolution step before other tools. It does not explicitly state when not to use it or name a competing alternative, but the precedence is clear from sibling context.

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