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

With no annotations, the description carries the full burden, and it discloses the generated artifacts (event-dispatch Core.lua, SavedVariables handling, slash command, optional XML/mixin and Settings-API panel) and frames the tool as a skeleton generator. It doesn't explicitly state write-side-effect behavior, but the schema's 'write' parameter handles that, so the description adds substantial context beyond the structured fields.

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

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

Two sentences: the first is a compact, front-loaded enumeration of what is generated, and the second is a crisp usage directive. No filler or redundancy; every phrase conveys necessary 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?

The description provides a strong overview of the generated skeleton's structure and components, which is the core context. However, it omits the return format when 'write' is false and doesn't mention prerequisites like folder configuration; with no output schema, these details would be useful. Slight deduction for that 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 70%, setting a baseline of 3. The description adds meaning to multiple parameters: 'chosen clients' links to flavors, 'SavedVariables handling' to savedVariables, 'slash command' to slashCommand, 'XML frame template with its Lua mixin' to withFrame, and 'Settings-API options panel' to withOptions. This enriches the brief schema descriptions beyond their literal definitions.

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

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

The description clearly states the tool's purpose with a specific verb ('Generate') and resource ('addon skeleton'), listing all included components (.toc manifests, Core.lua, SavedVariables handling, slash command, optional XML/mixin and Settings-API panel). This distinguishes it unambiguously from sibling tools that focus on API search, file reading, or validation.

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

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

The description explicitly says 'Use this to start a new addon rather than writing boilerplate by hand,' giving clear when-to-use guidance. It doesn't enumerate alternatives or when-not-to-use, but no sibling tool serves as a direct alternative for scaffolding, so exclusions are implicit.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It clearly states the tool checks existence, implying a read-only query, but it does not detail the return format (e.g., a per-client boolean table) or any error behavior. The description is not misleading but lacks depth beyond the basic operation.

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

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

The description is two sentences, front-loaded with the purpose, then gives a concrete usage scenario. Every sentence earns its place, and there is no wasted text or redundancy with 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?

This is a simple single-parameter lookup tool with no output schema. The description covers what it checks, which clients, and when to use it. It omits details about the output structure, but for a 1-param diff tool of this simplicity, the description is sufficiently complete for an agent to select and invoke it.

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

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

Schema coverage is 100%, with the parameter description already explaining 'Function, event or type name, e.g. GetSpellInfo or C_Item.GetItemInfo.' The tool description repeats 'function, event or type' but adds no new meaning about the parameter beyond what the schema provides, so the baseline score 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 description uses a specific verb phrase 'Check whether a function, event or type exists in each game client' and clearly names the resource (function/event/type) and scope (retail, Classic progression, Classic Era). This distinguishes it from sibling search tools like wow_api_search, which find definitions rather than compare availability across clients.

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

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

The description gives explicit when-to-use guidance: 'Use this before writing code that has to run on more than one flavor, or to explain why something works on Classic but not retail.' This provides clear context, though it does not explicitly name alternative tools for when not to use it (e.g., 'use wow_api_search to find where something is defined').

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

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

With no annotations provided, the description carries the full burden. It uses non-mutating verbs like 'search' and 'show', implying a read-only operation. However, it does not disclose any potential limitations, pagination, or how results are ordered beyond 'in order'. It adds some context about payload arguments but is not rich in behavioral details.

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

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

The description is two sentences with no fluff. It front-loads the core purpose and immediately follows with a practical use case. Every word earns its place, making it highly concise and well-structured.

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 search tool with no output schema, the description adequately explains what the tool does and shows a key output detail: 'payload arguments in order'. It does not describe the full return format or how 'limit' and 'flavor' affect results, but given the tool's simplicity and schema coverage, it is reasonably 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 schema covers 67% of parameters with descriptions for 'query' and 'flavor'. The description reinforces that the query is an 'event name or fragment' but does not add details for the 'limit' parameter, which lacks a description. Overall, it adds little beyond the schema, but does not conflict with it, earning a baseline score.

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 a specific action: 'Search the events an addon can register with frame:RegisterEvent' and adds the distinct feature of 'show each event's payload arguments in order'. This distinguishes it from sibling tools like wow_api_search or wow_api_type_search by focusing specifically on events and their payloads.

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

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

