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

Annotations already declare read-only, idempotent, non-destructive, open-world behavior, so safety is covered. The description adds genuine behavior beyond that: results are ranked with a practical recommendation plus its reason, and skill checks are run against the account. It does not explain pagination behavior despite the cursor parameter.

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 trigger condition first and the output behavior second. No redundant restatement of the title, though the source enumeration is fairly dense.

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 six optional parameters and no output schema, the description usefully explains what a result looks like (per-item recommendation and reason) and how personalization works. It omits any mention of cursor-driven pagination for long lists and of how items vs. quest inputs differ in output volume, leaving small 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 100%, so every parameter (including depth, cursor, and player) is already documented in the schema. The description only adds the ironman/GE exclusion and account-skill-check concept, which map loosely onto the ironman and player fields. Baseline 3 applies when the schema carries the load.

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 (find) and resource (item sources) and enumerates the source classes it aggregates: shops, ground spawns, drops, recipes, and GE. This lets an agent distinguish it from the narrower siblings get_shop, get_drops, and find_recipes, which each cover only one of those classes.

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 the triggering condition: 'Use when the player needs to get items, or every item for a quest,' including the quest-wide planning case. It gives clear context but names no alternative tool or exclusion (e.g., a note to use get_price for market values), so it stops short of full when/when-not routing.

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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is settled. The description adds genuinely new behavioral context: results default to the player's levels unless maxLevel is supplied, a filtering behavior not captured anywhere in 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, front-loaded with the use cases and ending with the one caveat that matters. The first sentence is a densely packed list but every element earns its place, and there is no filler.

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

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

For a read-only search tool with a fully documented schema and existing output-free contract, the description covers purpose, use cases, and the key filtering default. It stops short of noting pagination via cursor or explicitly setting its boundary against closely related recipe/item 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 description coverage is 100%, so the baseline is 3, but the description goes slightly beyond by explaining the behavioral consequence of omitting maxLevel (results filtered to the player's levels). It does not mention the cursor-based pagination or the player/product/material selectors explicitly.

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 frames the tool by three concrete use cases (how to make an item, what an item is used in, what a skill can make) and names the data returned (levels, XP, materials, tools, facilities). It is clear about what it does, though it never explicitly differentiates itself from overlapping siblings like find_item_sources or get_item.

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

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

It states when to reach for the tool via three explicit scenarios, which is stronger than mere implied usage. It stops short of naming alternatives or when-not-to-use conditions, so an agent still has to infer the boundary with find_item_sources.

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, and destructiveHint=false, so the safety profile is covered. The description adds value by disclosing what the call returns—name, mode, and origin ('where they came from')—which is meaningful since there is no output schema. It doesn't discuss errors or the case where no account is saved.

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 no waste, and the usage trigger is front-loaded ahead of the return description. Well-sized for a zero-parameter read tool, though slightly terse.

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 carries the return-value burden and does so adequately by naming the returned fields. The safety profile is handled by annotations. It could note behavior when no account is saved, but for this simple lookup it is largely complete.

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

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

The tool takes zero parameters and the schema is empty, so the baseline is 4. There is nothing for the description to clarify regarding 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?

The description states a specific verb and resource (returns the saved account) and enumerates the returned fields: saved name, mode, and provenance. An agent knows exactly what this tool yields. It does not explicitly differentiate from the sibling set_account, though the read/lookup framing makes the distinction reasonably clear.

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 an explicit trigger condition: 'Use when asked which account is saved.' That is clear when-to-use guidance. It stops short of naming alternatives or exclusions (e.g., contrasting with set_account), so it falls just below the top tier.

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 covered. The description usefully adds the data source (WikiSync) and the return content (points per task, done/not done), but omits any auth/account prerequisite even though results depend on a saved or named player.

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 no filler; the usage cue is front-loaded and the return-value summary follows. Efficient, though slightly terse on grammar ('done or not done').

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, idempotent, fully-schematized tool with no output schema, the description covers purpose and return shape well. It falls short only on the account/player prerequisite and paging behavior via cursor.

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 tier, cursor, player, and monster are already fully documented with patterns and an enum. The description only gestures at 'monster or tier' and adds nothing about the cursor-based paging or the player override. Baseline 3 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 and resource ('combat achievement tasks') and adds scope ('for a monster or tier'), which lets an agent distinguish it from siblings like get_diary, get_slayer_tasks, and get_quest. It also previews the payload, but does not explicitly name a sibling it is not.

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 for combat achievement tasks for a monster or tier' gives an implied usage context and the two selectable dimensions, but names no alternative tool and gives no when-not-to-use condition. Adequate but leaves the routing decision partly to inference.

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

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

Annotations already establish readOnly/idempotent/non-destructive safety, so the description is free to spend its words elsewhere — and it does, disclosing the response behavior: a tier-by-tier ✓/✗/? requirement summary, and the deeper task/reward listing that appears only when a single tier is chosen. That conditional-detail behavior is genuinely useful and not derivable from the annotations.

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

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

A single dense sentence front-loaded with the usage cue, with no filler. The interleaved ✓/✗/? notation and clause stacking make it slightly harder to parse than it needs to be, but nothing is wasted.

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

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

With no output schema, the description carries the burden of explaining returns and does so for both modes. Minor gaps remain: no mention of pagination via cursor or of the 'player' override, but the core unknowns an agent needs are 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?

Schema coverage is 100%, so the baseline is 3, but the description adds real semantics for the optional 'tier' parameter — selecting one tier unlocks the per-task completion and rewards view — which the schema's bare enum label does not convey. It is silent on cursor/player, so it is not a 5.

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 ('achievement diary region') and describes the exact output: per-tier requirements checked with ✓/✗/? and, for a single tier, tasks with WikiSync completion plus rewards. It is distinguishable from sibling get_quest/get_combat_achievements by the diary-region scope, though it never names those siblings directly.

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 opening 'Use for an achievement diary region' gives a positive trigger, but there is no when-not guidance, no mention of alternatives such as get_combat_achievements or get_quest, and no note that omitting tier changes the response shape. Usage is implied rather than instructed.

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). The description adds valuable output context—what data is returned—which is especially useful since there is no output schema. It omits any mention of pagination or cursor behavior, but the schema documents the cursor parameter.

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

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

