Server Quality Checklist

Tool Scores

• wow_character_equipmentA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnly, openWorld, idempotent, and non-destructive hints. The description adds behavioral detail by specifying that it returns one entry per filled slot and that the character name is case-insensitive.

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

  Conciseness5/5

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

  The description is concise, with a front-loaded main sentence, followed by an Args section and Returns section. It is well-structured with no wasted words.

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

  Completeness5/5

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

  For a simple two-parameter read-only tool with an output schema, the description covers the purpose, parameters, and return summary. Annotations cover safety, and the output schema handles return details.

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

  Parameters4/5

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

  The input schema only lists realm and character without descriptions, but the description supplements with 'Realm name or slug' and 'Character name, case-insensitive.' This adds meaning beyond the bare schema, covering both parameters.

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

  Purpose5/5

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

  Description states 'Get every equipped item with slot, name, item level, quality and enchants.' This clearly specifies the action, resource, and scope, distinguishing it from sibling tools like wow_character_summary or wow_character_resource.

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

  Usage Guidelines3/5

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

  No explicit when-to-use or alternatives are mentioned. The tool's usage is implied by its name and description, but it does not indicate when to choose it over sibling tools such as wow_character_summary.

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

• wow_character_mythic_keystoneA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds beyond that: it notes the 'Returns an error if the character has not completed a Mythic Keystone dungeon in that season' and explains the default season selection, which are useful behavioral details not present in annotations.

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

  Conciseness5/5

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

  The description is front-loaded with a clear purpose sentence, followed by a structured Args list and a Returns line. It is concise yet covers all necessary details without redundancy, earning each sentence's place.

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

  Completeness4/5

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

  The tool has an output schema, so the description doesn't need to detail the return structure. It covers parameter semantics, default behavior, and an error condition. The only slight gap is the lack of explicit guidance on when to select this over sibling tools, but the purpose is sufficiently clear.

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

  Parameters5/5

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

  Schema description coverage is 0%, so the description carries the full burden. The Args section explains each parameter: realm accepts name/slug, character is case-insensitive, and season_id defaults to the most recent season. This fully compensates for the lack of schema descriptions.

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

  Purpose5/5

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

  The description uses a specific verb ('Get') and resource ('a character's Mythic+ score and best dungeon runs for a season'), clearly distinguishing it from sibling tools like wow_character_summary or wow_character_equipment. The title 'WoW Mythic+ Profile' reinforces the focus.

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

  Usage Guidelines4/5

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

  The description clearly implies when to use the tool—when Mythic+ score and best runs are needed—and provides context about seasons and defaults. It doesn't explicitly name alternatives, but the sibling tool names and the tool's specific focus make the use-case evident.

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

• wow_character_summaryA
  4.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the tool's safety profile. The description does not disclose any additional behavioral traits such as rate limits, authentication requirements, or edge-case behaviors, but it does not contradict 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.

  Conciseness5/5

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

  The description is concise and well-structured: a one-sentence summary of what the tool does, followed by clear Args and Returns sections. Every sentence provides value, with no fluff or repetition of schema fields.

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

  Completeness5/5

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

  The description is complete for a simple read tool with two parameters: it lists the returned profile fields, explains parameter formats, and points to related tools for more details. The existence of an output schema and annotations further reduces the need for the description to explain return structures or safety.

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

  Parameters5/5

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

  With schema description coverage at 0%, the description takes on the responsibility of explaining parameters. It adds concrete meaning by giving examples for realm ('Twisting Nether' or 'twisting-nether') and specifying that character is case-insensitive, going beyond the bare schema.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: 'Get the headline profile for a character' and enumerates the specific fields returned (level, class, spec, race, etc.). It distinguishes itself from sibling tools by naming alternatives for gear and Mythic+ detail.

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

  Usage Guidelines5/5

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

  The description provides explicit usage guidance by instructing to 'Call wow_character_equipment or wow_character_mythic_keystone for gear and Mythic+ detail,' which clearly differentiates when to use this tool versus its siblings. It also gives parameter usage examples for realm and notes character names are case-insensitive.

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

• wow_find_realmA
  4.6/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds the return shape ('Up to 10 matching realms as {name, slug} pairs') and region scoping, which are useful behavioral details beyond what annotations provide.

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

  Conciseness5/5

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

  The description is compact, front-loaded with the purpose, then organized into usage, args, and returns. Every sentence earns its place with no wasted words.

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

  Completeness5/5

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

  For a single-parameter lookup tool with a clear output format, the description covers purpose, usage trigger, parameter semantics, and return limit. The output schema exists, but the description adds the limit and region context, making it complete.

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

  Parameters5/5

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

  The schema has zero description coverage, but the description fully defines 'query' as 'Full or partial realm name' and provides examples. This completely compensates for the schema gap.

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

  Purpose5/5

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

  The description opens with 'Resolve a realm name to the slug the other tools need,' clearly stating the verb, resource, and purpose. It differentiates from sibling character-lookup tools by focusing on realm resolution rather than character data.

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

  Usage Guidelines4/5

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

  The description gives an explicit trigger: 'Use this when a character lookup 404s, to rule out a wrong realm slug.' It does not explicitly state when not to use it or name alternatives, so it stops short of full guidance, but the context is clear.

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

• wow_character_resourceA
  5/5.0
  Behavior5/5

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

  The description discloses that the response has 'key'/'href' link objects stripped out and warns that 'achievements' and 'statistics' are very large, recommending narrower resources. These are behavioral traits beyond what the annotations (readOnlyHint, idempotentHint) already provide. No contradiction exists.

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

  Conciseness5/5

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

  The description is well-structured with Args and Returns sections, uses compact bullet-like lines, and every sentence provides essential information. There is no fluff or repetition of schema fields.

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

  Completeness5/5

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

  The description fully covers what the tool does, when to use it, parameter semantics, return behavior, and performance caveats. The output schema exists and handles return value structure, so the description need not explain that further. For a generic fallback tool, it is exceptionally complete.

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

  Parameters5/5

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

  Schema schema description coverage is 0%, so the description compensates by explaining each parameter: realm (name or slug), character (case-insensitive), and resource (allowed sub-resource paths with examples). It also adds context on resource selection, such as preferring narrower resources, which is not evident from the enum alone.

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

  Purpose5/5

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

  The description clearly states 'Fetch any other character sub-resource that has no dedicated tool,' which is a specific verb (Fetch) and resource (character sub-resource). It also distinguishes itself from dedicated sibling tools like wow_character_summary and wow_character_equipment by specifying it is for resources without a dedicated tool.

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

  Usage Guidelines5/5

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

  It explicitly says to use this tool for sub-resources that have no dedicated tool, and advises 'prefer a narrower resource where one exists.' This provides both when-to-use and when-not-to-use guidance, and implies alternatives (dedicated tools).

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