RuneScape Wiki

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered structurally. The description adds little behaviorally beyond the '#' convention for numeric names (which the schema also states); it says nothing about result ordering, page size, or what happens past the last page.

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 earning its place: the core action first, the exclusion next, the edge-case convention last. 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?

For a simple read-only browse tool with full schema coverage and no output schema, the description covers purpose, disambiguation and the numeric-name edge case. The only real gap is how category IDs map to values, which a sibling tool covers.

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

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

Schema description coverage is 100%, so all three parameters (category, alpha, page) are already documented with ranges and defaults. The description only restates the category/letter axes and the '#' rule, adding no semantics beyond the schema; baseline 3 is appropriate.

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

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

States a specific verb and resource ('Browse the Grand Exchange catalogue') plus the two axes it operates on (category and starting letter). It explicitly contrasts itself with lookup_item, 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?

Explicitly says what this is NOT ('NOT a name search') and names the alternative tool for that case, which is strong routing guidance. It lacks guidance on pagination or on where to obtain valid category IDs, which the sibling get_all_categories presumably provides.

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

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), so the description's real contribution is the failure semantics: unresolved entries return error rows rather than failing the whole call. That is genuinely useful context an agent cannot derive from the annotations or schema.

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

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

Two sentences, no padding, with the batch scope and input contract front-loaded and the return-shape/failure behavior placed after. 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?

An output schema exists, so return fields needn't be documented, yet the description still summarizes the row shape and resolution-failure behavior. Combined with annotations covering the read-only/idempotent profile, nothing needed to call this 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% — the 1-10 bounds, uniqueness, and 'names or itemIds, not both' constraint are all already documented in the schema. The description only restates the either/or rule, adding no format, casing, or resolution-order detail beyond it, 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 ('Compare latest Grand Exchange prices') plus a scope qualifier ('up to 10 items in one call') that distinguishes it from the single-item siblings like get_item_price and lookup_item. It never names a sibling explicitly, so the differentiation is inferable 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 description gives the input contract ('Provide either names or itemIds') but no when-to-use/when-not guidance relative to get_item_price, lookup_item, or estimate_flip. The batch-comparison use case is implied by 'up to 10 items in one call' but never framed as the reason to pick this 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?

Beyond the readOnly/idempotent annotations, the description discloses real behavioral limits: guide prices lag the live market, buy limits and fill times are unmodelled, and results will differ from actual profit. That is meaningful caveat context, though it says nothing about precision, time windows, or data freshness beyond the lag warning.

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, front-loaded with what the tool computes and immediately followed by the accuracy caveat and the key optional-parameter usage. No filler.

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

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

An output schema exists so return values need no explanation, annotations cover the safety profile, and the description supplies the estimate-only caveat that annotations cannot express. Nothing needed 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 baseline is 3, but the description adds the rationale for buyPrice/sellPrice ('to model your own offers') and restates the itemId-or-name selector, clarifying intent rather than just repeating types.

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 precise verb ('Estimate') plus the exact resource and domain ('Grand Exchange flip profit after the 2% RS3 sales tax'), and names both input modes (itemId or name). This is clearly separable from siblings like get_item_price or compare_items, which do not model flip profit.

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?

Tells the agent how to use it ('Pass buyPrice/sellPrice to model your own offers') and implicitly when it applies versus plain price lookups. It lacks an explicit when-not statement (e.g. use get_item_price for raw prices), so it falls 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.

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is fully covered. The description adds one piece of behavioral context the annotations don't: the result set is a fixed, bounded range (0-43). It does not mention ordering, output shape, or caching.

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

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

One sentence, front-loaded with the verb and resource, and it includes the one detail (the 0-43 range) that is actually informative. Nothing to trim.

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-only lookup with full annotation coverage, the description suffices: it says what is returned (IDs and names) and the extent of the enumeration. Only the relationship to category-consuming siblings is left implicit.

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 schema carries nothing to clarify; baseline 4 applies. The description correctly signals no filtering or input is expected.

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

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

States a specific verb (List) and resource (RS3 Grand Exchange category IDs and names) with the full scope of the result set (0-43). An agent can tell this is a static reference enumeration distinct from lookup_item or browse_items 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?

No guidance on when to call this versus get_category_info, browse_items, or other siblings. The agent must infer that this is the discovery/enumeration step preceding a category-scoped call, but the description never says so.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered structurally. The description adds no behavioral context beyond that — no return shape, no mention of what a 'letter count' result contains. Adequate but not additive.

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, front-loaded with the action and immediately followed by the prerequisite pointer. No filler, no restatement of the tool name or title.

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

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