A single, front-loaded sentence with no filler. Every item in the list earns its place by clarifying the scope of returned data.

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 absence of an output schema, the description does a good job of specifying the return contents. Combined with annotations covering safety and the schema documenting parameters, it is nearly complete, though a brief note about pagination or cursor usage would make it fully self-contained.

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

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

Schema description coverage is 100%, so the schema already fully documents all three parameters. The description adds no additional meaning or format details for monster, version, or cursor beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description states a specific resource (monster drops) and enumerates the exact data returned (quantities, rarities, live GE prices, shared tables, expected gp per kill). It clearly distinguishes this from a generic monster stats tool, but it never names any sibling tool to explicitly differentiate, so it stops 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?

The phrase 'Use for...' provides implied usage context, but there is no explicit guidance on when to choose this tool over get_monster, find_item_sources, or other siblings. No when-not conditions or alternatives are given.

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 covered. The description adds that all versions are returned and that GE price is included only when tradeable, which is useful. It says nothing about the cursor/pagination behavior for long lists, so it adds only moderate value beyond annotations.

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 dense, front-loaded sentence with no filler; each enumerated clause describes actual returned data. It is slightly list-heavy but nothing is wasted.

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

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

With no output schema, the description carries the return-value burden well by naming the fields returned. The main gap is silent pagination behavior despite a cursor parameter being present, which matters for an item with many versions.

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

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

Schema description coverage is 100%, so both parameters ('item' name or id, and 'cursor') are already documented in the schema. The description mirrors 'by name or id' but adds no new meaning, and the cursor continuation parameter is unaddressed. 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?

The description gives a specific verb+resource (facts about an item) and enumerates the returned fields, including live GE price when tradeable. It is clear what the tool does, but it never names sibling tools like get_price or find_item_sources, so the agent must infer the boundary itself.

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 for facts about an item by name or id' implies the use case, and the mention of GE price hints at overlap with get_price. However, there is no explicit when-to-use vs alternatives guidance and no exclusions, leaving routing 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 readOnly/idempotent/openWorld/destructive, so the description's job is lighter. It adds real behavioral context beyond them: results are filtered by category/members/recurring/min gp/hr and 'checked against the account', implying personalization to the saved or named player, plus cursor-based continuation of long lists.

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

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