The description gives a clear usage context: 'Use this whenever writing an OnEvent handler, so the argument list matches what the client sends.' This tells the agent when to use it, though it does not explicitly mention alternatives or when not to use it. It provides a clear 'when' but lacks 'when-not'.

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

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

No annotations are provided, so the description carries the burden. It discloses valuable behavioral information: the search covers specific API categories and results include full argument and return signatures. It does not mention whether the search is read-only or any limitations, but for a search tool this is reasonably transparent.

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

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

The description is compact and well-structured: a clear opening sentence, an illustrative second sentence with concrete examples, and a practical usage directive. No redundant information; every sentence contributes meaning.

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

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

Given the tool's simplicity, no output schema, and rich sibling set, the description covers the tool's scope, result contents, and usage. It could go further by explicitly stating that events/types are handled by sibling tools, but the enumeration of function categories already implies this distinction.

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

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

The schema already describes query, flavor, and namespace well. The description adds useful context about API families, but it does not elaborate on the limit parameter, which remains undocumented. With 75% schema coverage, the description provides some extra meaning but does not fully close the gap for the undocumented 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?

The description uses a specific verb and resource: 'Search World of Warcraft's in-game Lua API'. It further distinguishes from siblings by enumerating the covered API types (namespaced functions, legacy globals, widget methods) and by noting that it returns argument and return signatures. This clearly identifies it as the function search tool versus event/type search siblings.

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

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

It provides clear usage context: 'Use this before writing any addon code that calls the game.' This tells the agent when to invoke the tool. However, it does not explicitly mention exclusions or point to alternatives like wow_api_event_search or wow_api_type_search, so it falls short of full 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?

No annotations are provided, so the description carries the full burden. It implies a read-only operation via 'Report' and 'confirm,' but does not explicitly state safety or side effects. It does add details about sync times and size, which is useful context beyond a simple 'report.'

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

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

The description is two sentences, front-loaded with the key output aspects and a usage tip. No wasted words.

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

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

The tool is simple with no params and no output schema. The description covers what the tool reports (API index, UI source, game data sets, sync times, size) and when to use it. This is complete for the tool's complexity.

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

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

The schema has no parameters, so the baseline is 4. The description explains what the tool reports, but since there are no params, there is no parameter syntax to clarify. It adds context but does not further explain parameter semantics beyond 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 clearly states the tool reports which API index, UI source, and game data sets the server has, along with sync times and size. This is a specific verb+resource and distinguishes from siblings like wow_data_status by focusing on sync status and size.

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 sentence 'Use this to confirm the data is present and current before relying on other tools' provides clear context for when to use it. There are no explicit alternatives or exclusions, but the context is sufficient for a 0-param status tool.

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

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

With no annotations provided, the description carries the full transparency burden. It discloses that the tool searches multiple table types and resolves member names to their containing table, which is useful. However, it omits behavioral details like default flavor, return shape, or pagination behavior, leaving gaps.

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

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

Two sentences with no filler: the first states the tool's scope and gives a concrete example, the second clarifies member-name behavior. Every word earns its place; format is ideal for agent consumption.

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 no output schema and a straightforward search use case, the description adequately covers what is searched and how member-name search behaves. It doesn't describe return format, but for a search tool this is not a critical gap, especially with sibling context indicating a specialized type search.

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 query, kind, and flavor already described. The description adds significant semantic value by explaining member-name resolution, which clarifies query behavior beyond the schema. The limit parameter still lacks narrative guidance, but the schema's min/max partially covers it.

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

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

The description uses a specific verb + resource: 'Search the Enum.*, Constants.* and structure tables', clearly distinguishing it from sibling tools like wow_api_search and wow_api_event_search. The concrete example (Enum.ItemQuality, AuraData) further anchors the purpose.

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

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

