Server Quality Checklist

Tool Scores

• build_check_prerequisiteB
  3.3/5.0
  Behavior2/5

  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 only states it's a 'check', which implies read-only, but does not explicitly confirm it has no side effects, doesn't modify the character, or what kind of result it returns. It lacks any detail on error behavior, auth, or rate limits, leaving much unsaid.

  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 a single sentence, front-loaded with the core action and usage context. Every word earns its place, and it avoids redundancy or filler, 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.

  Completeness3/5

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

  The description is adequate for a narrow, simple tool: it states the purpose and when to use it. However, it lacks details on input expectations (e.g., what the character object needs) and does not disclose any behavioral nuances. The presence of an output schema reduces the need to describe return values, but the overall information is still minimal.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It only mentions 'single-feat' and 'one user-proposed choice', which vaguely maps to feat_id, but gives no guidance on the 'character' object structure or the format of feat_id. The schema shows character is an open object with additionalProperties, but the description does not clarify required fields or expected shape.

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

  Purpose4/5

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

  The description clearly states the tool performs a 'narrow single-feat eligibility check', identifying the action (eligibility check) and resource (a single feat). It distinguishes from siblings by contrasting with 'full discovery', so its purpose is specific and not easily confused with broader build tools.

  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 explicitly says 'use when sanity-checking one user-proposed choice rather than re-running full discovery', providing clear context of when to use it. It implies a lightweight, targeted scenario and distinguishes from heavier alternatives, though it doesn't enumerate specific sibling tools.

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

• rules_explainA
  4/5.0
  Behavior3/5

  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 does disclose the full-text search approach, the targeted content types (conditions, actions, glossary entries), and the inline return behavior. However, it does not state read-only status, permissions, or potential side effects, leaving some behavioral transparency gaps.

  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 a single, information-dense sentence that front-loads the verb and object, then efficiently adds search scope and the rationale for its inline behavior. Every word earns its place, with no repetition or filler.

  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?

  For a simple search/explain tool, the description covers the tool's goal, method, and key differentiator from sibling lookups, which is sufficient for an agent to select and invoke it. The output schema presumably documents return values, so the lack of return-format detail is not a gap. However, it could be more complete by explicitly naming sibling alternatives or mapping to the limit parameter.

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

  Parameters3/5

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

  The description implies the 'topic' parameter by saying 'Explain a rules topic', but it does not mention the optional 'limit' parameter or its default/value range. With 0% schema description coverage, the description only partially compensates for parameter documentation, though the two-parameter surface makes the missing 'limit' detail a moderate 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 uses the specific verb 'Explain' and identifies the resource as 'a rules topic', clearly stating what the tool does. It also distinguishes itself from sibling lookup tools by emphasizing 'a direct answer rather than a lookup requiring a follow-up call', which positions it uniquely against rules_search and rules_get_entry.

  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 explicitly frames the tool as the one to use when a direct answer is needed ('returning descriptions inline') versus a lookup that requires follow-up, giving clear context for when to use it. It does not explicitly name alternative sibling tools or state when not to use it, but the inline-vs-lookup contrast provides usable guidance.

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

• build_to_pathbuilder_exportA
  4.1/5.0
  Behavior4/5

  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 transparently explains that this is a normalize/strip pass (not a full transform), mentions dropping internal-only keys, and specifies the output envelope {success, build}. This provides useful context about what happens during the operation, though it does not cover side effects or permissions (which are likely irrelevant for a local transform).

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

  Conciseness4/5

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

  The description is front-loaded with the primary purpose in the first sentence. The second sentence adds useful implementation details but includes internal references like 'plan's Pathbuilder-schema findings' and 'Phase 1', which could be confusing without context. Overall it is reasonably concise and well-structured, with minor extra jargon.

  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?

  Given the tool's moderate complexity (one nested param, output schema present), the description is fairly complete. It covers the transformation approach, the output envelope, and the parameter's expected shape. It does not describe failure modes or edge cases, but the combination of description and output schema provides sufficient context. The internal references slightly reduce universal completeness.

  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 schema has only one parameter 'character' with no description and 0% schema_description_coverage, so the description must compensate. It does by clarifying that the character is the working representation and already follows Pathbuilder's build shape, which adds semantic meaning beyond the bare 'object' type. However, it does not detail specific required subfields, but given the permissive schema (additionalProperties true), this is reasonable.

  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 function: wrapping the working character representation into a Pathbuilder-compatible export. It distinguishes from siblings by specifying the output format (Pathbuilder) and describing the operation as a normalize/strip pass rather than a full transform, which differentiates it from tools like build_render_character_sheet or build_validate_build.

  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?

  The description implies usage when a Pathbuilder-compatible export is needed, but it does not explicitly state when to use this tool versus alternatives or mention exclusions. The context about the schema already following Pathbuilder's shape gives some situational background, but there is no direct guidance on selecting this tool over siblings.

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

