Server Quality Checklist

Tool Scores

• analyze_deckC
  2.3/5.0
  Behavior2/5

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

  No annotations are provided, so the description must disclose behavioral traits like whether this tool is read-only, destructive, has side effects, requires authorization, or has rate limits. The description only says it stores structural metrics, which implies a write operation, but it does not explain persistence, idempotency, or what happens to existing data. This is insufficient for a tool that accepts a complex request with nested objects.

  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 brief (one short sentence). While it is efficient, it omits critical information that could be added without much more text. It earns a 4 for being concise, not verbose.

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

  Completeness2/5

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

  Despite having an output schema and a single parameter, the tool is conceptually complex (involves scenarios, win packages, score definitions) and has many sibling tools. The description does not explain the return format, how the analysis is performed, what constitutes 'evidence-backed metrics', or how the output relates to the input. The tool is under-described for its complexity.

  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%, meaning the description must add meaning to the parameters, but it does not. The input schema defines a single 'request' parameter containing multiple nested objects (ScenarioInput, WinPackageInput, ScoreDefinitionInput, etc.), yet the description offers no explanation of how these fields relate to the analysis or what values they accept. For a complex tool with one parameter that is a nested object, this is a significant gap.

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

  Purpose3/5

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

  The description includes a verb (Store) and a resource (structural metrics, no scalar power score), which suggests the tool persists or records analysis results. However, the meaning of 'evidence-backed structural metrics' and 'without a scalar power score' is vague and does not clearly distinguish this from sibling tools like 'check_deck' or 'plan_deck'. The score is 3 because it indicates what the tool does but lacks specificity.

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

  Usage Guidelines1/5

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

  There is no guidance on when to use this tool versus alternatives such as 'check_deck', 'plan_deck', or 'compare_decks'. The description does not explain prerequisites, expected input context, or conditions under which this tool is appropriate. This is a critical gap given the complex input schema with nested objects.

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

• price_purchasesC
  2.4/5.0
  Behavior2/5

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

  No annotations are provided, so the description must carry the full burden. It only mentions that pricing does not add to cart or buy, but lacks details on authentication, rate limits, side effects, or output format. The presence of an output schema is not leveraged.

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

  Conciseness3/5

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

  The description is a single sentence, so it is concise. However, it is too short for the tool's complexity; conciseness should not come at the expense of completeness.

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

  Completeness1/5

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

  Given the complex nested input schema, the lack of annotations, and no output schema documentation, the description is woefully incomplete. The agent would not know how to properly construct the request or interpret results.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description does not explain any parameters. The agent must guess the meaning of fulfillment_plan_id, provider_id, and the nested policy object with its fields (currency, accepted_finishes, etc.). This is a critical gap.

  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 verb 'price' and resource 'unresolved purchases', and distinguishes the action from adding to cart or buying. However, 'unresolved purchases' is somewhat vague and could be more specific.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives (e.g., create_fulfillment_plan), prerequisites, or when not to use it. The description is purely functional.

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

• resolve_availabilityC
  2.4/5.0
  Behavior2/5

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

  With no annotations provided, the description bears full responsibility for behavioral disclosure. It only reveals that the tool does not reserve copies. Missing are details on whether it modifies any data, required permissions, side effects (e.g., caching), limitations (e.g., only checks against a specific collection), or rate limits. The single behavioral trait is helpful but insufficient.

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

  Conciseness3/5

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

  The description is a single short sentence, which is concise but comes at the expense of necessary detail. It lacks structure such as bullet points or sections. While every word earns its place, the description is underspecified for practical use, earning an average score.

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

  Completeness2/5

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

  Despite having an output schema and one parameter (with complex internals), the description fails to explain how the tool is used in practice. It does not address the input's nested structure, the meaning of 'substitutes', or what the output contains. An agent would struggle to form a correct request without additional context.

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

  Parameters1/5

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

  Schema description coverage is 0%. The description does not mention any parameters or explain what 'ResolveAvailabilityRequest', 'collection_id', 'substitutes', etc., represent. The complex nested structure with arrays and enums (e.g., 'proxy_policy' likely has valid values) is entirely undocumented in the description. This leaves the AI agent with no guidance beyond raw schema names.

  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 action ('resolve complete decks against physical copies') and adds a critical constraint ('without reserving them'). It distinguishes this tool from sibling tools like create_fulfillment_plan and price_purchases, which involve reservations or purchases. However, 'resolve' is somewhat abstract and could be more explicit (e.g., 'check availability').

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. For example, it does not indicate whether this tool should be used before creating a fulfillment plan or after loading a deck. No exclusions or context are given.

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