The description explicitly explains a key usage pattern: 'Searching for a member name finds the table that contains it.' This gives actionable guidance beyond a generic 'search' instruction. It does not explicitly name alternatives or state when not to use it, but the sibling context makes the niche apparent.

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

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

With no annotations, the description carries the full burden. It discloses important return values and explains the atlas concept, but it omits behavioral details such as how search matching works (substring vs exact), whether results are limited by the limit parameter, sorting, or error conditions. This is adequate but not comprehensive.

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

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

The description is three sentences, with the main action front-loaded, followed by return values and a usage preference. Every sentence adds value; no redundant or filler content.

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 search tool with no output schema and no annotations, the description covers purpose, return values, and usage preference. It is missing explanation of the limit parameter and result limit behavior, but given the tool's simplicity, 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?

Schema description coverage is only 50% (query is described, limit is not). The description adds no parameter-level detail beyond implying the query is the atlas name fragment. It does not explain the limit parameter's function or default behavior, leaving a gap that the description doesn't compensate for.

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

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

The description clearly states the tool searches named texture atlas elements used with SetAtlas, distinguishing it from sibling search tools (e.g., wow_icon_search, wow_file_search). It also lists specific return values (dimensions, FileDataID, exact SetAtlas call), making the purpose unambiguous.

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

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

The description provides explicit guidance to prefer atlases over raw texture paths for UI art, which is a clear usage directive. However, it doesn't name specific sibling tools as alternatives or state when NOT to use this tool, so it falls slightly short of full exclusionary 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?

With no annotations provided, the description carries the full burden of disclosing behavior. It does so by explaining what the tool reports (counts and sync dates) and what to do for missing datasets. It does not mention side effects, auth, or rate limits, but as a read-only status reporter, the absence of such disclosures is not a significant gap.

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

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

The description is two sentences with no wasted words. It front-loads the primary action ('Report which game data sets are synced') and adds the needed usage context. Every phrase 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?

Given the tool's simplicity (no parameters, no output schema), the description is nearly complete: it identifies what data sets are covered, what metrics are provided (counts and dates), and how to react if data is missing. It could optionally mention the underlying data source, but this is not essential for an agent to select and invoke the tool effectively.

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

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

The tool has zero parameters, and the schema is empty. According to the rubric, the baseline for no parameters is 4. The description adds no parameter information because none is needed, making this score 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 uses a specific verb 'Report' and clearly identifies the resource: which game data sets are synced (file/FileDataID index and texture atlas index). It distinguishes from siblings by focusing on sync status rather than searching or file operations, and the phrasing 'Use this when a game data lookup returns nothing' further differentiates it.

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

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

The description explicitly states when to use the tool: 'Use this when a game data lookup returns nothing.' However, it does not name alternative tools or explicitly state when not to use it, though the 'what to run for any that are missing' clause hints at next steps. This is clear but lacks full exclusionary 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?

With no annotations, the description must carry the burden. It adds useful behavior like numeric queries resolving to paths and the dependency on index syncing, but it does not explicitly state that the operation is read-only, nor does it disclose performance, error behavior, or output format.

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 three sentences, front-loaded with the core purpose, and every sentence adds distinct value (function, coverage, usage). 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?

It covers core purpose, usage, and some behavioral nuances, but with 5 parameters and no output schema, it leaves gaps: no mention of what a response looks like, what happens on not found, or how to check index sync status (e.g., wow_data_status). It is adequate but not fully comprehensive.

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 80%, and the description adds meaningful semantics beyond the schema—explaining that numeric queries are treated as FileDataIDs and that model/map coverage depends on the full index. This enriches the meaning of query and includeNonInterface beyond the raw property definitions.

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

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

The description clearly states the tool finds game art and asset files by name and returns FileDataID and texture path. It also explicitly ties usage to SetTexture, SetNormalTexture, or SetModel, distinguishing it from sibling search tools like wow_icon_search or wow_atlas_search.

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 a clear directive: 'Use this whenever writing SetTexture, SetNormalTexture or SetModel.' This gives explicit context for when to use, though it does not mention when not to use or point to alternatives, so it lacks full exclusionary guidance.

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

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