Front-loaded with the triggering condition and then the capability; two sentences with no filler. Slightly dense with filter enumeration, but each element 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 7-param, all-optional list tool with no output schema, the description covers the trigger, the filtering surface, pagination, and account-checking behavior. It does not describe the response fields, though the account-check behavior arguably needs one clarifying clause.

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 filter params and pagination (limit, cursor) are already documented in the schema; baseline 3 applies. The description adds only the output ordering signal ('by gp/hr'), not syntax or format 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 wiki's money-making guides by gp/hr'. The scope (guides, ranked by gp/hr, filterable) is precise enough to distinguish it from siblings like get_price or plan_skill.

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

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

Explicit trigger: 'Use when the player asks how to make money.' That is a clear when-to-use condition, but no when-not or named alternative tool is given for adjacent needs (e.g. single-item profitability via get_price).

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 covered. The description adds that results include map links and that the tool 'lists its other versions', which is real behavioral context tying the `version` parameter to a multi-variant result. It does not, however, mention pagination or rate/query limits, so it goes only modestly beyond the annotations.

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

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

A single front-loaded sentence with no filler; the trigger ('Use for...') comes first and the payload list follows. The field enumeration is long but each item earns its place by telling the agent what it gets back. Minor cost: the dense comma list is less scannable than split sentences.

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

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