• rules_relatedA
  4.1/5.0
  Behavior4/5

  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 extensively discloses behavior: exact data sourced from rule elements, handling of direct and OR-list prerequisites, and concrete examples for grants and stat_modifiers. This goes well beyond a simple 'gets related items' statement.

  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?

  Well-structured and front-loaded with the main purpose, followed by additional capabilities with concrete examples and a note on data provenance. Every sentence adds value; no filler or redundancy.

  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 comprehensively covers the tool's functionality, including edge cases like OR-list prerequisites and examples of grants/stat_modifiers. An output schema exists, so return format need not be described. The single parameter is simple and implicitly clarified.

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

  Parameters3/5

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

  Schema coverage is 0% with only the title 'Entry Id' provided. The description refers to 'a feat' and 'the item's own rule elements' but never explicitly states that entry_id is the identifier of that item. This implies meaning but doesn't fully compensate for the missing schema description.

  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?

  Clearly states it performs cross-reference traversal for a feat: what it requires and what requires it, plus grants/granted_by and stat_modifiers. This distinguishes it from sibling tools like rules_search and rules_get_entry by describing relationship traversal.

  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?

  Implied usage is clear: use when needing prerequisite relationships, grants, or stat modifiers. However, no explicit when-not-to-use or alternatives are named, so an agent may not know when to prefer this over rules_explain or rules_get_entry.

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

• build_get_level_up_choicesA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavior disclosure. It transparently explains that only two variant rules affect the output, that other valid slugs are recognized but ignored, and describes the exact effect of each relevant rule. It does not mention mutation or side effects, but the tool name implies a read-only operation.

  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 appropriately sized and front-loaded, opening with the main purpose before detailing variant rules. The dash-separated list for variant-rule edge cases is scannable, and every sentence adds meaningful information without filler.

  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 high complexity due to level-gate arrays and variant rules, and the description covers the core behaviors, variant effects, and related tool calls. The existence of an output schema reduces the need to document return values, though the character parameter structure and potential error conditions are not addressed.

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

  Parameters3/5

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

  Schema coverage is 0%, so the description must compensate. It thoroughly explains `variant_rules` and clarifies that `target_level` is the level at which unlocks are computed. However, `character` is only referenced as containing the character's class, leaving its structure underdefined even though it is a required parameter.

  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 that the tool reports what unlocks at a target level for the character's class, including specific content like feat categories, skill increases, and automatically-granted class features. This verb+resource+scope formulation distinguishes it from sibling tools by describing a consolidated level-up view.

  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 practical guidance by noting ability boosts follow core PF2e rules rather than class-specific data, and it explicitly tells the caller to use build_list_available_feats for archetype-feat slots when the free-archetype variant rule is active. However, it does not broadly contrast with all sibling tools or provide a general 'when not to use' statement.

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