No annotations are provided, so the description must carry the transparency burden. It discloses that the tool returns path and FileDataID, and explains the naming convention, but it does not explicitly state read-only behavior, how the limit parameter works, or what happens when no icons match.

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 three sentences, each earning its place: function and returns, naming convention, and use cases. No fluff or redundant content.

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 search tool, the description covers the return value and use cases. However, it omits details about the limit parameter and does not describe the response format or behavior for empty results, so it is not 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?

The schema documents 'query' with an example, and the description adds useful naming convention context. However, the 'limit' parameter is not explained in either place, leaving a key part of the parameter semantics uncovered. Coverage is approximately 50%.

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

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

The description clearly states the tool searches game icon textures by name and returns the path and FileDataID. However, it does not explicitly distinguish itself from sibling tools like wow_atlas_search, even though the focus on 'icon textures' is specific.

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

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

The description gives explicit use cases: picking icons for buttons, addon compartment entries, and .toc IconTexture. It does not mention exclusions or alternatives, but provides clear context for when to use it.

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

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

With no annotations provided, the description carries the behavioral transparency burden. The word 'Report' implies a read-only operation, and it discloses what information is returned (paths, flavors, build numbers, addons). It doesn't explicitly state side-effect-free behavior, but given the simplicity of the tool, this is adequate.

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

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

The description is two sentences, front-loaded with what the tool does and followed by practical usage. Every word earns its place; no fluff 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, zero-parameter tool with no output schema, the description explains what is reported and why to use it. It lists the categories of information returned, making it sufficient for an agent to decide when to call. A bit more detail on the output structure could earn a 5, but this is not a significant gap.

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

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

The tool has zero parameters, so the input schema provides no information to clarify. The description adds value by describing the kind of data returned (paths, flavors, build numbers, addons), which helps set expectations for the output. Baseline for 0 params is 4.

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 verb ('Report') and the resource ('World of Warcraft installations found on this machine'), with specific details (paths, flavors, build numbers, addons) that distinguish it from sibling tools which focus on APIs, UI files, linting, 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?

The description gives explicit use cases: 'confirm which client tools will target' and 'discover addon folders to lint.' While it provides clear context, it does not mention when not to use it or name alternative tools, 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It details the categories of problems detected (removed/moved APIs, unknown events, taint, performance traps), offering substantive insight into behavior. It does not mention output format or side effects, but for a static analysis tool this is adequate.

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

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

The description is compact and front-loaded with the core purpose. Every sentence contributes value: the first defines the tool and its scope, the second specifies when to run it. 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 tool with no output schema and no annotations, the description provides sufficient context: what it analyzes, what categories of issues it finds, and when to use it. It lacks explicit return-format details, but the description is otherwise complete and actionable.

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 each parameter is already documented. The description does not add additional parameter-level meaning, but that is acceptable given the high schema coverage. 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 description uses a specific verb ('Analyse') and identifies the resource ('addon Lua'), and clearly distinguishes this tool from sibling tools by focusing on WoW-specific linting (removed APIs, events, taint, performance traps). It fully explains what the tool does.

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 provides explicit guidance on when to use the tool ('Run this on any addon Lua before shipping it, and whenever porting between clients'). It does not name alternative tools or provide when-not-to-use exclusions, but the context is clear enough for an agent to decide.

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

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

No annotations are provided, so the description carries the burden. It discloses what is validated and mentions that some directives are 'silently dropped' by the client, implying the tool surfaces warnings. However, it does not describe the output format, whether it is read-only, or any side effects. For a validation tool, this is acceptable but not fully transparent.

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

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

The description is two sentences long, front-loaded with the core action and scope, followed by practical usage guidance. Every word earns its place, with no redundant phrasing or 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 validation tool with no output schema and no annotations, the description provides a solid scope of checks and a clear usage context. It misses only the return format or outcome expectations, but given the tool's nature, this is not a major gap. Overall, it is complete enough for an agent to select and invoke 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?