There is no output schema, so the description carries the burden of describing the return payload — and it does so thoroughly by enumerating stats, weaknesses, slayer info, locations and versions. Missing pieces are pagination behavior (the schema's `cursor` hints at long lists) and any note on ambiguous monster names, but overall it is sufficient to 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% — `monster`, `version` and `cursor` are all documented in the schema itself. The description reinforces that a monster can have multiple versions and that other versions are listed, which helps an agent understand the `version` parameter's role, but it adds no format or syntax detail beyond the schema. 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?

The description names the resource (a monster) and enumerates the specific facts returned — combat level, hitpoints, max hit, attack styles, weaknesses, immunities, slayer info, locations. That is far more specific than a tautology and lets an agent distinguish it from get_drops or get_slayer_tasks at a glance, but it never states a clean verb ('retrieve/fetch') and the slayer mention slightly blurs the line with get_slayer_tasks.

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 for a monster's stats' gives an implied trigger condition but no explicit when-not guidance and no named alternative. An agent can infer it should call this for monster lookups rather than get_item or get_quest, but routing decisions (e.g. use get_drops instead when you need drop tables) are 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, openWorld and non-destructive. The description adds genuinely new behavior: it returns cleaned text rather than raw markup, and long pages continue via a cursor, which is non-obvious and useful for an agent deciding how to consume 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?

One compact sentence with zero filler; purpose comes first, then scoping, then the continuation caveat. 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?

For a 3-parameter read tool with annotations covering the safety profile and no output schema, the description covers purpose, scoping and pagination adequately. It could say slightly more about how a continued response relates to the original request, but nothing essential 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 title, section and cursor are all documented in the schema, including that section can be a heading or index from get_page_sections. The description largely restates this, 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 (read) and resource (OSRS Wiki article) plus the output form (clean text) and scoping option (whole page or one section by heading/index). This is clearly distinct from siblings like get_page_sections and search_wiki.

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?

Says to use it to read a wiki article and gestures at sections and continuation, but never states when to prefer search_wiki or get_page_sections instead, nor any preconditions. Usage is implied rather than routed.

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, covering the safety profile. The description adds only the procedural hint about ordering relative to get_page; it says nothing about pagination behavior despite the cursor parameter, or about the size/shape of a section list.

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

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

A single short sentence with zero filler, front-loading the action and the sequencing relative to get_page. Every word 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 simple read-only listing tool with full schema coverage, complete annotations and no output schema, the definition covers what an agent needs to select and call it. The only gap is a brief note on pagination/large pages, which the cursor parameter hints at but the description never mentions.

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 'title' and 'cursor' are already documented in the schema, including that cursor continues a long list. The description adds no extra meaning beyond that, 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?

The description states a specific verb (list), resource (an OSRS Wiki page's sections), and names the related sibling get_page, so an agent can tell it apart from the page-reading tool. It stops short of a fully self-contained scope statement but the intent 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?

It specifies a workflow condition: use this before reading a page with get_page. That gives clear context for selection, but it offers no exclusions or guidance on when listing sections is unnecessary (e.g. when the page is known to be small).

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, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context by naming WikiSync as an external data source and stating the saved-account fallback, but says nothing about pagination limits or behavior when the player has no WikiSync data.

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

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

Two short sentences with zero filler; the data categories are front-loaded and the default-account behavior is appended as a compact qualifier.

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 usefully enumerates the returned progress categories and the external source, and annotations cover the read-only safety profile. It omits any indication of result shape beyond the cursor hint in the schema and of failure modes (unknown player, no WikiSync sync).

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 meaning the schema does not: the name parameter is optional and falls back to the saved account. It does not elaborate on mode, cursor or questState, which the schema already documents.

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: a player's quest, achievement diary, collection log and combat achievement progress, sourced from WikiSync. That enumerations makes it distinguishable from siblings such as get_account or lookup_player. It stops short of naming which sibling to prefer, so it is clear but not fully differentiated.

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 for ..." frames the use case but offers no when-not guidance and names no alternative (e.g. lookup_player for basic account info). The note that it "Defaults to the saved account" is the only contextual routing hint, and it is more about parameter behavior than tool selection.

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 the safe read-only, idempotent, open-world profile, so the description's added value is the return payload: instant buy/sell prices, their age, margin after GE tax, averages, volumes, buy limit, alch values and batch totals. This is meaningful behavioral context not covered by structured fields, though cursor/pagination mechanics are left to 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?

Two tightly packed sentences with the usage directive front-loaded and the return inventory following; no filler or redundancy.

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

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

With no output schema, the description does the work of enumerating return fields, which is essential and largely complete. A brief note on the cursor-based continuation it returns would close the only remaining gap.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds value beyond the schema's bare 'Item names or ids' by confirming fuzzy-name matching works with a concrete example, and it notes multi-item batching.

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 — retrieving Grand Exchange prices for one or more items — and clarifies accepted input forms (name, fuzzy name, id). It does not explicitly differentiate from the sibling get_price_history, which is why it stops 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?

The leading 'Use for...' clause gives clear usage context and supplies a concrete fuzzy-name example ('d scim'), making invocation conditions obvious. It stops short of naming alternatives or when-not conditions (e.g. vs get_price_history).

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, non-destructive, open-world). The description goes beyond them by disclosing the return payload: low, high, average, % change over the window, and the series. It omits pagination behavior despite a cursor parameter existing, but with no output schema this return-shape disclosure is meaningful added context.

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 no filler, and the usage cue is front-loaded before the return details. The first sentence's phrasing ('Use for how...') is slightly awkward but costs nothing in ambiguity.

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 four-parameter read tool with no output schema, the description covers purpose and the returned summary fields, which is most of what an agent needs. The remaining gaps are the cursor continuation behavior and the relationship to get_price, neither of which is addressed.

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 item, cursor, points and timestep are already documented in the schema. The description adds only 'over the window' and 'the series', which gesture at the points/timestep semantics without specifying units or pagination, so the baseline 3 for a fully documented schema is appropriate.

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

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

The description states a specific verb-like use ('how an item's Grand Exchange price has moved') and the resource (price history), which clearly separates it from a generic lookup. It does not, however, explicitly name or distinguish the very close sibling get_price, so differentiation remains implicit 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?

'Use for how an item's Grand Exchange price has moved' is a clear when-to-use cue, so usage is implied but not spelled out. No alternative tool is named (get_price is the obvious candidate for current price), and there are no exclusions or prerequisite conditions.

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, destructiveHint=false, openWorldHint), so the bar is lower; the description nonetheless adds real value by disclosing the shape of the returned readiness data, including the ✓/✗/? prerequisite markers. It does not describe pagination behavior (cursor is only documented in the schema) or output ordering, but that is a minor gap against strong annotation coverage.

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

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

Two sentences, front-loaded with the usage trigger, then the return contents. The long enumeration of fields is dense but every item earns its place by describing output with no output schema present. 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?

With no output schema, the description carries the burden of describing returns and does so thoroughly, and annotations cover safety. For a three-parameter read tool the definition is close to complete; the one meaningful omission is differentiating it from the sibling quest tools (get_quest_guide, suggest_quests, plan_quest_trips).

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 name, cursor and player, including the player pattern. The description adds nothing about parameter semantics (e.g., that cursor continues a long prerequisite list), 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 resource (quest) and enumerates the substantive content it returns: prerequisite tree with ✓/✗/? marks, skill requirements, items, enemies, start point, difficulty, length, rewards and ironman notes. That is far more than a tautology. However, with near-namesake siblings like get_quest_guide, suggest_quests and plan_quest_trips present, it never draws the boundary between them.

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

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

"Use when the player asks about a quest or whether they can do it" gives a clear triggering context, and the readiness framing hints it is the requirements-check tool rather than a guide or suggestion tool. No explicit exclusions or named alternatives are provided, so an agent comparing it to get_quest_guide must still infer the split.

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?

The annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), so the lower bar applies. The description still adds behavior beyond them: results are section-scoped, sections are addressable by name or number, long content is paginated via a cursor, and output includes map links.

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

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