For a single-parameter, no-output-schema read tool with full annotation coverage, the description is minimally sufficient. The gap is that 'letter counts' is never unpacked, so an agent cannot anticipate the response content, though it can call 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 description coverage is 100% — the single 'category' parameter is documented with its valid range (0-43) and bound by minimum/maximum. The description contributes only the cross-reference to get_all_categories for obtaining valid IDs, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Get letter counts for a Grand Exchange category'), which is enough to distinguish it from siblings like get_ge_info or lookup_item. However, 'letter counts' is an unusual, unexplained concept, leaving some ambiguity about what is actually returned.

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

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

Explicitly routes the agent to the sibling get_all_categories when it needs valid category IDs, which resolves the main pre-call prerequisite. It does not, however, say when this tool should be preferred over other Grand Exchange siblings for other purposes.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description usefully adds that it is a public Jagex endpoint requiring no auth and that it takes no arguments — context the annotations do not supply. It stops short of describing response shape, but with an output schema present that is not required.

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 resource, then the exclusion, then the invocation constraints. No filler; every sentence carries new 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?

An output schema exists, so return values need not be explained, and annotations carry the safety profile. The description covers purpose, sibling routing, argument count and auth requirements — everything needed to invoke this metadata endpoint 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?

Zero parameters, so the baseline is 4. The description confirms 'Takes no arguments', which is consistent with the empty, additionalProperties:false schema and prevents an agent from inventing inputs.

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 ('Read Grand Exchange database metadata') and even names a concrete field ('lastConfigUpdateRuneday'). It explicitly distinguishes itself from the item-price tools, so an agent can tell it apart from get_item_price and lookup_item 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 when-not guidance ('This is not item prices') paired with named alternatives ('use get_item_price or lookup_item for those'). Nothing about tool selection 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?

Annotations already declare readOnly, idempotent, non-destructive, and open-world, so "no side effects" is largely redundant. The description does add value annotations do not carry: no authentication is required, and the returned series is a bounded ~180-day daily window. It stops short of noting rate limits or whether very old data is truncated.

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, then the constraint, then the alternative. Every sentence carries distinct information with no filler.

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

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

An output schema exists, so return values need not be described. Between the description (scope, auth, mutual-exclusivity, alternative routing) and the annotations (safety profile), an agent has everything required to call this 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 baseline would be 3, but the description adds the mutual-exclusivity rule ("Pass exactly one of itemId or name") that the schema's additionalProperties:false does not actually express. Neither parameter is declared required in the schema, so this constraint is genuinely additive.

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 ("Read ... daily price series for one item") plus the scope ("about the last 180 days"), which is far more precise than the bare title. It is readily distinguishable from siblings like get_item_price (current price) and summarize_price_history (aggregates).

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

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

Explicitly routes the agent away from this tool when aggregates are wanted: "Use summarize_price_history for min, max, and average instead of the raw series." However, it does not clarify how it differs from the closer siblings get_item_price and lookup_item, so guidance is clear but incomplete.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered structurally. The description adds the content shape of the result (price, trends, examine text) but says nothing beyond annotations about rate limits, caching/freshness of the price data, or how open-world lookups behave on unknown items.

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, zero filler, with the action and the returned data front-loaded and the argument rule second. Nothing is restated from the title or annotations.

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?

An output schema exists, so return values need not be spelled out, and annotations carry the safety semantics; what remains is adequately covered by the description plus schema. The only gap is the absence of guidance on which sibling to pick for graph/history/compare needs, which slightly limits routing confidence for a tool that sits among several similar price tools.

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 a constraint the schema cannot express: mutual exclusivity ('exactly one of' itemId or name), since the schema has no oneOf and zero required parameters. The sibling routing hint (prefer lookup_item for fuzzy search) also lives in the param description and helps disambiguate the two selectors.

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 a specific verb (Get) and resource (current Grand Exchange price for an item) and enumerates the returned data (price, trends, examine text), which is more precise than a tautology. It does not, however, distinguish itself from siblings such as get_item_graph, compare_items, or lookup_item, so an agent can't tell from the description alone when this is the right retrieval 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 one concrete usage constraint — 'Pass exactly one of itemId or name' — which is real invocation guidance. But it offers no when-to-use/when-not guidance relative to the surrounding item/price tools (lookup_item, get_item_graph, compare_items), leaving selection 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?