• build_list_backgroundsA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the transparency burden. It discloses that trained_skills and granted_items come from specific system fields, that level is always null, and details the significant impact of include_legacy (54% legacy-flagged, still playable). This provides meaningful behavioral context beyond just 'list'.

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

  Conciseness4/5

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

  The description is moderately detailed but well-structured, with separate sections for output fields and include_legacy. The mention of `_legacy_filter_sql` is cryptic but not overly distracting, and each substantial part earns its 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?

  Given the output schema exists, the description adds important context by explaining the nested structure of trained_skills and granted_items and the legacy filter's practical implications. It covers the key aspects needed for an AI agent to use the tool correctly, though it omits potential details like ordering or pagination.

  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 coverage is 0%, but the description thoroughly explains both parameters: filter as a name substring and include_legacy's default and meaning. It also gives concrete examples of output structures, adding context beyond the 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 it 'List backgrounds' with an optional name substring filter. This specific verb+resource combination unambiguously distinguishes it from sibling tools like build_list_classes and build_list_ancestries.

  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?

  The description implies usage for retrieving background lists and references build_list_classes for comparison, but does not explicitly state when to use this tool versus alternatives or provide exclusion criteria. It explains parameter behavior but not usage scenarios.

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

• rules_get_entryA
  4.2/5.0
  Behavior3/5

  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 the entry includes 'description, traits, raw data' and that matching is by 'exact name' or slug. However, it does not state behavior for missing entries, multiple identifiers provided, or error conditions. The 'Provide exactly one' hint partially covers misuse but not edge cases.

  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 a single sentence, front-loaded with the action and resource. Every clause adds value: what is fetched, via which identifiers, and the exclusivity constraint. No filler or repetition.

  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 return values don't need description. The description covers the essential input constraint and the nature of the output. Minor gaps include not-found behavior and error handling, but the overall context is sufficient for a low-complexity fetch tool.

  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 schema has 0% description coverage, so the description must compensate. It explains that id, name, and slug are alternative selectors and that exactly one must be provided. This adds meaning beyond the raw schema (which only lists nullable properties with defaults), though it does not detail the format for each identifier.

  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 function: 'Fetch a single PF2e entry's full detail (description, traits, raw data) by id, exact name, or slug.' It uses a specific verb ('Fetch') and resource ('single PF2e entry'), and distinguishes from siblings like rules_search by emphasizing 'single' and 'full detail'.

  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 provides clear usage context: it fetches a single entry by exactly one of three identifiers, with the explicit constraint 'Provide exactly one of the three.' However, it does not explicitly mention when to prefer this over alternatives like rules_search or rules_related, so it misses the 'when-not' guidance for a 5.

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

• build_list_ancestriesA
  4.3/5.0
  Behavior4/5

  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 a key behavioral trait: legacy-flagged ancestries are excluded by default, and explains that 38% are still playable. This goes beyond a simple 'list' and arms the agent with important context, though it omits minor details like sorting or response format.

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

  Conciseness4/5

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

  The description is moderately sized and front-loaded with the main purpose. The detailed explanation of include_legacy is valuable, but the internal reference 'See `_legacy_filter_sql`' is an implementation detail that adds little for an agent. Overall, it is concise and well-structured, earning a high score.

  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?

  Given the tool's simplicity (2 params, no nested objects) and the presence of an output schema (so return values need not be explained), the description is complete. It covers the primary purpose and the non-obvious legacy behavior, which is sufficient context for an agent to invoke this tool correctly.

  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?

  Schema description coverage is 0%, but the description compensates: 'filter' is clarified as a name substring, and 'include_legacy' is explained in depth, including its default behavior and the 38% legacy-flagged ancestries. This adds meaning beyond the bare schema types, though it doesn't provide explicit syntax or examples for the filter parameter.

  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 function: 'List playable ancestries, optionally filtered by name substring.' This specifies the verb (list), resource (playable ancestries), and optional filtering. It distinguishes itself from sibling tools like build_list_backgrounds and build_list_classes by focusing specifically on ancestries.

  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 provides clear context for when to set the include_legacy parameter, advising to set it True when the user wants the full catalog. It does not explicitly mention alternative tools or exclusions, but the tool's purpose and siblings make selection obvious, and the parameter guidance is a useful decision point for the agent.

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