• search_libraryC
  2.4/5.0
  Behavior2/5

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

  With no annotations, the description must convey all behavioral traits. It hints at a privacy feature (not disclosing contents in summary), but omits whether this is a read-only operation, what other side effects exist, or any required permissions. The agent is left to infer safety and behavior from the name alone.

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

  Conciseness3/5

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

  The description is a single sentence, which is concise, but it is under-informative. It earns its place by adding the disclosure constraint, yet it omits crucial details that could be added without significant bloat. Balance between brevity and completeness is off.

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

  Completeness2/5

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

  Given the tool has 4 parameters, 2 required, and an output schema present, the description is incomplete. It fails to cover usage context, parameter roles, or differentiation from siblings. The output schema may define return structure, but the description does not help the agent understand when or how to invoke this tool effectively.

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

  Parameters1/5

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

  Schema description coverage is 0%, so the description should explain parameters. It does not. 'snapshot_id' and 'query' are required but their meaning is entirely left to the schema title fields, which provide no context. The description adds no parameter-specific information.

  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's action: 'Search a stored collection'. It adds a distinguishing behavioral note about not disclosing contents in the summary. However, 'stored collection' is somewhat vague and doesn't explicitly contrast with sibling tools like 'search_cards' or 'load_collection_snapshot'.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus its siblings. The description does not mention scenarios, prerequisites, or alternatives. An agent has no context to decide between 'search_library' and 'search_cards' or other search/load operations.

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

• load_collection_snapshotC
  2.6/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. It states the tool 'normalizes' and creates an 'immutable snapshot', implying a read-only transformation, but does not disclose potential side effects (e.g., does it modify the original file? Consume significant memory? Require specific permissions?). The term 'supported' is left undefined.

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

  Conciseness3/5

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

  Extremely concise at 8 words, but overly terse. Lacks contextual sentences that would help the agent understand usage (e.g., supported formats, snapshot benefits). Edge cases like not providing any parameter details make it under-specified rather than efficiently written.

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

  Completeness2/5

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

  Given the complexity (5 parameters, output schema exists) and no annotations, the description is incomplete. The output schema exists but the description doesn't hint at what the snapshot contains (e.g., card objects? aggregated data?). Required distinction from 'load_deck' or 'search_library' is missing. Agent would likely misuse the tool without external knowledge.

  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%, meaning the description adds zero meaning beyond parameter names and types. For example, 'mapping' parameter is described only by schema (object mapping strings to strings) with no context on what it maps (e.g., field names? column indexes?). 'allow_partial' defaults to false but the description never explains partiality. The description does not compensate for the low schema coverage.

  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 uses a specific verb ('Normalize') and resource ('local collection file'), clearly stating the output ('immutable snapshot'). It distinguishes this from siblings like 'load_deck' by emphasizing the 'collection' context.

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

  Usage Guidelines2/5

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

  No guidance on when to use this tool versus alternatives (e.g., search_cards, load_deck, analyze_deck). The description does not mention prerequisites (e.g., file must exist locally, supported format) or what 'supported' means.

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

• load_deckC
  2.7/5.0
  Behavior3/5

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

  Since annotations are missing entirely, the description carries the full burden for behavioral disclosure. It states a key behavioral trait: the tool does not treat the deck as evidence of ownership, which implies it is a safe, non-destructive operation. However, it fails to describe side effects, authorization needs, or what happens with invalid input. The output schema exists but the description does not reference return behavior, leaving gaps.

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

  Conciseness4/5

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

  The description is a single, concise sentence with no extraneous content. It front-loads the core action ('normalize deck text') and adds a key discriminator. While brief, it earns its place by being focused.

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

  Completeness2/5

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

  Given the tool has 3 parameters with 0% schema description coverage, an output schema (which could document return values), and a complex sibling set, the description is too sparse. It does not explain the normalization process, input requirements, output structure, or how this differs from similar tools like 'check_deck'. Substantial gaps remain for the 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.

  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 for documenting parameters. It mentions none of the three parameters ('text', 'label', 'format') explicitly. 'text' and 'label' are required but their purpose is only inferred from the tool's context. The 'format' parameter has a default but no explanation of its role. This is a significant gap.

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

  Purpose3/5

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

  The description 'Normalize deck text without treating it as evidence of ownership' uses a specific verb ('normalize') and identifies the resource ('deck text'). However, the phrase 'without treating it as evidence of ownership' is ambiguous and does not clearly differentiate this tool from siblings like 'check_deck' or 'analyze_deck'. The lack of clarity on what 'normalize' means reduces the score.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives like 'check_deck' or 'analyze_deck'. The description implies a specific constraint (not treating as evidence) but does not explain what that means for usage. No exclusion criteria or context signals (e.g., prerequisites like deck format constraints) are given.

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