A single front-loaded sentence with zero filler; every clause (source, section granularity, map links, cursor pagination) carries distinct information and nothing is repeated.

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 does the work of characterizing the return: ordered sections, map links, and cursor-based continuation. The only real gap is how a caller discovers valid section names or numbers before the first call.

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 parameters are already documented, and the baseline of 3 applies. The description reinforces 'section by name or number' and cursor continuation but adds no new syntax, defaults, or edge cases beyond the schema's own text.

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 ('step-by-step quest instructions') and names the content source (Quest Helper) plus the delivered artifact (map links), so the agent knows exactly what it gets. It does not distinguish itself from the closely related sibling get_quest, so the agent must infer which one returns the overview versus the walkthrough.

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 for...' implies the guiding condition and the phrase 'one section at a time by name or number' hints at the calling pattern, but there is no explicit when-not clause and no mention of get_quest, plan_quest_trips, or suggest_quests as the alternative for summaries or trip planning.

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. The description's only added behavioral value is disclosing data freshness details (restock time) and that results are per-item; it says nothing about pagination limits or error behavior for an unknown shop 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?

A single front-loaded sentence with zero filler; the trigger phrase comes first and the returned fields are listed compactly. Every clause 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?

With no output schema, the description usefully compensates by enumerating the returned fields, and annotations cover safety. It falls just short of complete because pagination behavior (cursor-driven long lists) and behavior on a nonexistent shop 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 description coverage is 100% and both parameters (name, cursor) are documented in the schema, so the baseline of 3 applies. The description adds no parameter-level detail such as name-matching rules (exact vs fuzzy) or what the cursor continuation returns.

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

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

The description states a specific resource and enumerates the exact payload (owner, location, item price, currency, stock, restock time), which clearly separates it from siblings like get_item or get_price. However it never names an alternative tool, so the differentiation is achieved by field listing rather than explicit contrast. It is clear but not sibling-routing.

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 for what a shop sells" gives an implied trigger condition, but there is no when-not guidance and no named alternative (e.g. get_item for a single item across shops, get_price for pricing only). An agent must infer the boundary itself.

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/non-destructive, so safety is covered. The description adds genuine extra context: results reflect the saved account unless a player filter is supplied ('only tasks it can be assigned are counted'), which is non-obvious conditional behavior beyond the annotations.

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 with no filler, front-loaded on the purpose and return contents. Well sized for a simple read tool, though it trades some completeness for brevity.

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, single-master query with no output schema, the description conveys what is returned (tasks with amounts, weights, chances) and the account-conditioning rule. An agent has enough to call it correctly; only explicit sibling routing 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%, with cursor, master, and player all documented in-schema, so the baseline is 3. The description's mention of account-vs-player filtering adds a little meaning but no parameter syntax or format 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?