• rules_data_versionA
  4.3/5.0
  Behavior4/5

  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 fully states the output (which release the database was built from) and implies no side effects. As a read-only reporting tool, this is transparent and sufficient.

  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 a single concise sentence that conveys the exact action and result with no wasted words. It is optimally structured and front-loaded.

  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?

  This is a trivial tool with no parameters and an output schema available. The description is complete for understanding what the tool does and what it returns, requiring no additional context.

  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 tool has zero parameters, so per the rubric baseline is 4. The description adds no parameter information because there are none to explain, which is appropriate.

  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 'Report' and clearly identifies the resource (foundryvtt/pf2e release) and scope (current rules database). It distinctly separates this tool from sibling search/build tools, which all focus on querying or manipulating rules data.

  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?

  The description implies its use when needing to know the database version, but there is no explicit guidance on when to use it vs alternatives or any exclusions. It is self-evident enough for a simple version query, but lacks explicit context.

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

• rules_searchA
  4.3/5.0
  Behavior4/5

  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 does this well by explaining the default legacy filter behavior, the nuance that 'is_remaster: false' does not mean 'retired,' and even provides statistical context (54% of backgrounds, 38% of ancestries). It stops short of explicitly stating read-only behavior or pagination, but the search nature makes that largely implicit.

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

  Conciseness4/5

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

  The description is structured into a concise summary paragraph and a detailed note on the critical include_legacy parameter. The second paragraph is lengthy but earns its place because the legacy filter nuance is genuinely non-obvious and decision-relevant. No filler sentences are present, though the reference to 'licensing.legacy_filter_sql' is slightly technical.

  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 description covers the tool's primary behavior, return format, sibling-tool differentiation, and the most important filter nuance. It also points to an output schema for raw data. It does not explicitly describe limit behavior or pack/type filtering, but those are straightforward from the schema. Given the tool's search nature and the presence of an output schema, this is a quite complete description.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description must compensate. It thoroughly explains include_legacy: its default, its effect, and when to change it. However, the description does not add meaning for query, pack, type, or limit; those rely on their names and schema titles. While include_legacy is the most complex parameter, the others are left entirely to the schema, leaving partial compensation.

  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 a specific verb and resource ('Full-text search over PF2e rules content') and clearly states what it returns ('compact summaries (id/name/pack/type/level/category)'). It also distinguishes itself from the sibling tool by explicitly directing users to rules_get_entry for full data, eliminating ambiguity about its scope.

  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 guidance on when to use this tool versus an alternative ('call rules_get_entry with an id for the full description and raw data'), and it gives a clear rule for when to set include_legacy=True ('whenever the user wants the full catalog'). This is exactly the kind of when-to-use/when-not-to-use context the rubric asks for.

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

• build_list_equipmentA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the disclosure burden. It reveals that STARTING_WEALTH_GP is returned alongside results as a reminder, explains the default behavior of include_legacy, and references the legacy filter SQL, adding transparency about filtering behavior.

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

  Conciseness4/5

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

  The main purpose is stated in one sentence, followed by context about starting wealth and a parameter detail. The reference to `_legacy_filter_sql` could be trimmed, but the description remains focused and front-loaded.

  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 tool is a simple list operation with an output schema. The description covers filtering, default behavior, and the starting wealth caveat, making it sufficient for an agent to select and invoke correctly.

  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 0% schema description coverage, the description compensates by naming the filter criteria ('name substring, item type, and/or maximum price') and explicitly explaining include_legacy's default and meaning. All four parameters are effectively documented.

  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 states 'Browse the equipment pack (weapons, armor, shields, gear) by name substring, item type, and/or maximum price.' This clearly identifies the resource (equipment) and the verb (browse), and distinguishes it from sibling tools that list other character options like ancestries or classes.

  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 does not explicitly mention alternatives, but the context of sibling tools (e.g., build_list_ancestries, build_list_classes) makes it clear this is for equipment. It also sets expectations for use during character building by referencing starting wealth and legacy filtering.

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

