Everloot: WoW Forever data

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

Goes well beyond the annotations: it discloses that further-reading links are search URLs and nothing is fetched from them, and that when not connected the observed layer is unrecorded rather than empty. These are non-obvious behaviors an agent would otherwise get wrong, though it does not mention rate limits or result ordering.

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

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

Front-loads what the tool returns and packs source-layer detail efficiently. The sentences are long but each carries distinct information; the connectivity caveat earns its place despite adding length.

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, the description needn't enumerate return fields, yet it still explains what each evidence piece contains and flags the wiki staleness caveat and the unrecorded-vs-empty distinction. Complete enough for an agent to call it correctly.

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

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

Schema coverage is 100%, so both parameters are already documented, and the description adds nothing specific about the limit or question format beyond the schema. The detail about observed facts requiring three installs informs content, not the parameters themselves, so baseline 3 applies.

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

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

States a specific verb and resource: it returns the evidence behind a question, each piece carrying claim, source URL, licence and date. Covers what layers of evidence exist (observed, curated, 2023 wiki). It does not explicitly distinguish itself from siblings like search_knowledge, 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 'for an answer that cites its sources' implies when to reach for this tool over a plain search, and 'Returns evidence rather than prose' reinforces that. But no sibling is named as an alternative and there are no explicit when-not conditions, so usage is only implied.

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

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

Annotations already establish the read-only, non-destructive profile, and the description adds substantial extra context: the data comes from deliberately uploaded scans, a day becomes public only after 3 installs scanned the item on that realm, medians are expressed in copper, and missing data is surfaced explicitly rather than silently omitted. That is meaningful disclosure beyond the annotations, though auth/connection requirements remain only loosely implied.

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?

Five short sentences with no obvious filler, but the ordering scatters provenance, thresholds, units, and caveats without front-loading the core purpose. 'Copper is the median' is a return-value detail that the output schema likely already covers, so it earns less of its place here.

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, the description need not explain return values, and it does cover the key behavioral context an agent lacks: data source, publication threshold, and explicit handling of unavailable data. It stops short of stating connection/auth prerequisites or how to interpret gaps per day, but is largely complete for a two-parameter read tool.

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

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

Schema coverage is 100%, so both parameters are already documented in the schema and the baseline is 3. The description adds no semantics for realm or itemId (e.g., realm format or id source), so it does not exceed 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 conveys the resource (auction price history per realm/item) but never states a clear verb and reads more like a data-provenance blurb than a purpose statement. It does not distinguish this tool from likely siblings such as market_value or item_page, which an agent would need to choose between.

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

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

There is no when-to-use guidance, no conditions that select this tool over market_value or item_page, and no stated prerequisites. The only contextual clue is 'when connected,' which describes behavior rather than when to invoke it.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description goes further with meaningful behavioral context: the 3-install agreement rule for public rows, the 'Everloot authorized public corpus' data source that applies 'when connected', and explicit reporting of missing/unavailable data. That provenance and trust-model detail is real value 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?

The purpose is front-loaded in the first sentence and the total is short. Most sentences earn their place (trust threshold, data source, explicit error reporting), though 'Not a Blizzard profile read and not a copied catalog' is slightly abstract and could be sharper.

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, the description does not need to explain return values, and it covers the remaining agent-facing questions: where data comes from, what makes a row public, and how missing data is surfaced. It stops short of naming valid collection values or describing scale/pagination limits, but nothing critical is missing for correct invocation.

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

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

Schema coverage is 100%, so both parameters are already documented, including the meaning of ownerInstallId. The description's 'Owned is what that install uploaded' reinforces that semantics but adds little syntax or format detail beyond the schema, so the baseline of 3 is appropriate.

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

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

The description gives a specific function: produce the missing items in one collection for one install, contrasting what is owned (uploaded by that install) against what is missing. It distinguishes itself from non-tools ('not a Blizzard profile read and not a copied catalog'), but it never distinguishes itself from actual sibling tools like completion_progress or entity_relations, so an agent still has to infer 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?

Usage is implied ('missing items ... for one install') and there are negative exclusions ('Not a Blizzard profile read and not a copied catalog'), which point away from wrong interpretations. But there is no explicit when-to-use statement, no prerequisite list, and no named sibling alternative for the adjacent collection/completion use cases.

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

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

Goes well beyond the readOnly/destructive annotations by disclosing the trust model: an entry is public only after 3 installs report it identically, and progress appears only when the install uploaded with the collection-sharing choice plus a verified grant, otherwise the answer says so. This is exactly the kind of authorization, aggregation, and data-availability context an agent needs before promising 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?