The input schema already has 100% description coverage for all three parameters. The tool description adds overall context about validation scope but does not provide additional meaning beyond the schema for individual parameters. Baseline 3 is appropriate since 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 uses the specific verb 'Validate' with the resource '.toc manifest', and enumerates distinct checks (interface version, flavor suffix, directives, SavedVariables, file lists). This clearly distinguishes it from sibling tools like wow_lua_lint and wow_xml_validate, which target other file types.

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

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

The description explicitly states when to use the tool: 'Run this whenever an addon fails to load or shows as out of date.' This gives a clear trigger context. However, it does not mention when not to use it or alternatives, but that is less critical given the specialized purpose.

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

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

With no annotations, the description must carry the full transparency burden. It conveys a read-only search over a large fixed corpus and adds 'ground truth' context, but it does not disclose output format, default flavor/limit behavior, or performance implications.

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

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

The description is two sentences: the first front-loads the action and scope, the second provides valuable usage context. No words are 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?

Despite 8 parameters and no output schema, the description clearly covers the tool's purpose, scope, and primary use case. It relies on the schema for filters and limits, though it does not describe the return structure or mention TOC files, leaving 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 75%, so the schema already documents most parameters. The description adds no parameter-specific meaning beyond reinforcing that this is a regex search, so the baseline score 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 and resource: 'Regex-search the full Lua and XML source of the 348 Blizzard addons that ship with the client.' This clearly distinguishes it from sibling tools like wow_api_search or wow_ui_read_file by emphasizing full-source ground-truth searching.

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

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

'Use it when the API reference tells you what a function is but not how it is meant to be used' gives a clear trigger and context. However, it does not explicitly name alternative tools or provide when-not-to-use exclusions, 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.

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

No annotations are provided, so the description must carry the full burden. It conveys that the tool lists packages and supports optional filtering, and it frames this as a read-only, preparatory step. However, it does not explicitly disclose whether there are any side effects, permissions, or limitations (e.g., return format, ordering, or performance characteristics). This is sufficient for a simple list operation but leaves room for more transparency.

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

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

The description is two sentences, front-loads the action, and each clause earns its place. It states the payload, the optional filter, the intended workflow, and a practical example without any 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?

Given the simplicity of the tool, the rich parameter schema, and the presence of sibling tools like grep and file search, the description is adequately complete. It explains the tool's scope, ties it into a workflow, and gives an example. It does not describe return values, but the absence of an output schema makes that less critical. A 5 would require more explicit details about output or edge cases, so 4 is appropriate.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by providing a concrete example ('Blizzard_ActionBar for action buttons') that illustrates how the filter parameter maps to real UI packages, going beyond the schema's basic substring definition. This extra semantic guidance raises the score to 4.

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

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

The description uses a specific verb ('List') and names the exact resource ('Blizzard_* addon packages that ship with the client'), clearly distinguishing it from sibling tools like grep or file search. It also gives a concrete example ('Blizzard_ActionBar for action buttons'), which reinforces the tool's purpose.

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

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

The description explicitly tells when to use this tool ('Use this to find which package owns a piece of the UI before grepping it'), which clearly positions it relative to a sibling tool (grep). It provides a clear usage scenario but does not list explicit exclusions or when not to use it, 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?

No annotations are provided, so the description carries the burden. It explains what mixins are and that searching a method name yields the defining mixin, adding useful context. However, it doesn't disclose return format, pagination, or other side effects, leaving some behavioral aspects implicit.

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

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