• build_calculate_derived_statsA
  4.6/5.0
  Behavior5/5

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

  With no annotations, the description carries full burden and delivers extensively. It discloses the deterministic nature, the AC calculation basis (armor vs unarmored, potency rune), and a deep explanation of fallback behavior for missing HP/AC fields, including a real-world example of silent wrong results. This goes far beyond typical transparency.

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

  Conciseness4/5

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

  The description is front-loaded with a clear statement, then logically organized into AC specifics and a detailed fallback explanation. It is longer than average, and the fallback paragraph is verbose, but every sentence carries important technical nuance. Not maximally concise, but not bloated either.

  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 output schema is present, so return values needn't be explained. The description covers major inputs, edge cases, and limitations. It does not list all required character fields (e.g., ability scores, level), but given the tool is clearly PF2e-specific and the schema is open, the provided field references give strong context. A small gap remains for a fully self-contained spec.

  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 input schema is nearly empty (one generic object with additionalProperties). The description compensates by referencing concrete fields like 'armor', 'attributes.ancestryhp', 'attributes.classhp', 'proficiencies.unarmored', 'ancestry', and 'class', explaining their role and even the nuanced absent-vs-zero behavior. This gives an agent essential guidance for constructing a correct 'character' object.

  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 first sentence clearly states the tool's scope: 'Deterministic PF2e math: AC, saves, Perception, skill totals, HP, class DC, and spell DC/attack per casting tradition...' This is a specific verb+resource+output list, and it distinguishes the tool from sibling build_* list/validate/render tools. No ambiguity about what it does.

  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 clear context (compute derived stats for a PF2e character) and explicitly notes a limitation: 'Does not yet include a raised shield's bonus'. This tells the agent when not to rely on it. However, it does not name alternative tools or explicitly say 'use this instead of manual arithmetic' in a way that contrasts with siblings. The context is clear but exclusions are minimal.

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

• build_list_classesA
  4.6/5.0
  Behavior5/5

  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 extensively discloses behaviors: the 0/2/4/6/8 proficiency rank convention, the fact that this is 'baseline only' excluding subclass/later features, the no-op status of include_legacy, and detailed caveats about the trained skills count. This is exemplary transparency.

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

  Conciseness4/5

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

  The description is long but structured with clear paragraphs and bold text, front-loading the core purpose before diving into caveats. While some internal details like `_legacy_filter_sql` and the Magus anecdote could be trimmed, the length is justified by the complexity of the output semantics.

  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?

  Given the complexity of the tool and the presence of an output schema, the description covers the necessary behavioral context: the meaning of the returned proficiency ranks, the baseline vs. subclass distinction, the trained skills calculation gotcha, and the parameter semantics. It leaves little ambiguity for an agent to misuse the tool.

  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?

  Schema coverage is 0%, so the description must explain the parameters. It adequately describes `filter` as a name substring, and it thoroughly explains `include_legacy` including its default, its current no-op status, and the reason for its existence. Although `filter` lacks details like case sensitivity, the description adds meaning far beyond the empty 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 opens with 'List classes, optionally filtered by name substring', which clearly states the verb and resource. It further specifies that it returns level-1 proficiency baselines and distinguishes itself from generic list tools by noting the data source. The purpose is specific and distinguishes from sibling list tools.

  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 provides clear context on when to use this tool: for obtaining class baseline stats for a draft character, with a caution that it does not account for doctrine/subclass choices or later automatic features. It also explains that the caller must add the Intelligence modifier to `trained_skills.additional`, which is a usage directive. However, it does not explicitly name alternative tools for those other needs, so it falls short of fully explicit alternative selection.

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

• build_list_available_spellsA
  4.7/5.0
  Behavior5/5

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

  With no annotations, the description fully discloses the tool's behavior: rank cap resolution order, fallback logic, spell_slots null semantics, cantrip tagging, and the include_legacy flag effect. It even explains the discrepancy in source data leveling for cantrips.

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

  Conciseness4/5

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

  The description is quite long and dense, but it is organized into logical paragraphs with clear topics. While every sentence adds value, it could be more concise without losing important edge case details.

  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 covers all key behaviors, including edge cases like Magus/Summoner non-monotonic progression and legacy filtering. With an output schema present, the description sufficiently explains the tool's overall functionality and return semantics.

  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%, and the description compensates by explaining max_rank precedence, include_legacy default, and character class usage. It also clarifies how tradition and character interact, giving meaning 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 lists available spells for a given tradition based on rank, and also provides spell slot counts. It distinguishes itself from sibling tools by focusing on spells and slot data, with explicit references to class progression and cantrip handling.

  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 provides significant usage context, explaining when max_rank is needed, when the class's own slot table applies, and when the fallback heuristic is used. It does not explicitly name alternative tools, but clearly defines the scenarios this tool is designed for.

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