• check_deckC
  2.8/5.0
  Behavior2/5

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

  With no annotations provided, the description bears full responsibility for disclosing behavioral traits. It states 'without inferring bracket fit' but fails to explain whether the tool is read-only, what permissions it requires, what side effects exist, or the nature of its return value. For a legality-checking tool, this is insufficient.

  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 a single, front-loaded sentence that wastes no words. It efficiently communicates the purpose without fluff. However, it is perhaps too concise—adding a brief sentence about input or output could improve it without sacrificing conciseness.

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

  Completeness2/5

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

  Given the complexity of the input schema (nested objects with many properties) and the presence of an output schema, the description is too sparse. It does not explain what the output represents (pass/fail, detailed violations), what 'bracket fit' means in context, or note any prerequisites like authentication or specific game format. The tool is moderately complex but the description covers almost none of the needed context.

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

  Parameters1/5

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

  The input schema has 0% description coverage for parameters, and the tool description adds no information whatsoever about the 'request' object or its nested properties. The agent receives no guidance on how to construct the required input (e.g., deck_id, scenario), making parameter understanding entirely reliant on the schema structure 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 uses the specific verb 'Check' and identifies the resource as 'deck construction legality', clearly stating the tool's core function. It further distinguishes itself by noting 'without inferring bracket fit', which sets it apart from potential sibling tools like analyze_deck or plan_deck that might involve inference. This makes the purpose unambiguous and differentiated.

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

  Usage Guidelines2/5

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

  There is no explicit guidance on when to use this tool versus alternatives. The description hints at a distinction ('without inferring bracket fit') but does not specify situations where this tool is preferred over analyze_deck, plan_deck, or others. No alternatives are named, nor are when-not scenarios provided.

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

• plan_deckC
  2.9/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 transparency. It discloses only that candidates must be 'complete' and between 'one to eight', but it does not mention side effects, read-only status, permissions, or what the evaluation returns. This is a minimal disclosure for a complex tool.

  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 of eight words, stating the action and key constraints with no redundant or extraneous information. It is highly concise and front-loaded with the main verb.

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

  Completeness1/5

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

  Given the extremely complex input schema and the presence of an output schema, a one-sentence description is wholly inadequate. It does not explain what a 'candidate' is, what the evaluation entails, or how the tool fits into the overall workflow, making it insufficient for an agent to understand and use the tool correctly.

  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 adds a meaningful constraint on the 'candidates' parameter by specifying 'one to eight' and requiring completeness, which the schema itself does not enforce. However, it gives no details about the many other fields in the 'request' object, leaving the agent to rely solely on the schema structure and names.

  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 uses the verb 'Evaluate' with a specific resource ('candidates') and a scope ('one to eight'), making the core action understandable. However, it does not clarify that these are deck candidates or that the tool produces a plan, which would distinguish it from sibling tools like analyze_deck or compare_decks.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It neither explains prerequisites, exclusions, nor mentions any competing tools, leaving the agent without contextual selection cues.

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

• search_cardsB
  3.1/5.0
  Behavior3/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 mentions 'bounded pagination' (adding behavioral context) but doesn't disclose if it's read-only, what happens to the returned data, rate limits, or authentication needs. The description adds some value beyond nothing.

  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 a single sentence with no wasted words. It could be slightly longer to add param context, but it remains concise and front-loaded with the key action.

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

  Completeness2/5

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

  With 5 parameters, 0% schema coverage, no annotations, and an output schema present, the description is too sparse. It leaves the agent guessing about param semantics, return structure (despite output schema existing), and behavioral boundaries.

  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 'bounded pagination', hinting at limit/offset, but gives no meaning for query, type_contains, color_identity, or how they interact. This is insufficient for 5 parameters.

  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 states it searches a card catalog with bounded pagination, which is a specific verb-resource combination. It distinguishes from sibling tools like search_library by mentioning 'verified local card catalog', though it doesn't explicitly differentiate from all siblings.

  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 searching cards with pagination but provides no guidance on when to use this tool vs siblings like search_library or load_collection_snapshot. No exclusion or alternative context is given.

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