The description names the specific resource (what a slayer master assigns) and even previews the return fields (amounts, weights, chances), so an agent knows what it gets. It doesn't explicitly differentiate from siblings, but no adjacent tool covers slayer assignment data, so the purpose reads clearly.

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 implies usage (query a master's assignable tasks) and explains the account-dependent behavior, but gives no explicit when-to-use vs when-not guidance and names no alternative tool. Adequate but leaves routing 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 readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: the lookup falls back to the saved account when no name is given, which materially affects invocation. It says nothing, though, about cursor-based pagination or failure 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 compact sentences, front-loaded with the use case and with the default-account fallback placed right after. No filler or 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?

For a read-only lookup with full schema coverage and no output schema, this covers purpose, returned data and the default-account behavior adequately. Minor gaps remain: it does not mention paging via cursor or how modes affect results.

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 name, mode (with enum) and cursor are all documented in the schema. The description's note about defaulting to the saved account lightly enriches the optional-name semantics, but adds nothing about mode or cursor beyond what the schema already states.

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

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

States a specific verb-and-resource (lookup a player's hiscores) and enumerates the returned data categories: skill levels, XP, ranks, boss kill counts, clue scrolls, combat level. It does not explicitly distinguish itself from the close sibling get_player_progress, but the scope is unambiguous on its own.

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 for a player's hiscores' implies the usage context, and 'Defaults to the saved account' clarifies behavior when no player is supplied. However, it names no alternatives (e.g. get_player_progress) and gives no when-not guidance, leaving the agent to infer selection.

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, non-destructive, openWorld), so the remaining burden is describing what the tool actually produces. The description does this: it discloses the inventory-fitting split and enumerates the categories returned (items per trip, later items, quest-obtained items, teleports).

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: the first front-loads the usage trigger, the second lists the outputs. No filler. It is compact and well-ordered, though the second sentence is a dense feature list rather than tightly prioritized 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?

There is no output schema, so the description must convey return content, and it does enumerate the result categories. For a read-only planning tool with fully documented parameters, this is nearly complete; only pagination/cursor behavior for long lists 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?

Schema description coverage is 100%, so name, cursor, player, and ironman are already documented in the schema. The description adds no parameter-level meaning beyond that, 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: it plans quest trips by splitting item needs into 28-slot-inventory-sized batches. The purpose is clear and distinguishable from the get_quest/get_quest_guide siblings, though it never names those siblings to sharpen the contrast.

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 when the player wants to know what to bring for a quest" gives a clear, explicit trigger for invoking the tool. It stops short of stating when NOT to use it or pointing to the guide/quest siblings for plain requirement lookups.

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 safety behavior is covered. The description usefully adds what content is produced (methods, materials, cost, quests), but omits pagination/continuation behavior even though a cursor parameter exists.

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 the usage trigger front-loaded before the output summary. The second sentence is a dense list but every element describes a distinct output, so it largely earns its space.

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 must convey return content, and it does so concretely. For a 7-parameter, read-only planner with full annotation coverage and full schema coverage, the main remaining gap is the cursor/continuation 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 skill, method, player, target, currentXp/currentLevel and cursor. The description gestures at a 'method' and level/XP targeting but adds no syntax, format, or fallback rules beyond the schema, so the baseline 3 applies.

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

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

The description states a specific verb (plan toward a level/XP goal) and enumerates what it returns: XP remaining, a method's actions/materials/cost, best methods at level, and XP-rewarding quests. That distinguishes it from lookup-style siblings like get_player_progress, though it never names a sibling 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?

The opening sentence gives an explicit trigger condition: 'Use when the player wants to reach a level or XP goal.' It does not state when not to use it or name alternatives (e.g. get_player_progress for raw progress), 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 cover the safety profile (readOnly, idempotent, openWorld, non-destructive), so the bar is lower. The description adds real behavioral value by disclosing the error/repair path: an unknown table or field returns the valid ones, which tells an agent how to recover without guessing.

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

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

Two sentences, purpose front-loaded followed by failure behavior, with no filler. The concrete bucket names make the abstract 'Bucket table' concept immediately usable.

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

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

For a 7-parameter read tool with no output schema, the description covers purpose, when-to-use, and error handling, and the schema carries parameter detail. It does not mention pagination/limit behavior in prose, though the cursor and limit parameters are documented in the schema, so the gap is minor.

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 all seven parameters are documented in the schema itself, including the where-tuple format and the cursor semantics. The description only alludes to select/where/ordering by name without adding syntax or format detail beyond the schema — the baseline 3 is appropriate.

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

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

States a specific verb and resource (query Bucket tables) and gives concrete table examples (combat_achievement, infobox_monster, dropsline). It also positions itself against the sibling set with 'structured wiki data no other tool covers', so an agent can distinguish it from get_monster, get_drops, search_wiki, etc.

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 for structured wiki data no other tool covers' gives a clear selection condition and implies an exclusion (use the specialized sibling when one exists). No specific alternative tool is named, so the routing is implied rather than explicit.

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 safety is covered. The description adds genuine value beyond that by disclosing the return shape (titles, URLs, short snippets), which matters because there is no output 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 short sentences, zero waste, with the usage rule front-loaded and the return shape second. 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 3-parameter search tool with no output schema, the description covers purpose, selection rule and return contents. It omits pagination behavior (the cursor parameter implies paging) and any hint about result quality, minor gaps given the rich 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 100% with descriptions for query, limit (default 10, max 50) and cursor. The description adds no syntax, format or semantics beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb+resource ('find OSRS Wiki pages') and explicitly positions itself as the catch-all ('anything no other tool covers'), which distinguishes it from the many specific siblings like get_item or get_quest. It stops short of naming any sibling directly, but the fallback framing is clear.

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

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

Gives an explicit selection rule: use this for anything no other tool covers, implying the specialized tools are preferred when they apply. It does not name a specific alternative or state a when-not condition, so it falls just short of a 5.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so safety and repeat-call behavior are covered. The description earns credit for adding the persistence side effect ('saves it so later answers are checked against that account'), which explains why the write matters beyond the annotation flags. It does not state overwrite/invalid-input 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 tight sentences with the triggering condition front-loaded and the consequence summarized in a short clause. 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 simple two-parameter setter with no output schema and full annotation coverage, the description supplies purpose, trigger, and effect. It leaves minor gaps around overwriting or invalid names, but nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100%: name is documented as 1-12 characters and mode enumerates all six values. The description adds the examples 'main, ironman and so on' for mode, but that duplicates the enum rather than extending it. Baseline 3 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?

The description gives a specific verb and resource (saves the player's OSRS name/account mode) and explains the downstream effect on later answers. It does not explicitly distinguish itself from close siblings like get_account or lookup_player, so it falls just short of the top band.

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 concrete trigger: 'Use when the player tells you their OSRS name or account mode'. This clearly implies the call is only needed at that moment. However, it names no alternatives or exclusions (e.g., vs. lookup_player), so it lacks the explicit when-not guidance of a 5.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds the return shape — "the solution and, for emote clues, the emotes, location and equipment with alternates" — which is genuinely useful given there is no output 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, zero preamble: the usage trigger leads and the return behavior follows. Every clause earns its place with no 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 single-parameter, annotation-covered, no-output-schema tool this is nearly complete: input variety and emote return values are described. It stops short of describing what "the solution" looks like for the anagram/cipher/cryptic cases, a minor omission.

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% for the single text parameter ("The clue text, as written on the scroll"), so the baseline is 3. The description goes further by naming the concrete clue formats expected (anagram, cipher, cryptic, emote), helping the agent recognize valid input beyond the generic schema text.

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 (solve) and resource (clue scroll) and enumerates the clue types handled (anagram, cipher, cryptic, emote). It is clear, though the purpose largely overlaps the name/title and no sibling tool competes for this job, so there is little differentiation to add.

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 when the player pastes Treasure Trails clue text..." gives an explicit, concrete trigger for invocation. There is no competing sibling to exclude, so no when-not or alternative routing is needed, but also none is offered.

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/openWorld, so safety is covered. The description adds genuine behavior beyond that: results follow the wiki's ordered progression and deliberately include blocked-quest entries with a single unmet requirement, which the agent could not infer from 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 filler, with the trigger condition front-loaded before the behavioral detail. 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?

For a read-only suggestion tool with no output schema and a fully documented 7-parameter schema, the description covers trigger, ordering, and inclusion logic adequately. It is slightly thin on how cursor-based continuation and the 'after' vs WikiSync distinction interact, but nothing essential 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 the baseline is 3. The mention of filtering by 'XP reward skill or unlock text' largely restates the rewardsSkill and unlocks parameters rather than adding syntax or semantics, so no upgrade is warranted.

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 (suggests) and resource (quests), and pins down scope: the wiki's optimal order, quests startable now plus those blocked by a single requirement. This clearly separates it from sibling get_quest (retrieval) and get_quest_guide, so an agent can pick it 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 opening clause 'Use when the player asks what quest to do next' is an explicit trigger condition, which is exactly the guidance an agent needs. It stops short of naming a sibling as an alternative or stating when not to use it, so it falls short of a 5.

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