• build_list_skill_increase_optionsA
  4.7/5.0
  Behavior4/5

  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 discloses a key behavioral limitation: it does not consult skillIncreaseLevels itself, and it clarifies the fixed caps rule. However, it does not explicitly state that it is a read-only operation, though this is implied by 'list'.

  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?

  Two sentences, front-loaded with the main purpose, and each sentence adds valuable context. No redundancy or fluff.

  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?

  Given that the tool has an output schema, the description does not need to explain return values. It covers the core rule, the limitation, and the relationship to a sibling tool, making it complete for a list-like tool with good annotations.

  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?

  With one parameter 'character' that has no schema description, the description compensates by indicating that the character's current level and current ranks are required. It does not detail the full object structure, but the key inputs are identified.

  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 what the tool does: lists which of the 16 core skills can be legally raised by one rank given current level and ranks. It distinguishes itself from build_get_level_up_choices by explicitly naming that as the confirmation 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?

  Provides explicit guidance on when to use this tool (to list legal skill increases) and when not to (to confirm availability, use build_get_level_up_choices). Also explains the fixed caps rule, clarifying that it applies regardless of class.

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

• build_validate_buildA
  4.7/5.0
  Behavior5/5

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

  With no annotations, the description carries the full burden and delivers thoroughly. It explains the error/warning distinction, details each validation check, describes how variant_rules changes behavior, notes the soft/non-blocking nature of some warnings, and discloses limitations (e.g., no ability-boost double-up check, no spellcasting proficiency). It even provides rationale for scoping decisions (e.g., fixed trained skills warning).

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

  Conciseness4/5

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

  The description is very long and includes parenthetical references to internal function names and docstrings, which adds noise. However, it is front-loaded with the main purpose and logically organized: validation categories first, then variant rules and parameter effects. Most sentences add meaningful information, but it could be tightened by removing some internal implementation details.

  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 tool has 3 parameters, one nested object, and an output schema, yet the description covers all key aspects: return types (errors/warnings), validation scope, parameter effects, limitations, and even the distinction from Foundry's implementation. It is complete enough for an agent to use correctly without additional lookups, despite the moderate complexity.

  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 must compensate. It does so excellently: it explains variant_rules values ('ancestry-paragon', 'free-archetype') and their effects, and describes pfs_legal_only semantics with caveats. The 'character' parameter's meaning is inherently clear from the tool's purpose. Nearly all parameter intent is covered.

  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 validates builds and returns structured errors and warnings. It enumerates specific validation categories (duplicate feats, prerequisites, skill caps, ancestry budget, archetype dedication, etc.), which distinguishes it from sibling tools like build_check_prerequisite. The verb-resource pair is explicit: 'build_validate_build' validates a character build.

  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 strong context on when the tool is appropriate (full build validation) and lists limitations ('Does NOT yet check...'), but it does not explicitly name alternatives or say 'use this when validating an entire build'. The scope is clear, though exclusions for alternative tools are implicit rather than explicit.

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

• rules_list_subclass_option_groupsA
  4.7/5.0
  Behavior4/5

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

  Since no annotations are provided, the description carries the full burden. It discloses the scope ('every...found in the ingested data'), the grouping ('one tag family per class'), and the data source ('exact GrantItem data, not parsed from prose'). While it implies a read-only list operation, it does not explicitly state that it has no side effects or other behavioral constraints.

  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 moderately long but every sentence earns its place: it gives the purpose with examples, clarifies the grouping and importance, differentiates from a sibling, and provides forward guidance. It is front-loaded with the main action and uses concrete examples throughout without redundancy.

  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 zero-parameter list tool with an output schema, the description is complete. It describes what is returned, why the tool is needed, how it relates to other tools, and what to do next. It even notes the data source and the 'grants' field behavior without over-explaining since the output schema exists.

  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 tool has zero parameters, and the schema coverage is 100% (trivially), so the baseline is 4. The description adds useful context by explaining that the output tags are intended as inputs to `rules_list_subclass_options`, but since there are no parameters, there is nothing more to clarify.

  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 a specific verb+resource: 'List every subclass-style choice-group tag found in the ingested data', followed by concrete examples. It clearly distinguishes itself from siblings by explicitly contrasting with `build_list_classes` and pointing to `rules_list_subclass_options` as the next step.

  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 explicitly states when to use this tool: 'nothing else in this server can enumerate them', and provides an alternative exclusion: `build_list_classes` only returns a flat baseline. It also gives direct usage instructions by telling the caller to invoke `rules_list_subclass_options` with a returned tag.

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