Annotations already cover safety (readOnly, idempotent, non-destructive), so the bar is lower; the description adds a genuinely useful failure mode beyond them — ironman/hardcore return HTTP 404 and the tool surfaces that rather than silently falling back to normal data. It does not disclose rate limits or response shape, but the silent-fallback warning is the key behavioral fact.

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

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

Two tight sentences: the core purpose first, then the mode-specific caveat. No filler, and the most important constraint (broken modes) is not 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?

With an output schema present, return values need not be described, and the description covers the operational caveats an agent needs before calling. Nothing material is missing for a two-parameter read-only lookup.

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% (baseline 3), and the description goes beyond the enum labels by explaining what each mode means operationally (index_lite vs. alternate endpoints). That is real added meaning for the gameMode parameter rather than a restatement of the schema.

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

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

States a specific verb and resource ('Get RS3 hiscores for a player'), which is immediately distinguishable from the item/GE/wiki-oriented siblings. An agent knows exactly what domain this tool covers 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 clear conditional guidance per game mode: normal works, ironman/hardcore hit currently-broken endpoints. It stops short of naming an alternative tool or an explicit 'use this instead of X' rule, but the mode-level context is enough to choose 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?

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds two genuinely useful behavioral facts beyond that: redirects are followed and the return is plain text rather than wikitext/HTML.

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 terse sentences, zero filler, with the core action front-loaded before the fallback advice. 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 single-parameter read tool with full annotation coverage and no output schema, the description supplies enough: action, redirect behavior, and return format. An agent can call it correctly without further 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?

Schema coverage is 100% with a single, fully described parameter, so the baseline is 3. The description reinforces exact-title preference but adds little syntax or format detail beyond what the schema already states about titles and redirects.

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: fetching plain-text content of a RuneScape Wiki page. The plain-text qualifier and 'follows redirects' distinguish it from sibling data tools like lookup_item and get_category_info.

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 routing guidance: prefer exact titles, fall back to lookup_item or wiki search when unsure. This names alternatives and a triggering condition, though 'wiki search' is not an actual listed sibling, leaving slight ambiguity about the exact fallback 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?

Adds search strategy beyond annotations: exact name match first, then wiki opensearch fallback. Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior. It does not mention rate limits or failure modes, but provides useful beyond-schema 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?

Two sentences with zero wasted words. The core action is front-loaded, followed immediately by the search strategy and routing 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?

For a simple lookup tool with rich annotations, full schema coverage, and an output schema, the description supplies the necessary purpose, search behavior, and sibling routing. No critical agent-facing context is missing.

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

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

Schema description coverage is 100%, so both query and limit are already well documented in the schema. The description adds no parameter syntax, default, or constraint beyond what the schema provides. Baseline 3 is appropriate when 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: resolve an item name to Grand Exchange ID and latest price. It explicitly distinguishes itself from get_item_price by routing name-only lookups here. An agent can identify the tool's purpose 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?

Gives an explicit routing rule: prefer this before get_item_price when you only know the name. This names an alternative and a condition, though it does not cover when-not cases or other siblings like browse_items. Clear context without full exclusion 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered without the description. The description adds the input rule that exactly one of itemId/name must be passed and the window bounds, but says nothing about pagination, rate limits, or data staleness that would go beyond the structured fields.

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

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

Two sentences, both front-loaded with the most important information: what is computed first, then the input constraint and the sibling escape hatch. No filler or redundant restatement of the title.

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

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

An output schema exists, so return-value detail need not be repeated, and the annotations carry the safety profile. Between the description's metric list, the one-of input rule, the window bounds, and the sibling pointer, an agent has everything needed to invoke this correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description nonetheless adds value the schema leaves ambiguous: 'Pass exactly one of itemId or name' resolves whether both may be supplied (the schema only says 'provide itemId or name'), and it restates the days range/default for quick reference.

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 (summarize) and resource (one item's recent Grand Exchange prices) and enumerates the computed metrics (min, max, average, change, average daily volume). It also names the sibling get_item_graph and the condition that distinguishes them (full daily series), so an agent can route 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 one explicit alternative and when to prefer it: 'Use get_item_graph for the full daily series.' That is real routing guidance, but it does not address the other plausible siblings (get_item_price, compare_items) or state when a summary is preferable to a raw lookup beyond the series-vs-summary contrast.

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