Front-loaded with what the tool returns, then the trust/availability caveats, then scope exclusions — a sensible order with no filler sentences. It is dense and slightly repetitive in re-stating the corpus and 'not a copied catalog' idea, which keeps it short of a 5.

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

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

With an output schema present, return values need no explanation, and the description adequately covers authorization prerequisites and data-availability behavior. It leaves the relationship to sibling tools like collection_gap or quest_page unstated, which is the main remaining gap for an agent choosing between them.

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

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

Schema coverage is 100%, so both parameters are already documented in the schema. The description adds only indirect framing ('one install's characters', install-uploaded data) and no syntax, format, or interaction details beyond what the schema provides, 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 (one install's characters' completion data) broken into concrete categories — achievements ranked by criteria met, reputations near next standing, titles known, quests finished in a chain. It explicitly distinguishes itself from adjacent concepts ('Not a Blizzard profile read and not a copied catalog'), so an agent can route away from profile-style reads and catalog lookups.

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

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

Gives clear context: it reads Everloot's current authorized public corpus when connected, and states that missing or unavailable data is reported explicitly rather than silently. It does not name a sibling alternative (e.g. collection_gap or quest_page) for when a narrower query is preferable, so the when-to-use-vs-alternative guidance 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?

With readOnlyHint/destructiveHint already covering safety, the description contributes real extra context: install counts are only recorded from 3 installs upward and a missing count means 'not counted, not zero', and GitHub facts carry a refresh timestamp so staleness is disclosed. These data-provenance caveats are exactly the kind of behavior an agent cannot get 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?

The resource is named first, then the ranking modes, then the per-project payload and caveats, so the structure is front-loaded and scannable. The sentences are dense but each carries distinct information (ranking criteria, fields shown, install-count rule, refresh timestamps) rather than 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-field explanation is optional, and the description still previews the projected fields (repo, stars, latest release, last commit, .toc interface number, Everloot installs). Combined with read-only annotations and the board semantics, an agent has what it needs to call this correctly; only explicit when-to-use guidance is absent.

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

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

The board enum values are listed in the schema, but the description supplies their meaning (installed = most installed, rising, active = most active, release = freshest release, maintained = best maintained), which the bare enum labels do not convey. 'limit' is undocumented in prose, but the ranking descriptions plus the install-counting semantics add genuine value beyond the 67%-covered 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 a specific resource (community-registry Forever addons and open-source projects) and scopes it to a ranked board, so an agent knows this returns ecosystem projects rather than game entities. It lacks an explicit verb like 'list', but the content and scope are unambiguous and clearly distinct from the wiki/entity siblings (item_page, npc_page, search_knowledge).

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

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

Usage is only implied: the enumerated board modes (most installed, rising, most active, freshest release, best maintained) hint at browse/discovery scenarios, but the description never states when to pick this over another tool or what conditions would exclude it. Since no sibling covers the same addon-registry data, the omission is tolerable but still leaves the agent to infer intent.

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 a safe read (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the description's real contribution is data provenance: player-observed relations backed by 'listed where 3 installs agree' with install count and last seen, versus game-file-derived relations explicitly flagged 'unconfirmed' with their source build. That confidence signalling materially changes how an agent should trust and present results, and the corpus scope ('authorized public corpus and the committed client layer') is useful 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?

Scope is front-loaded in the opening clause, and the two sentences carry dense but purposeful content. The parenthetical provenance blocks are heavy, but each earns its place by distinguishing confirmed from unconfirmed 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?

With 9 relation types, 9 kinds, a direction axis and an output schema present, the description supplies the missing envelope: direction semantics are reinforced and data provenance is clarified. The notable remaining gap is the absence of any when-to-use framing, which is scored separately under usage guidelines.

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 five parameters including rel, kind, direction and limit are already documented with descriptions and enums. The description's relation list loosely maps to rel enum values and 'Ids are the game's own' echoes the id description, adding little 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?

The first sentence states a precise verb and resource: it returns 'every typed relation of one entity, both directions,' and enumerates the concrete relation types (dropped by, sold by, reagent for, same icon). An agent immediately understands this is a relation-graph lookup rather than an entity fetch, though no sibling tool (e.g. get_entity) is named 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?

The description never states when to reach for this tool versus get_entity, search, or item_page, nor any prerequisite or exclusion. Provenance and direction are explained, but that is output content, not usage 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?

The annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds useful scope context, notably that some reference sites are page shapes only, but does not describe permissions, freshness, or other operational behavior beyond that.

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

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

The description is a single front-loaded sentence with no filler. Its terse phrase 'page shapes only' is efficient, though the overall definition is under-specified rather than overly wordy.

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 tool with an output schema and clear safety annotations, the description gives enough content scope for invocation. It is less complete for tool selection because it does not explain when to use this versus related tracker or progress 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?

The tool has zero parameters, so there are no parameter semantics to explain. Per the schema, the baseline is 4 when no parameters exist.

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

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

The description identifies a specific resource, the Everloot feature catalogue, and enumerates the status categories it covers: live, next, waiting, and page-shape-only references. It does not state an explicit action verb or name a sibling alternative, so it falls short of full 5-level differentiation.

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

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

There is no guidance on when to choose everloot_plan over siblings such as completion_progress, collection_gap, or ecosystem_projects. The content summary implies a tracker use case but does not provide explicit conditions or exclusions.

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

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

Annotations already declare the safety profile (readOnlyHint=true, openWorldHint=false, destructiveHint=false), so the description is free to add the non-obvious detail that the text block duplicates the JSON as a string. That quirk is genuinely useful invocation context, though nothing is said about missing ids, errors, or truncation.

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 names the resource and enumerates the returned fields; the second short sentence carries the JSON-string quirk. No filler, nothing repeated from the schema.

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

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

With an output schema present, the description need not document return values, and annotations cover the safety profile; the remaining need is minimal for a one-parameter read. Only the absence of any failure-mode or rate-limit note keeps it from being fully 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?

Only one parameter, and schema description coverage is 100% ('An id from a search result'), so the schema already carries the semantics. The description restates the same idea without adding format, length, or validity details beyond the schema's maxLength.

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 (fetch) and resource (one knowledge record) and pins the identifier's provenance to 'the id a search result gave,' which implicitly positions it as the follow-up to a search. It never names a sibling tool, so the differentiation from get_by_name, get_entity, or object_page is left for the agent to infer.

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

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

The precondition is stated clearly: the id must come from a search result, which tells the agent to call this after a search rather than as a standalone lookup. There is no explicit when-not guidance or named alternative for lookups by name or entity.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavior: matching is exact and case-insensitive, which tells the agent it will not do substring or fuzzy matching. It stops short of saying what happens on zero or multiple matches.

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 clause with no wasted words; the matching rule comes first. It is economical, though arguably so terse that it omits the disambiguation outcome an agent would want.

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 explained, and annotations plus full schema coverage carry much of the load. The real gap is behavioral: for a tool explicitly framed around disambiguation, the description never says whether multiple same-name records are returned as a list or how ambiguity is resolved.

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 goes slightly beyond it by specifying that the name parameter is matched exactly and case-insensitively, which the schema's terse 'Full record name.' does not say. It adds nothing about the kind enum, but the schema already enumerates and describes that.

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 lookup operation (exact full-name match, case-insensitive) on records, which is clear enough to distinguish it from a generic 'search'. However, it never names the sibling it competes with (e.g. search) or the record kinds covered, so differentiation is only implied by the phrase 'for disambiguation'.

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?

'For disambiguation' implies the usage context (use when you need a unique exact hit rather than a fuzzy result), but no alternative tool is named and no when-not condition is given. The agent must infer the contrast with search/get_entity on its own.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description usefully adds that this returns the *full* record rather than the hit summary, but says nothing about failure behavior for unknown ids or whether the record can be missing/stale after a search.

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; purpose lands first, qualifier second. It is arguably too terse for the ambiguity against sibling retrieval tools, 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?

An output schema exists, so return-value detail is legitimately omitted, and with one required parameter and full annotation coverage the basics are complete. The definition still leaves an agent guessing how it differs from get_by_name and fetch when both name and id are available.

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

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

Schema coverage is 100% and the single 'id' parameter is documented in-schema as coming from a search_knowledge hit, so the description adds nothing new beyond echoing that provenance. 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?

States a specific verb and resource — fetch the full record — and qualifies it by origin ('behind a search hit id'), which cleanly separates it from the summarised results a search returns. It does not name the sibling it complements (search_knowledge), but the implicit reference 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?

'Behind a search hit id' and 'for page rendering' imply the call follows a search and feeds a detail view, so usage is inferable. However, with siblings like fetch, get_by_name, and search in the set, the description never states when to pick this over those alternatives or what happens if the id is stale.

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 a safe read (readOnlyHint=true, destructiveHint=false), and the description meaningfully adds context: it reads Everloot's authorized public corpus when connected, reports missing data explicitly, and warns that the gold difference is not an accusation. This is substantive behavioral disclosure 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?

The description is a chain of terse, cryptic sentences ('Gameplay stays on its own line', 'A missing line is unrecorded') that read as stream-of-consciousness. The first sentence is front-loaded, but the rest is opaque rather than economical.

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 structure need not be explained, and the description covers several behavioral caveats. Still, the meaning of the 'money line' / 'own line' distinction is unclear, leaving an agent unable to fully predict what the ledger contains.

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

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

Schema description coverage is 100% for both required parameters (realm, character), so the schema carries the parameter burden. The description adds no syntax or format detail for character/realm, consistent with a baseline 3.

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

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

The opening sentence states a concrete resource: peak gold plus the money events from a character's own upload. However, the following jargon-heavy sentences ('money line', 'its own line') muddy what the tool actually returns and never differentiate it from siblings like auction_history or market_value.

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 lists constraints ('no scan of a player who did not upload', 'installs are not merged') but never states when to prefer this tool over alternatives such as auction_history. No explicit when/when-not routing is present.

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/destructive/openWorld annotations, the description discloses important behavior: only verified officer uploads count, a figure becomes public after two officers agree, characters can opt out and be excluded, and missing data is reported explicitly. This is substantial context that annotations alone do not provide.

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

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

The most important information is front-loaded, and most sentences carry useful behavioral detail. It is slightly long and could be tightened, but it avoids repetition and remains focused.

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 a simple two-parameter schema, existing output schema, and read-only annotations, the description covers the key privacy, aggregation, opt-out, and empty-result behaviors an agent needs. It is complete for correct invocation and interpretation.

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 two required parameters, guildName and realm, so the schema already documents their meaning. The description adds no format or syntax details for those parameters, making the baseline 3 appropriate.

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

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

The description opens by naming the specific resource and its contents (roster, bosses killed, loot, attendance, average item level), and it distinguishes the scope by stating it does not look up other players or guilds. An agent can identify this as a guild-publication board rather than a general lookup.

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

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

It provides clear context and a boundary condition: it does not look up other players or guilds, and an unpublished guild yields an empty board. However, it does not name a specific alternative sibling tool for those excluded cases.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false). The description adds real behavioral context beyond them: data provenance and its 'unconfirmed' status against a build, and the key constraint that only ids are returned, with names sourced from item_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?

The three usage modes are front-loaded and each sentence maps to a calling pattern with little waste. The parenthetical '(found in game files, unconfirmed, with the build)' is awkwardly spliced into the opening sentence and slightly slows the read.

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 zero required parameters, an output schema present, and annotations carrying safety, the description covers the main things an agent needs: the three modes, id-only output, and the name lookup path. It does not explain how limit applies to the unargumented tree mode or describe the return shape, a minor gap.

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

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

Schema coverage is 100%, so the schema already documents each parameter's type and examples, making 3 the baseline. The description earns above that by explaining how parameters compose — class alone or with optional subclass, slot and quality slugs — which the flat schema does not express.

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 (item categories: class, subclass, slot, quality) and its source (game files), and explicitly separates its role from the sibling item_page, which supplies names from player uploads. An agent can distinguish this from item_page 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?

It spells out three distinct invocation modes — no arguments returns the whole tree with counts, an item id returns that item's category path, and a class (plus optional subclass/slot/quality) returns the items inside. There is no explicit when-not-to-use or named alternative besides item_page, so it stops short of a 5.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), so the description's job is to add depth – and it does: data provenance (Everloot's authorized public corpus), the 3-install consensus threshold for names/pins/rates, exclusion of Wowhead rows, connectivity dependence, and explicit reporting of missing data. That is rich behavioral context 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?

It is dense and information-rich with no filler sentences, and the core payload description is front-loaded. The clipped fragments ('No Wowhead rows.') read terse rather than wasteful, though they slightly hurt flow.

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 shape needn't be repeated; the description instead supplies the semantic rules (consensus thresholds, corpus dependency, explicit failure reporting) an agent needs to interpret results. What's missing is when-to-use routing against the many sibling page 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?

The single itemId parameter has 100% schema description coverage ('Item id from a drop row.'), so the schema carries the semantics. The description adds nothing about the identifier's expected origin or format, which is the baseline score when schema coverage is complete.

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 ('One Forever item') and enumerates the exact payload: agreed name, public drop rate with kill count, and agreed map pin. This sharply separates it from sibling page tools such as npc_page, quest_page, object_page and vendor_page without needing to open any schema.

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

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

It explains the consensus conditions under which a name, rate or pin becomes public, which implicitly tells the agent what will and won't be returned. However, it never states when to reach for item_page versus siblings like get_entity, search or recipe_thresholds, so selection guidance is only implied.

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

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

On top of the read-only/non-destructive annotations, the description discloses the data pipeline that determines what a caller actually receives: a day becomes public only after 3 distinct reporters upload, values are medians, thin and outlier days are excluded, market value weights the last 14 public days while historical is a 60-day median, and absent data is surfaced explicitly. That is substantial behavioral context an agent cannot get from 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?

Three sentences, front-loaded with what is returned, then how the numbers are derived, then the missing-data guarantee. Every sentence contributes either output composition or interpretation rules; nothing is filler.

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

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

An output schema exists, so return shape need not be explained, and the description instead supplies the interpretive context that schema cannot: how days qualify, which windows feed which metric, and that gaps are reported rather than silently omitted. For a two-parameter read tool this is complete.

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

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

Schema description coverage is 100% for both required parameters (realm, itemId), so the schema already carries the burden. The description adds only loose scope framing ('one item on one realm') and no format, range, or identifier-resolution detail, which is the expected baseline when the schema is fully documented.

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

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

The description opens with a specific set of returned metrics (market value, minimum buyout, historical value, units listed) scoped to one item on one realm, which is far beyond a tautology. It does not, however, distinguish itself from plausible overlapping siblings such as auction_history or item_page, so an agent must still infer which one to reach for.

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

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

Usage is only implied: an agent can infer this is the lookup for an item's current/median market value on a realm. There is no explicit 'use this instead of X' routing, no stated preconditions, and no mention of when the 60-day historical figure versus the 14-day weighted value is the right one to consult.

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=true, destructiveHint=false, openWorldHint=false), so the description only needs to add context — and it does: it discloses the data source ('Reads Everloot's current authorized public corpus when connected') and error behavior ('Missing or unavailable data is reported explicitly'). However, the surrounding framing ('One Forever NPC', '3 installs agreeing', 'No copied spawn list') is cryptic and does not clarify what the returned page contains.

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

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

It is short and has no filler sentences, but the opening is not front-loaded with the core action; the most informative clause ('Reads ... public corpus') arrives after opaque domain jargon. Sentences earn partial credit but the ordering buries the point.

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, and annotations cover safety. The remaining burden — what the tool does and when to invoke it versus the many sibling page/entity tools — is not addressed, leaving an agent under-informed for a tool in a crowded namespace.

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?

With a single parameter at 100% schema description coverage, the schema already documents npcId as 'NPC id' with type and bounds. The description adds no format, range, or resolution guidance beyond that, so 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?

The description never states the action or resource plainly — it opens with 'One Forever NPC: agreed name and map pins' and dwells on agreement mechanics ('3 installs agreeing') rather than saying it retrieves an NPC page by id. Siblings like item_page, object_page, and vendor_page establish the pattern, but this text does not clearly differentiate or name what npc_page returns. A reader cannot confidently restate the tool's job.

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

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

There is no explicit when-to-use guidance and no mention of alternatives such as get_entity, get_by_name, or search for resolving an NPC. The only implicit signal is the 'npcId' requirement, which the schema already conveys. Nothing tells an agent which sibling to pick when resolving an NPC.

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/non-destructive and closed-world, but the description adds real domain behavior: it reads Everloot's current authorized public corpus when connected, a frequency only becomes public after 3 install reports, and an empty window is a measured zero rather than missing data. That zero-vs-absent distinction materially affects interpretation and is not in any structured field.

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 resource being fetched and each subsequent clause carries distinct domain information (loot windows, install-report threshold, zero semantics). The middle clause about windows and install reports is dense and slightly run-on, but nothing is padding.

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-shape explanation is not strictly required, yet the description usefully names what comes back and how to read it. Combined with the annotations and the data-source caveat, an agent has enough to call and interpret it correctly; missing only explicit routing against sibling page 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 objectId parameter is already well documented. The description's phrase 'the id in its GUID' marginally reinforces the identifier's nature but adds no syntax or formatting detail beyond the schema example.

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 with concrete examples (chest, herb, ore vein, fishing pool) and the keying identifier, so an agent can separate it from item_page/npc_page/quest_page siblings. The retrieval verb is implicit rather than stated ("One game object ... by the id"), which keeps it just short of a 5.

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

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

Use is implied by the parallel 'page' family and by the description's fetch-by-id framing, but there is no explicit when-to-use, no exclusion (e.g. vs get_entity or item_page), and no prerequisite statement beyond the connection note at the end.

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 true, destructiveHint false), yet the description adds substantial behavior the agent could not otherwise know: minimum thresholds of 10 characters, 3 installs and 3 addresses, rounding to the nearest 5, complementary suppression of derivable counts, deduplication ('each character counts once'), and explicit 'No names, ever' plus explicit reporting of missing 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?

The core measurement is front-loaded in the first sentence, followed by scope, suppression rules, window and default behavior in a logical order. It is dense and the suppression sentence is long, but nearly every clause carries decision-relevant information rather than 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 explained, and the description still covers the parts an agent needs to call it correctly: optional filters, default window, empty-argument behavior, thresholds and rounding. The only loose thread is the unexplained 'level band' grouping dimension with no corresponding parameter.

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 race, class, window and faction and the baseline is 3. The description confirms sensible semantics — all filters are optional and combine into joint groupings — and restates the window default, but adds little syntax or format detail beyond the schema. Note a minor mismatch: 'level band' is presented as a grouping dimension although no level parameter exists.

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 computation: character counts grouped by race, class, race-and-class, and faction-and-level band, drawn from an opt-in census. That is far more precise than the title alone. It does not, however, name or contrast any sibling tool, so an agent gets no explicit routing help beyond the obvious domain difference.

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

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

Usage is implied rather than stated: 'With no arguments, the overview: most played class first' tells the agent what a bare call returns, and the window sentence explains the default scope. There is no when-to-use/when-not guidance and no named alternative among the many sibling tools for an agent deciding between census aggregates and entity 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?

Despite annotations already covering the safety profile (readOnly, non-destructive), the description discloses substantive behavior the agent could not otherwise know: steps require 3 agreeing installs, gold requires 3 agreeing price uploads, no copied guides are used, the corpus is the currently authorized public one, and missing data is reported explicitly rather than silently omitted.

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

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

The purpose is front-loaded in sentence one and the remaining sentences each carry new information. The consensus clause ('on a reported recipe, or on the recipe colours that make it orange...') is dense and slightly hard to parse, costing a point.

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. The description covers sourcing, derivation rules and failure reporting; the only notable gap is the absence of guidance on when this tool is the right choice relative to its siblings.

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 profession, fromSkill and toSkill are already documented, including the constraint that toSkill must exceed fromSkill. The description adds nothing further about parameter meaning, 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 derives a leveling path for one profession, sourced from Everloot uploads, with an implied range (fromSkill to toSkill). The scope and data source are clear, but it never names or contrasts with the obvious siblings (everloot_plan, recipe_thresholds), leaving differentiation to inference.

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

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

There is no explicit statement of when to choose this tool over everloot_plan, recipe_thresholds, or search. Usage is only implied by the purpose, and no prerequisites or exclusions 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?

Beyond the readOnly/non-destructive annotations, the description discloses the consensus model ('each fact needs 3 installs agreeing'), a licensing constraint ('No copied quest text'), the live data source, and explicit error reporting for missing data. These are meaningful traits the annotations do not carry, though 'when connected' and 'authorized public corpus' stay vague.

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?

Five short sentences, front-loaded with the payload description, then provenance and constraints. Every sentence carries information, though the 'Forever quest' and 'installs' jargon is slightly cryptic to an outside reader.

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 the description covers provenance, data-quality rules, and error behavior. It is largely complete for a single-entity page fetch; only the precise meaning of connectivity/availability 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% and the single questId parameter is documented there. The description adds no syntax, range, or format detail for the id, so the baseline 3 applies when the schema does the work.

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

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

The description names the resource and scope precisely: one quest record with agreed title, level, giver, turn-in, and rewards. An agent can tell this is a single-quest retrieval, distinct from list/search tools, though it never explicitly contrasts itself with sibling page tools like item_page or npc_page.

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

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

There is no statement of when to use this tool versus alternatives such as search or get_by_name. The provenance sentence ('Reads Everloot's current authorized public corpus when connected') hints at a data source but does not give selection criteria or prerequisites for invoking it.

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

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

Annotations already declare readOnlyHint, openWorldHint, and destructiveHint, so the safety profile is covered. The description adds genuine value beyond that: excerpts-only due to copyright, links to original sources, and the caveat that a build's time reflects when Everloot first saw it rather than Blizzard's release time.

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

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

Three sentences, front-loaded with the ordering cue 'Newest first' followed by the payload description. The parenthetical enumerations are informative but slightly verbose; overall tight with minimal waste.

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 re-explained. The description covers purpose, return content type, and key caveats; the only gap is explicit guidance on alternatives and parameter usage.

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

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

Schema coverage is 67%, below the 80% threshold, so the description must compensate but doesn't. The filter enum values are effectively echoed by both the schema description and the tool description without adding syntax or format detail, and game/limit receive no description-level elaboration.

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

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

The description clearly states the resource and its contents: newest-first Blizzard blue posts, hotfixes, and new game builds. It's a clear verb-less but well-defined resource ('recent official changes'), though it doesn't explicitly contrast itself with siblings like search or fetch.

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

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

Usage is implied by the title and content ('recent official changes'), so an agent can infer when it's relevant. However, there's no explicit when-to-use/when-not guidance and no mention of alternatives such as search or search_knowledge.

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/openWorld/destructive annotations, the description discloses meaningful behavioural traits: data is inferred from players' trade-skill windows, a recipe is only surfaced when 3 installs agree, results are ranges never exact numbers, and cost per craft appears only when every reagent has an agreed price. This provenance and confidence detail is genuinely useful, though nothing is said about coverage, staleness limits, or error behaviour.

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

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

Four dense sentences with the core purpose front-loaded and no filler. The colour-metaphor phrasing is slightly indirect but each sentence contributes distinct information about provenance, thresholds, and cost estimates.

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 explained, and the description covers provenance, confidence rules, and cost caveats. It is nearly complete for this tool, missing only guidance on corpus freshness or how to interpret the returned ranges.

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

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

Schema coverage is 100%, so both parameters are already documented in the schema, and the description adds no extra syntax, matching rules, or format detail for the 'recipe' substring filter. The baseline of 3 applies when the schema carries the parameter burden.

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 (a profession's recipe skill thresholds where recipes turn yellow/green/grey) and implies retrieval, so an agent understands what it returns. It does not name or contrast with siblings such as profession_path or talent_plan, leaving differentiation to the tool name alone.

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

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

Usage is only implied: an agent can infer this answers 'when do recipes change colour for profession X'. There is no explicit when-to-use, no exclusions, and no named alternative for related questions, so the routing burden falls on the reader.

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/non-destructive/non-open-world, so the safety profile is covered. The description adds return-shape behavior: a cap of 10 results and the per-result id/title/URL fields, plus the fact that the text block mirrors the JSON as a string. That is useful 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 the relationship to search_knowledge and the caller contract front-loaded. The trailing 'text block is the same JSON as a string' is relevant but slightly cryptic in isolation.

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 re-explained, yet the description usefully summarizes the result shape and count cap. Nothing an agent needs to invoke it correctly appears to be 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?

There is a single 'query' parameter with 100% schema description coverage, including the note that question words are ignored. The description adds nothing about the parameter, so the baseline 3 applies.

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

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

States a specific verb and resource ('the same search as search_knowledge') and immediately differentiates itself from that sibling by its shape ('in the shape ChatGPT connectors and deep research call by name'). An agent can tell search apart from search_knowledge 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?

It gives clear context for when this variant applies (ChatGPT connector / deep research callers invoking by name) rather than a generic search. There is no explicit when-not or a named fallback beyond the implied search_knowledge equivalence.

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=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds genuinely new behavioral context: exact-name matches are ranked first, and results include provenance (source and licence) — useful signal about result ordering and trustworthiness that annotations do not convey.

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 with the purpose front-loaded and no filler. Each sentence carries information (purpose, ranking rule, result provenance), though the whole is quite terse for a 4-parameter tool.

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

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

An output schema exists, so return values need not be re-explained, and provenance/ranking are covered. But for a tool with 4 parameters, two enums, and 27 siblings including `search` and `get_by_name`, the absence of any routing guidance leaves the definition only minimally complete.

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

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

Schema description coverage is 75%, with `limit` carrying no description at all, and the description mentions none of the four parameters. The `kind` and `version` narrowing options are left entirely to the schema, so the description adds no meaning beyond structured fields and does not compensate for the uncovered `limit` parameter.

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 ("Search WoW lore and Forever reference data"), so the agent knows exactly what corpus is queried. However, with siblings named literally `search` and `get_by_name` in the same toolset, it does nothing to distinguish itself from those alternatives.

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

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

There is no when-to-use, when-not-to-use, or alternative-routing guidance. An agent cannot tell from the description whether this or the sibling `search` should be called for a given lookup, which is a significant gap given the near-identical sibling name.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description goes beyond them by disclosing that problems are reported in plain words and 'nothing is dropped silently' (error/partial-result behavior), plus the provenance caveat that the data is game-file data that is 'unconfirmed'. That is genuine behavioral context the annotations do not carry.

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

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

Front-loaded with the verb, then a colon list of exactly what is returned and which problems are surfaced. Every clause carries information. It is a single dense sentence, so slightly heavy for a one-parameter tool, but nothing reads as 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 and annotations both exist, so the description is not obligated to explain the return shape, yet it summarizes the decoded contents and the failure modes anyway. With one required parameter at full coverage, an agent has everything needed to call it correctly; the only minor omission is a pointer to the related build/plan 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% and the single parameter is documented, so the baseline is 3. The description earns more by spelling out the concrete shape of a valid code and the accepted link form ('a calculator link carrying one after #plan='), which tells the agent what actually counts as a valid input beyond the schema's generic 'share code, or a link that carries one'.

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

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

The description gives a specific verb ('Decodes') and a tightly scoped resource ('Everloot talent share code'), and even pins down the input grammar (EL1-<class>-<spec>-<build>-<payload> or a link with #plan=). That is more than clear. It stops short of a 5 only because it never names or contrasts with the obvious siblings (everloot_plan, talent_tree), so sibling differentiation is inferred from the resource rather than stated.

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

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

Usage is implied: you reach for this when you hold a share code or a calculator link. There is no explicit when-to-use, no when-not-to-use, and no named alternative, so an agent must infer the boundary against everloot_plan/talent_tree on its own.

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 and destructiveHint=false, so the safety profile is covered. The description nevertheless adds genuine context beyond the annotations: the data's provenance and uncertainty ('from the game files, unconfirmed, with the build') and the semantic meaning of node ids ('the ids a share code names'), which is valuable for interpreting the payload.

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

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

The core content is front-loaded, but there is redundancy: 'from the game files (found in game files, unconfirmed, with the build)' repeats itself, and the dangling provenance qualifiers make the opening sentence hard to parse. The calculator pointer reads as an aside. It is usable but not tight.

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 the description need not explain return values, yet it usefully summarizes the node contents anyway. Between the enum-covered class, the optional tree filter, the annotations, and the output schema, an agent has everything needed to invoke it correctly; only sibling routing is ambiguous.

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

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

Schema description coverage is 100% – both the class enum and the tree filter are fully documented in the schema. The description's 'narrow to one tree by name' merely restates the tree parameter, adding no syntax or format detail beyond what the schema already provides. 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 resource (WoW: Forever talent trees of one class) and enumerates exactly what each node contains (talents, ranks, grid position, prerequisites, row gate, point arrival levels). An agent can tell what it returns. It does not, however, explicitly distinguish itself from the sibling talent_plan, so it stops short of 5.

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

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

It offers some usage direction: 'Narrow to one tree by name' and a pointer to the calculator at /tools/talents/<class>. But there is no explicit when-to-use vs. when-not, and no contrast with the sibling talent_plan (which presumably consumes these node ids), leaving the selection decision 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=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavior beyond that: the aggregation rule (an item lists only when three installs agree on item and copper price, with two agreed prices both retained), the live data source ('current authorized public corpus when connected'), and explicit reporting of missing/unavailable 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?

It is reasonably short and the core statement leads, but several sentences are cryptic ('No copied catalog', 'Everloot's current authorized public corpus') and the aggregation rules consume space without clearly helping the agent decide or call the tool. Some sentences do not obviously earn their place.

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

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

An output schema exists, so return shape need not be explained, and annotations cover safety, which lowers the burden. However, the description still fails to state plainly what is returned (a vendor's inventory) or how it relates to npc_page, and its obfuscated terminology limits how much the provenance/error details actually help.

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

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

There is a single parameter, vendorNpcId, with 100% schema description coverage, so the schema fully documents it. The description adds no syntax, range, or acquisition hints for the id, 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?

The fragment 'Goods one Forever vendor sells' does point at the resource (a vendor's item listing), and the title/name reinforce 'vendor page'. But the phrasing is garbled and heavily obfuscated, and it never states a clean verb+resource or distinguishes itself from the parallel sibling npc_page, so an agent must guess at the exact intent.

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

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

There is no when-to-use guidance and no routing against alternatives such as npc_page (vendor details) or item_page (item details). The only conditional statements describe data-inclusion rules, not invocation conditions, so the agent gets no help deciding when this tool is the right pick.

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 mark this as a safe read-only operation, and the description adds substantial behavioral context beyond them: provenance and confirmation levels for each entity type, the three-install agreement rule, unavailable unreleased zones, missing game objects, and the connected public corpus.

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

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

The description is front-loaded with the result type and ordering, then moves efficiently through invocation, provenance, exclusions, and data source. Every sentence contributes actionable context.

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

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

For a six-parameter read-only lookup with an output schema, the description is complete: it covers input modes, distance semantics, data reliability, exclusions, and the connected data source.

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

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

Schema coverage is 100%, so the schema documents the parameters in detail. The description still adds useful invocation semantics by presenting zone-plus-coordinates and NPC-id starting point as the two modes and by clarifying that distances are straight-line yards.

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 result shape: entrances, NPCs, and vendors near a point, nearest first with distances in yards. It clearly scopes what is included and excluded, though it does not explicitly name sibling tools as alternatives.

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 explains the two invocation modes: zone plus x/y, or an NPC id. It also gives exclusions for unreleased zones and game objects, but it does not direct the agent to an alternative sibling tool when this one is unsuitable.

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