The description is two sentences, front-loaded with the main purpose, and contains no filler or redundant phrasing. Every sentence adds value.

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 focused search tool with 3 parameters and no output schema, the description covers core functionality, domain context, and use cases. It doesn't explicitly mention result format or parameter edge cases, but the provided information is sufficient for a straightforward read-only search.

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 67% (query and flavor have descriptions, limit does not). The description adds a small behavioral nuance about query ('Searching a method name finds the mixin that defines it') but doesn't elaborate on limit or flavor 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 uses a specific action ('Search') and a clear resource ('the mixin tables Blizzard's UI uses'), and further distinguishes itself from sibling tools by explicitly mentioning 'XML mixin attribute or CreateFromMixins' and 'method name finds the mixin that defines it'.

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 explicit use cases: 'reuse Blizzard's behaviour' and 'understand what a template's methods do.' It doesn't name alternatives but clearly implies this tool is for mixin-specific searches, making it distinct from API or template searches.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses the core behavior (reading a file) and the purpose, but it does not mention return format, error handling, line range behavior, or any potential side effects. Since it's a read-only tool, the safety profile is implied but not explicitly stated.

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

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

The description is two sentences, front-loaded with the primary purpose, and contains no unnecessary words. Every sentence adds value.

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 tool with 4 parameters and no output schema, the description is minimal. It gives good context for the purpose and usage, but it does not explain the startLine/endLine parameters or describe the return value. The schema provides partial coverage, but the description leaves important operational details 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 descriptions cover 'path' and 'flavor', but 'startLine' and 'endLine' have no descriptions. The description adds context for 'path' by saying it should come from grep/template_search, but it does not explain the line range parameters at all. With 50% schema coverage, the description needed to compensate for the missing parameters but does not.

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

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

The description clearly states the tool's function: reading a Lua or XML file from Blizzard's shipped UI source. It uses a specific verb ('Read') and resource ('file from Blizzard's shipped interface source'), and distinguishes itself from sibling tools by referencing paths from wow_ui_grep or wow_ui_template_search.

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

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

The description explicitly says to use this tool when you need the full implementation in context rather than a single matching line, and directs users to use paths reported by wow_ui_grep or wow_ui_template_search. This clearly defines when to use this tool versus alternatives.

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

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

With no annotations, the description carries the full burden. It discloses that results show inheritance chain, attached mixins, and definition locations, which is useful behavioral info. It does not explicitly state read-only behavior, rate limits, or other side effects, but for a search tool this is acceptable.

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 three concise sentences, front-loaded with the core action. Each sentence adds value: what it searches, what it shows, and a usage tip. 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?

Given the tool's complexity (4 params, no output schema), the description covers the main purpose, key result content, and a practical use case. It does not detail return format or ordering, but the info provided is enough for an agent to select and invoke the tool correctly in most cases.

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

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

Schema coverage is 75% (three of four parameters have descriptions), but none of the parameters are explained in the tool description itself. The 'limit' parameter has no description in either schema or description, so the description does not compensate for the gap.

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

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

The description clearly states the tool searches Blizzard's virtual XML templates and shows inheritance chain, mixins, and definitions. It distinguishes the tool from writing frame art from scratch, but does not explicitly differentiate it from sibling search tools like wow_ui_mixin_search, so it falls short of a 5.

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

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

The description provides a clear usage context: use this to inherit Blizzard's look and behavior instead of creating frame art from scratch. However, it does not mention when not to use it or compare it to alternative sibling tools, so it lacks explicit exclusions.

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

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

With no annotations provided, the description carries the full burden and discloses specific behaviors: it checks for unknown elements/attributes, nesting, enum values, and structural issues. It also highlights that errors are otherwise invisible, which is meaningful context beyond a generic 'validate' statement.

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 dense with useful information. No fluff or repetition; the first sentence explains scope, the second provides usage rationale.

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

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

The description covers what, why, and when for this simple validation tool. Minor gaps: it doesn't describe the return format (no output schema) or clarify that at least one parameter must be supplied, but these are not critical for basic 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 100% with both parameters described, so the baseline is 3. The description adds no extra meaning about the parameters, notably not clarifying the relationship between 'xml' and 'path' (e.g., whether they are alternatives or combined).

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 'Validate WoW interface XML against Blizzard's own UI.xsd' and lists specific error types it catches, distinguishing it from sibling tools like wow_lua_lint and wow_toc_validate.

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 explicitly instructs 'Run this on every XML file an addon loads' and explains why (the client silently ignores mistakes), giving clear context for when to use the tool, though it doesn't name alternatives or exclusions.

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