• compare_decksB
  3.4/5.0
  Behavior4/5

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

  The description discloses a key behavioral trait: it does not produce a scalar score. Since no annotations are provided, the description carries the full burden of behavioral transparency. It also hints at a comparison output (likely showing differences or side-by-side). However, it does not explain what the output format looks like, whether it's read-only or has side effects, or how it handles invalid or missing IDs.

  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 a single concise sentence that packs key information: action, item count range, items compared, and what is NOT done (no scalar scoring). It is front-loaded and efficient. However, given the complexity of the tool and the 0% schema coverage, a slightly longer description might add necessary clarity without being verbose.

  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 tool has 1 parameter with 0% schema coverage, no annotations, and an output schema exists (but its content is not shown). The description provides the count constraint and item type, but fails to explain what the output contains (e.g., a comparison table, list of differences), how conflicts are resolved (e.g., if IDs are invalid), or whether the tool is read-only. Given the complexity of comparing multiple decks, the description is somewhat incomplete.

  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?

  There is a single parameter 'deck_or_plan_ids' with a type of array of strings. Schema description coverage is 0%, so the description must compensate. The description says 'compare two to eight raw decks or plan winners', which adds the constraint of min/max count (2-8) and the types of strings ('deck_or_plan_ids' → decks or plan winners). However, it does not specify the format of each ID (e.g., should they be full IDs or partial?), whether the order matters, or how mixed types (e.g., both deck and plan IDs) are handled.

  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 uses specific verbs ('compare', 'without scalar scoring') and names the resource ('raw decks or plan winners'). It clearly states the tool compares decks, not scalar scores, and implies a parallel/cross comparison. However, 'plan winners' is a domain term that may need more explanation, and 'raw decks' could be clarified to avoid confusion with 'check_deck' or 'analyze_deck'.

  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 states a use case (compare decks without scalar scoring) and implies it's an alternative to scoring-based evaluation. However, it does not explicitly say when NOT to use this tool (e.g., when you need a numeric score, use 'check_deck' or 'analyze_deck') or mention any prerequisites (e.g., deck/plan IDs must exist). The sibling tools suggest possible alternatives, but no guidance is provided.

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

• create_fulfillment_planB
  3.4/5.0
  Behavior3/5

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

  Annotations are missing, so the description carries the full weight. It hints at immutability ('immutable plan result') which implies the plan cannot be modified post-creation, a key behavioral trait. However, it does not disclose whether the action is destructive (overwrites existing allocations), requires authentication/authorization, or has rate limits. A 3 reflects partial disclosure but missing critical behavioral details for a mutation tool.

  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 of only 8 words, with no redundant phrases. Every word ('allocate', 'physical copy', 'once', 'immutable', 'plan result') serves a purpose. It fits the tool's likely complexity and is front-loaded with the action and key constraint ('immutable').

  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?

  Given the tool has a complex structure (nested object with 3 fields), no annotations, no output schema explanation (though output schema exists, context signals say 'has output schema: true', but description doesn't leverage it), the description is insufficient. It covers the core purpose but omits parameter details, error scenarios, and return values. The completeness is adequate for a simple tool but gaps remain for the nested input schema.

  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% (context signals), so the description must compensate entirely. The description does not elaborate on the parameters (resolution_id, mode, exact_target_id). However, because there is only one parameter (request) that is an object with nested fields, and the description is minimal, it cannot adequately explain their semantics. Average baseline is 3, but given the very low coverage, a 4 would require description to fully cover parameters. Here it fails, but schema has no descriptions at all, so 4 is too generous. Actually, since coverage is 0% and description doesn't clarify params, score should be 2.

  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 'Allocate each physical copy once inside an immutable plan result' clearly identifies the verb (Allocate) and resource (physical copy within an immutable plan result), distinguishing it from sibling tools like 'search_cards' or 'compare_decks'. It specifies a unique action ('allocate') and context ('immutable plan'), making the purpose unambiguous.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like 'resolve_availability' or 'plan_deck'. It does not mention any prerequisites (e.g., a plan must exist), exclusions (e.g., cannot modify after allocation), or conditions (e.g., requires permissions). Context signals show sibling tools share similar domains (planning/resolving), making such guidance critical.

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