• rules_list_subclass_optionsA
  4.7/5.0
  Behavior5/5

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

  With no annotations provided, the description fully covers behavioral details. It explains exact tag matching with a concrete example, the return format (full entries including grants and stat_modifiers), and that these fields come from structured GrantItem/ActiveEffectLike data, not prose. This is highly transparent.

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

  Conciseness4/5

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

  The description is front-loaded with the core action, then provides necessary rationale and return details. It is longer than the ideal two-sentence summary, but each clause adds value, and the structure is logical and free of filler.

  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 tool with one parameter, no schema descriptions, and no annotations, the description is remarkably complete. It covers what the tool does, how to use it correctly, what the output contains, and why the design choices were made. The existence of an output schema means the return structure is already documented elsewhere.

  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 only defines 'tag' as a string with no description. The description compensates by explaining what a valid tag is, pointing to the sibling group tool, and illustrating why exact matching matters with real tag examples. This adds significant meaning beyond the 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 lists every option in a subclass-style choice group by exact tag, distinguishing it from the sibling rules_list_subclass_option_groups. It also specifies that it returns full entries rather than summaries, further clarifying its unique role.

  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 explicitly references rules_list_subclass_option_groups for valid tag values and explains why exact matching is necessary to avoid missing groups. It warns against guessing class-name-based filters, providing clear context. It does not explicitly state when not to use the tool, but the guidance is strong.

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

• build_list_ability_boost_optionsA
  4.8/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden and it does so excellently. It discloses exactly which data sources are respected (ancestry flaws, Pathbuilder's breakdown field), what is not yet checked (the two-free-boosts rule), and what is delegated elsewhere. This is transparent about the tool's internal logic and limitations.

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

  Conciseness4/5

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

  The description is somewhat long but every clause carries important information. It front-loads the core purpose, then adds caveats and redirects. No filler words or redundant statements, but it could be slightly tightened without losing meaning.

  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?

  Given the complexity of ability boost rules and the presence of an output schema, the description is sufficiently complete. It explains the source parameter, the integration with Pathbuilder's breakdown, the known exception not handled, and points to validate_build for full cross-source validation. This gives an agent all necessary context to decide whether and how to invoke the tool.

  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?

  Schema description coverage is 0%, so the description must compensate for the parameter meanings. It explains that 'source' is one of the enum values and clarifies how 'character' is used (specifically its abilities.breakdown field). This adds significant meaning beyond the bare schema, though it doesn't describe the full structure of the character object.

  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 states exactly what the tool does: lists eligible ability score boosts for a given source. It names the specific resource (ability boost options), the input (source), and the constraints (ancestry flaws, recorded boosts). This clearly distinguishes it from sibling tools like build_list_skill_increase_options or build_list_available_feats.

  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 explicitly says when to use this tool (for a single source's boosts) and when not to use it (for full multi-source interaction), pointing to validate_build as the alternative. It also notes the known limitation about the 'two free boosts' rule, giving clear usage boundaries.

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

• build_render_character_sheetA
  4.8/5.0
  Behavior5/5

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

  No annotations are provided, but the description thoroughly discloses behavior: output is written to disk and not returned, fonts are inlined, deity statuses have three distinct cases, unresolved items are reported, and logo embedding follows licensing constraints. This is exemplary transparency.

  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?

  Although long, every paragraph earns its place by covering a distinct aspect: output format, section list, deity handling, parameter details, and return value. The structure is front-loaded with the core purpose and flows logically, making it easy to navigate despite the length.

  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?

  Given the tool's complexity and the absence of annotations, the description is exceptionally complete. It covers behavior, edge cases, parameter semantics, and the return dict, leaving little room for misinterpretation. It even explains why certain data might be missing and how to interpret warnings.

  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 input schema has zero parameter descriptions, yet the description explains every parameter in depth: character, output_path, paper (letter/a4 defaults), logo_path (accepted formats, scaling behavior), and symbol_dir (matching rules). It fully compensates for the schema's lack of guidance.

  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 first sentence clearly states the tool's purpose: to write a print-ready, self-contained HTML character sheet and return a summary. This specific verb+resource formulation distinguishes it from sibling tools like build_to_pathbuilder_export or build_validate_build.

  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 provides rich context on when to use the tool (e.g., sending a printable sheet to a player) and highlights important caveats before calling (e.g., lack of spellCasters means no spell pages). It does not explicitly name alternative tools, but the use-case is clear enough.

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

• build_list_available_featsA
  4.9/5.0
  Behavior5/5

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

  With no annotations provided, the description carries full burden and excels. It discloses the two output buckets ('available' vs 'unconfirmed'), the rule that unconfirmed feats are never silently included, and the omission of failing/owned feats. It also honestly notes that pfs legality is 'best-effort' and 'not authoritative,' and explains the archetype data anomaly in detail.

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

  Conciseness4/5

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

  The description is long but well-structured and front-loaded with the core purpose. Each paragraph addresses a distinct aspect: output buckets, filtering logic, archetype special case, and return metadata. Some redundancy exists (e.g., restating PF2e rules context), but for the tool's complexity, the length is justified and every major section adds value.

  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?

  Given the tool's complexity, the description is remarkably complete. It covers output semantics, filtering edge cases, category-specific behavior, legacy filtering, and added metadata. The presence of an output schema reduces the need to explain return values, but the description already covers what appears in each entry (rarity, pfs status). It fully equips an agent to decide when and how to invoke this tool.

  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 must compensate. It explains level defaults to character's current level, feat_category includes the special 'archetype' handling, and include_legacy default behavior is described. The character parameter is implied through repeated references to 'character's own class/ancestry' and 'current level,' providing enough context for an agent to understand its role.

  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 a specific verb and resource: a 'token-saving discovery tool' that 'returns only feats of the requested category at or below the target level whose prerequisites the character already meets.' This clearly distinguishes it from sibling tools like rules_search and build_check_prerequisite by emphasizing its filtering and token-saving role.

  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 states when to use the tool: instead of reasoning over the full feat list or raw rules text. It also provides when-not guidance by explaining that feats failing prerequisites or already owned are omitted, and that archetype feats are queried via trait within class/skill categories. Special cases like class/ancestry restrictions and include_legacy behavior are thoroughly covered.

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

• rules_list_variant_rulesA
  5/5.0
  Behavior5/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It reveals that the tool returns compact summaries, supports a category filter, and currently provides mechanical support only for Free Archetype and Ancestry Paragon while the rest are reference text only. This sets accurate expectations about scope and limitations.

  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 detailed yet every sentence earns its place: content scope, examples, return type, pointer to the alternative tool, parameter semantics, and current mechanical support status. It is well-structured and front-loaded with the primary purpose, with no unnecessary 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?

  Given the tool's simple one-parameter surface and the existence of an output schema, the description covers all essential user-facing aspects: what is returned, how to filter, when to use alternatives, and current limitations. No critical usage information is missing.

  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 0% description coverage for the only parameter `category`, but the description fully compensates by defining the two filter values ('character-building' and 'subsystem') and explaining that omitting the parameter shows both. This makes the parameter's meaning and default behavior completely clear.

  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 'Browse' and a resource 'optional/variant character-building and subsystem rules', enumerating concrete examples like Free Archetype and Ancestry Paragon. It explicitly distinguishes itself from sibling tools by directing users to rules_get_entry for full text and noting where mechanical support lives in build tools.

  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 clearly states when to use this tool (browsing summaries) and when to call rules_get_entry for full official text. It also explains the category filter context ('ask about these when starting a new character') and names alternative tools for mechanical support, giving explicit when-not guidance.

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