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

With no annotations, the description carries the full burden and adequately discloses that the tool performs a real write, increments quantity, and creates a row if absent. It does not mention potential errors or rate limits, but overall transparency is high.

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

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

The description is two sentences: the first covers core behavior, the second gives usage alternatives and auth requirement. No extraneous information; every sentence adds value.

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

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

For a simple add tool with three well-documented parameters and no output schema, the description fully covers usage context, alternatives, and authentication needs. It is complete and self-contained.

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

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

Input schema has 100% description coverage with well-described parameters (cardId UUID, isFoil boolean, quantity integer). The description adds no additional parameter-specific details beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states the action (add a card) and resource (buy-list), and explicitly distinguishes it from update_buy_list and remove_buy_list, which are sibling tools with different semantics.

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

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

The tool description explicitly provides when-to-use guidance by naming alternatives (update_buy_list for absolute quantity, remove_buy_list for deletion) and mentions the authentication requirement (IWMM_API_KEY).

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

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

With no annotations, the description fully discloses the behavioral traits: it increments quantity (not overwrites), creates row if absent, and requires an API key. This is sufficient for an AI agent to understand the tool's side effects.

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

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

Two sentences, zero waste. Every sentence provides essential information: what it does, behavior, alternatives, and requirements.

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

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

For a simple additive operation, the description covers purpose, guidelines, and requirements. Missing explicit return value mention, but not critical. Sibling references strengthen completeness.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the semantic of 'quantity' (incremented, not set) beyond the schema's 'How many to add.' No additional param info needed.

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

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

The description clearly states the tool's verb ('add'), resource ('card to a deck'), and behavioral nuance ('incrementing its quantity, creates the row if absent'). It effectively distinguishes itself from siblings 'set_deck_card_quantity' and 'remove_deck_card'.

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

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

Explicitly tells when to use this tool vs siblings: 'Use set_deck_card_quantity to set an absolute quantity or remove_deck_card to delete a row.' Also mentions the required auth key 'IWMM_API_KEY'.

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

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

Declares 'real write' to indicate mutation, but lacks details on side effects, idempotency, or rate limits. With empty annotations, more context would help.

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

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

Three succinct sentences: purpose, batch usage note, alternatives and auth. No filler.

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

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

Covers all essential information for a write tool with clear schema. Missing return value description, but not critical for basic usage.

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

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

Schema already provides descriptions for all parameters. Description adds minor clarity (e.g., single-item array for one card) but doesn't significantly extend understanding.

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

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

Clear verb (add) and resource (cards to inventory). Distinguishes from siblings by explicitly naming update_inventory and remove_inventory.

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

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

Explicitly states when to use this tool (adding cards) vs alternatives (update_inventory, remove_inventory). Also specifies authentication requirement (IWMM_API_KEY).

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

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

States 'This is a real write' and requires an API key, but lacks details on uniqueness constraints, immediate persistence, or any side effects. Adequate but not thorough.

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

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

Three sentences, no wasted words. Purpose is front-loaded, each sentence adds distinct value.

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

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

Given the tool's simplicity (2 params, no output schema, no annotations), the description covers core aspects: purpose, usage guidance, auth requirement. Lacks mention of naming constraints but still fairly complete.

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

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

Schema covers 100% of parameters. Description doesn't add extra meaning beyond the schema's field descriptions. Baseline score appropriate.

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

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

Clearly states 'Create a new empty deck' with specific verb and resource. Distinguishes from sibling tools like add_deck_card and import_deck by name and purpose.

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

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

Explicitly says when to use this tool (to create empty deck) and when to use alternatives (add_deck_card to fill, import_deck from text). Also mentions required IWMM_API_KEY.

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

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

Annotations are empty, so the description carries the full burden. It discloses the authentication requirement (IWMM_API_KEY) and the constraint that at least one threshold must be provided. However, it does not detail side effects (e.g., duplicate alerts), error behavior, or sync/async nature.

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

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

The description is two sentences with no wasted words. It efficiently communicates the tool's purpose, parameter constraints, and a key prerequisite.

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

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

For a simple creation tool with no output schema, the description covers the core behavior. It could optionally mention the expected response (e.g., returns the created alert), but the current level is adequate.

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

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

Schema description coverage is 100%, but the description adds critical business logic: 'Supply increasePct, decreasePct, or both (Premium). At least one threshold is required.' This clarifies the relationship between parameters and the premium feature, going beyond the schema's individual property descriptions.

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

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

The description 'Create a price alert for a card' clearly identifies the action and resource. It further specifies that the alert can be set for increasePct, decreasePct, or both (Premium), distinguishing it from related sibling tools like delete_price_alert, update_price_alert, and list_price_alerts.

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

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

The description states 'At least one threshold is required' and 'Requires IWMM_API_KEY', providing clear prerequisites. It does not explicitly mention when not to use the tool, but the context is sufficient for the agent to decide.

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

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

With empty annotations, the description carries the full burden. It clearly states it is a 'real write to the buy-list' and returns the count of distinct cards added. No additional side effects are mentioned, but the basic behavior is transparent.

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

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

The description is two sentences with no wasted words. The first sentence states the core action, and the second confirms it's a write operation and lists the key requirement. Front-loaded and efficient.

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

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

Given one parameter, no output schema, and no nested objects, the description adequately explains what the tool does, what it returns, and the prerequisite. It is complete for this simple tool.

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

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

Schema coverage is 100% and the description does not add extra meaning beyond what the schema provides for deckId. The schema already explains how to obtain deckId (from list_decks or create_deck).

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

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

The description clearly states the tool adds missing cards from a deck to the buy-list and returns the count. It distinguishes from siblings like add_buy_list by specifying the source (deck's missing cards) and the action (add to buy-list).

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

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

The description mentions the requirement for IWMM_API_KEY, which is a critical usage constraint. It does not explicitly state when not to use or list alternatives, but the context of 'missing cards' vs. direct addition implies appropriate use.

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

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

Adds context beyond destructiveHint annotation: specifies that all cards are deleted and operations are permanent. Also mentions API key requirement.

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

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

Two concise sentences, front-loaded with essential action, no unnecessary words.

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

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

For a single-parameter delete tool with annotations present, description covers effect, permanence, and auth requirement. No output schema needed.

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

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

Only one parameter (deckId) with schema description already clear; description adds no extra meaning beyond what schema provides. Schema coverage 100% so baseline 3.

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

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

Description clearly states it deletes a deck and all its cards, with permanence. Distinguishes from sibling tools like create_deck, update_deck, list_decks.

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

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

Does not explicitly state when to use or provide alternatives; usage is implied by name and description but no guidance on when not to use.

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

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

The annotations already provide destructiveHint=true, so the destructive nature is disclosed. The description adds the authentication requirement (IWMM_API_KEY), which is not in annotations. However, it does not elaborate on consequences (e.g., irreversibility) or whether other data is affected.

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

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

The description is extremely concise with two short sentences. The primary action is front-loaded ('Delete a price alert by ID'), and the second sentence adds a crucial prerequisite. No unnecessary words.

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

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

Given the tool's simplicity (one parameter, no output schema), the description is adequate but incomplete. It lacks return value information, error handling (e.g., if ID not found), and confirmation of irreversibility. Still, the core purpose and requirement are clear.

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

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

Schema description coverage is 0%, so the description must compensate. It says 'by ID' but does not explain what the ID represents (e.g., the ID from list_price_alerts) or provide any format or source. The parameter 'id' remains minimally documented.

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

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

The description clearly states 'Delete a price alert by ID' – a specific verb ('Delete'), a distinct resource ('price alert'), and how it's identified ('by ID'). This distinguishes it from siblings like create_price_alert and update_price_alert.

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

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

No guidance on when to use this tool versus alternatives (e.g., when a price alert is no longer needed). It only mentions 'Requires IWMM_API_KEY' as a prerequisite, but does not explain usage context, conditions, or what happens if the ID is invalid.

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

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

Annotations already provide destructiveHint=true, so the description does not need to reiterate that. The description adds value by noting the authentication requirement (API key), which is not present in annotations. No contradiction found.

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

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

The description is extremely concise, consisting of two short sentences with no unnecessary words. Every part serves a purpose: stating the action and noting a requirement.

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

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

For a simple one-parameter destructive tool with no output schema, the description adequately covers the operation and a key prerequisite. It does not detail side effects or response, but given the simplicity and annotation coverage, this is sufficient.

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

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

The schema has 0% description coverage, so the description should compensate. However, it adds no meaning to the 'id' parameter beyond what the schema (type integer, minimum 1) already provides. For a simple parameter, some additional context could be expected but is missing.

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

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

The description clearly states 'Delete a transaction by ID' with a specific verb and resource. It includes the requirement 'Requires IWMM_API_KEY' which helps differentiate it from sibling tools like list_transactions or record_transaction.

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

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

The description implies use when you need to delete a transaction and provides a prerequisite (API key). It does not explicitly state when not to use it or name alternatives, but the context of sibling tools and the self-explanatory name provide adequate guidance.

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

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

Annotations already declare readOnlyHint=true. The description adds meaningful context: full export, CSV format, reimport compatibility, and API key requirement. No contradictions, and the behavior is well-disclosed beyond annotations.

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

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

The description consists of two concise sentences. The first sentence defines the action and output, the second adds compatibility and authentication. No unnecessary words. Ideal structure.

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

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

Given no parameters, no output schema, but with annotations present, the description covers the essential: CSV columns, compatibility, auth. It lacks explicit mention of how the CSV is returned (e.g., response body), but is adequate for an agent to understand the tool.

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

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

The tool has no parameters, so baseline score is 4. The description appropriately does not waste space on parameters, as none exist.

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

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

The description clearly states the verb 'Export', the resource 'authenticated user's full card inventory', and the output format 'CSV' with explicit columns. It distinguishes from siblings like 'list_inventory' (which likely returns JSON) and 'import_inventory_cards' (import vs export).

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

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

The description implies usage for full inventory export in CSV format, and mentions compatibility with 'import_inventory_cards' and API key requirement. It does not explicitly state when not to use it versus alternatives like 'list_inventory', but the context of 'full' and CSV is clear.

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

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

Annotations already declare readOnlyHint=true. Description adds return content details (prices, rarity, type, flavor name) but no additional behavioral traits like rate limits or side effects.

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

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

Three efficient sentences: first states purpose, second lists return contents, third gives alternative. No fluff, front-loaded.

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

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

No output schema, but description summarizes return data (prices, rarity, type, flavor name). With 2 simple params and clear purpose, it is sufficiently complete for a lookup tool.

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

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

Schema has 100% description coverage; both parameters are well-described. Description reiterates 'by set code and collector number' but adds no new meaning beyond schema.

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

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

Clearly states 'Look up a specific card printing' with verb and resource. Distinguishes from sibling 'search_cards' by mentioning broader search as alternative.

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

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

Explicitly tells when to use (specific card by set code and number) and provides alternative 'use search_cards' for broader catalog. No when-not mentioned but context is clear.

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

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

Annotations indicate readOnlyHint=true. The description adds behavioral details: returns offers grouped by finish, best first, highest offer per finish marked, and NM condition only. This provides useful context beyond the annotation, though some details like rate limits or pagination could be included.

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

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

Two concise sentences with no redundant information. The first sentence states the core purpose, and the second adds details and a usage alternative. Every phrase earns its place.

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

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

Given the tool's low complexity (2 parameters, no output schema), the description covers purpose, input, output format, condition, and alternative. It is complete enough for correct tool selection and invocation.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description mentions 'set code and collector number' but doesn't add significant meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: getting buylist offers for a card printing by set code and collector number. It uses a specific verb ('Get'), a resource ('buylist offers'), and distinguishes from the sibling 'get_card_prices' tool.

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

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

The description explicitly tells when to use this tool (for buylist offers) and when not to use it (for retail prices), providing the alternative 'get_card_prices'. This gives clear guidance to the agent.

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

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

Annotations already declare readOnlyHint=true. The description adds the premium-gating and API key requirement, which is important behavioral context beyond read-only status. It does not disclose return format, pagination, or error behavior, limiting the added value.

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

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

The description is three sentences, each serving a distinct purpose: purpose, default, and access requirements. It is front-loaded with the most important information and contains no superfluous words.

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

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

For a tool with two simple parameters and no output schema, the description covers the purpose, defaults, and access restrictions. It is mostly complete, though it could mention the structure of the return value (e.g., list of cards with P&L) for full completeness.

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

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

The input schema has 0% description coverage. The description provides default values for both parameters (type=best, limit=10), adding some meaning. It does not explain the semantics of 'P&L' or what 'performance' entails, so the added value is minimal.

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

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

The description clearly specifies the verb 'get', the resource 'cards performance by P&L', and the scope (best or worst, default top 10). It distinguishes itself from siblings like get_card (individual card details) and get_card_prices (price data) by focusing on performance ranking.

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

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

The description states the default behavior and access restrictions (premium-gated, requires API key), giving clear context for when to use. However, it does not explicitly mention when not to use or suggest alternatives among the many card-related sibling tools.

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

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

Annotations already indicate read-only. The description adds behavioral context about retention cadence beyond 30 days and confirms normal+foil coverage, providing value beyond annotations.

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

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

Two sentences, front-loaded with the main purpose, and no extraneous information. Every sentence earns its place.

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

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

Given the simple 2-parameter tool with readOnlyHint annotation and no output schema, the description completely covers purpose, scope, and data retention behavior without gaps.

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

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

Schema coverage is 100% with descriptions for both parameters. The tool description adds overall scope but no additional parameter-specific meaning beyond what the schema already provides.

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

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

The description clearly states the tool gets 30-day price history for a card printing (normal + foil), with a specific verb and resource, distinguishing it from sibling tools like get_card_prices and get_card_performance.

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

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

The description implies usage for historical price data within 30 days but does not explicitly state when to use it over alternatives or mention exclusions. Sibling tools exist for current prices or performance, but no guidance is given.

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

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

Annotations already indicate readOnlyHint=true, so the safety is known. The description adds that it retrieves 'current normal and foil prices', which is useful but does not disclose other behavioral traits (e.g., whether both prices are always returned, if prices can be null, or rate limits).

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

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

The description is a single sentence of 11 words, no fluff. It communicates the essential purpose efficiently.

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

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

For a simple read-only tool with only 2 well-documented parameters and no output schema, the description is complete. It tells the agent exactly what it does and what inputs are needed.

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

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

The input schema has 100% coverage with detailed descriptions of setCode and setNumber. The description adds no additional parameter information beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description clearly states the verb 'get' and the resource 'current normal and foil prices for a specific card printing'. It distinguishes itself from sibling tools like 'get_card_price_history' (which returns historical data) and 'get_card_buylist' (which returns buylist prices), making it unambiguous.

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

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

The description does not explicitly state when to use this tool versus alternatives like 'get_card_price_history' or 'get_card'. The purpose is implied by the name and description, but no direct guidance on exclusion or context is provided.

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

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

The readOnlyHint annotation already signals this is a safe read operation. The description adds useful behavioral context beyond the annotation: results are sorted 'most valuable first' and the addressed printing is included in the output. It does not mention pagination behavior, but that is covered by the schema parameters. Overall, it adds meaningful behavioral details.

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

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

The description is three sentences long, front-loaded with the main action, then usage guidance, then an alternative comparison. Every sentence earns its place with no fluff or repetition. The structure is clear and efficient.

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

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

Despite lacking an output schema, the description is complete for the tool's complexity: it covers what the tool does, when to use it, how it differs from an alternative, sorting order, and inclusion of the addressed printing. The readOnlyHint annotation and schema provide additional context. No critical information appears missing for an agent to select and invoke this tool correctly.

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

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

The input schema already provides 100% coverage, with descriptions for setCode, setNumber, page, and limit. The description does not add significant meaning beyond the schema; it reiterates the concepts of 'set code' and 'collector number' without new details. Per the baseline for high schema coverage, a score of 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'List every printing of the card at this set code and collector number.' It clearly defines the tool's scope (printings for a given set code and collector number) and differentiates it from search_cards by explaining how search_cards works differently. This is a precise, non-tautological statement.

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

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

The description explicitly states when to use this tool: 'Use this to compare what the same card costs across sets, or to find a cheaper printing.' It also explicitly prefers it over a specific alternative, search_cards, and explains why: search_cards does substring matching on names and returns unrelated cards. This meets the 'explicit when/when-not/alternatives' criterion.

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

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

Annotations declare readOnlyHint=true, and description adds behavioral context about premium gating and API key requirement, providing value beyond the annotations without contradiction.

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

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

Extremely concise - single sentence plus two critical phrases with no redundancy.

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

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

No output schema is provided, and the description does not specify the return format or data structure. For a tool with no output schema, the description should compensate by explaining the output, but it only gives a conceptual description.

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

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

No parameters exist; schema coverage is 100%. The description does not add param info, but baseline for 0 parameters is 4.

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

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

The description clearly identifies the tool gets cash flow, defining it as money in vs out from BUY/SELL transactions, distinguishing it from related tools like get_cash_vs_credit.

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

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

Specifies access constraints (premium-gated, requires IWMM_API_KEY) but does not indicate when to use this tool versus alternatives such as get_cash_vs_credit or get_realized_gains.

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

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

Annotations already declare readOnlyHint=true, so the tool is clearly a read operation. The description adds behavioral context about the comparison logic and return values without contradicting annotations. No hidden side effects are mentioned, but the transparency is adequate.

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

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

The description is very concise—two sentences that effectively convey the tool's purpose, functionality, and required information. No redundant words.

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

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

Given the tool has one optional parameter and no output schema, the description adequately explains the return values (recommendation, credit advantage, out-of-pocket costs, priced buy-list lines) and prerequisites. It is complete for the tool's complexity.

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

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

The input schema covers 100% of the parameter (bonus) with a full description. The description does not add additional meaning beyond the schema, so baseline score of 3 is appropriate.

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

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

The description clearly states it provides a recommendation between cash and store credit, specifying the comparison and the return values. It distinguishes itself from sibling tools, as no other tool offers this specific comparison.

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

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

The description mentions 'for the authenticated user' and a key requirement (IWMM_API_KEY), but does not explicitly state when to use versus alternatives or provide exclusion criteria. The context implies usage for buylist and buy list decisions, but guidance is mostly implicit.

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

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

Annotations already declare readOnlyHint=true, so the description doesn't need to confirm safety. It adds context about the data returned (FIFO cost basis) and the authentication requirement, which is valuable. No contradictions with annotations.

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

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

Two concise sentences front-load the core purpose and parameter options. No extraneous words; every sentence adds value.

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

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

The description is adequate for a simple tool but does not specify the return format (e.g., numeric value, currency) or error behavior (e.g., what if card not found). With no output schema, more detail on output would improve completeness.

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

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

With 0% schema coverage, the description compensates by explaining the alternative identification methods (cardId or setCode+setNumber) and implicitly covering isFoil via 'finish'. However, it doesn't explicitly document the default for isFoil or the fact that setCode and setNumber must be used together.

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

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

The description clearly states the tool retrieves FIFO cost basis for a specific card and finish. It specifies two identification methods (cardId or setCode+setNumber), distinguishing it from sibling tools like get_card or get_inventory_quantities.

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

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

The description provides parameter requirements but lacks guidance on when to use this tool versus alternatives (e.g., get_inventory_quantities, get_portfolio_breakdown). No explicit when-to-use or when-not-to-use context is given.

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

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

Annotations already indicate readOnlyHint=true, so the description doesn't need to state it's read-only. It adds authentication context (requires IWMM_API_KEY) but no further behavioral details such as rate limits, data freshness, or error conditions.

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

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

Two sentences with no unnecessary wording. Front-loaded with the core function, then additional detail about authorization.

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

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

Given the simple single-parameter input, read-only annotations, and no output schema, the description is sufficient. It explains what the tool returns (deck with mainboard+sideboard). Could mention the response structure briefly but not essential.

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

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

Schema covers deckId with description and constraints. Description adds value by telling the user to obtain deckId from list_decks or create_deck, which is helpful context beyond the schema.

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

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

The description clearly states it retrieves one deck including its mainboard and sideboard cards, using a specific verb and resource. It distinguishes from sibling tools like list_decks which lists decks without cards, and create_deck which creates decks.

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

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

No explicit guidance on when to use this tool versus alternatives. It mentions that deckId can come from list_decks or create_deck, but does not explain when to prefer this over other get tools or when not to use it.

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

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

Annotations already declare readOnlyHint=true. The description adds behavioral details: it is a batch operation, returns both normal and foil counts, and requires an API key. It does not contradict annotations.

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

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

The description is two sentences with no unnecessary words. It is front-loaded with the core purpose, followed by usage context and a requirement. Every sentence adds value.

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

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

For a simple batch lookup tool with a single array parameter and read-only annotation, the description covers the input, output (normal+foil counts), usage context, and authentication. It does not specify the exact output format or error behavior, but given no output schema, this is mostly sufficient.

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

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

Schema description coverage is 0%, so the description must compensate. It correctly describes that the sole parameter 'cardIds' is a list of UUIDs, but adds no further detail beyond the schema's structural constraints. The description provides basic clarity but not rich semantics.

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

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

The description clearly states the verb ('return'), resource ('inventory quantities'), and scope ('normal + foil' for a batch of card UUIDs). It distinguishes itself from sibling tools like `get_card` and `list_inventory` by being a dedicated batch lookup for quantities.

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

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

The description gives explicit context by stating 'Useful before recommending adds.' This helps the agent decide when to use it, though it does not explicitly mention when not to use it or compare with alternatives like `list_inventory`.

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

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

Beyond the readOnlyHint annotation, the description details the algorithm (matching, best offer capping, vendor grouping) and states the requirement for IWMM_API_KEY, providing rich behavioral context.

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

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

The description is two sentences, front-loaded with the core action, and every sentence adds value without redundancy.

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

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

The description covers the algorithm, output (vendor groups with per-item payouts and totals), and a key requirement (API key). No output schema exists, but the description sufficiently explains return values.

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

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

There are no parameters, so the description correctly does not add parameter info. Baseline 4 for 0 parameters.

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

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

The description clearly states the tool computes the market sell value of the authenticated user's entire inventory using specific logic (matching cards to buylist offers, capping by buy quantity, grouping by vendor). It uses specific verbs and resource, and implicitly distinguishes from siblings that target single cards or portfolio summaries.

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

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

The description implies usage for total inventory valuation but does not explicitly state when to use this tool over alternatives like get_card_buylist or get_portfolio_summary. No exclusions or alternative recommendations are given.

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

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

Annotations already provide readOnlyHint=true, so the description adds value by disclosing gating (Premium-gated) and authentication requirement (IWMM_API_KEY). It does not describe output format details beyond 'each with value, count, and share' or mention rate limits, data freshness, or side effects. This is adequate but not rich.

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

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

The description is concise at two sentences, front-loading purpose and output format, then adding gating info and a sibling reference. Every sentence provides value with no fluff.

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

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

Given the tool's complexity (enum with special cases, no output schema), the description covers core purpose, output structure partially, and references a key sibling. It omits details like overall summary alternative (get_portfolio_summary) but is sufficient for a read-only breakdown tool with well-documented parameters.

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

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

Schema coverage is 100% with descriptions for both parameters, including enum values and special behavior for 'cost-basis' and 'color'. The description does not add significant meaning beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description clearly states the tool's function: 'Get the user's collection value broken down by a dimension into slices (each with value, count, and share).' It uses a specific verb ('Get') and resource ('collection value broken down'), and distinguishes from sibling 'get_portfolio_breakdown_cards' by noting it's for drilling into one slice.

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

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

The description provides usage context by noting it is 'Premium-gated' and 'Requires IWMM_API_KEY', and gives an explicit alternative: 'Use get_portfolio_breakdown_cards to drill into one slice.' However, it does not compare with other siblings like get_portfolio_summary or explicitly state when not to use this tool.

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

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

Annotations already provide readOnlyHint=true; description adds premium-gated and requires IWMM_API_KEY, which is valuable authorization context. No contradiction.

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

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

Two sentences conveying purpose, relationship to parent tool, and access requirements. No wasted words.

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

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

Lacks output schema but description is sufficient for a read operation. Could mention pagination or response format, but not critical for understanding the tool's core function.

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

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

Schema coverage is 100%, so baseline 3 is appropriate. Description does not add additional meaning beyond what the schema provides for the three parameters.

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

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

Clearly states the tool retrieves cards inside one slice of a portfolio breakdown, distinguishing it from get_portfolio_breakdown. Uses specific verb 'Get' and resource 'cards inside one slice of a portfolio breakdown'. Different from siblings.

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

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

Implicitly guides usage as a drill-down after get_portfolio_breakdown. Mentions premium-gating and API key requirement. Could explicitly state when not to use or alternatives, but context is clear enough.

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

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

Annotations already declare readOnlyHint=true, so the description adds value by disclosing that it is premium-gated and requires a specific API key. This goes beyond the annotations by providing authentication and access control details. No contradictions.

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

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

The description is extremely concise with three sentences, each adding essential information: purpose, premium gating, and API key requirement. There is no wasted text.

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

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

For a simple read-only tool with one parameter and no output schema, the description adequately covers purpose and access requirements. It could be improved by hinting at the return format, but the current description is sufficient for an AI agent to understand the tool's basic behavior.

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

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

Schema coverage is 100% (one parameter 'days' with a description), so the baseline is 3. The tool description does not add any additional meaning beyond what the schema already provides for the parameters.

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

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

The description clearly states 'Get portfolio value history' which includes a specific verb and resource. It distinguishes itself from sibling tools like get_portfolio_breakdown and get_portfolio_summary by focusing on history. The additional context about premium gating also helps clarify its scope.

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

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

The description mentions that the tool is premium-gated and requires the 'IWMM_API_KEY', providing clear context for when it can be used. However, it does not explicitly state when to use this tool versus alternatives or provide exclusions, which prevents a higher score.

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

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

Annotations already declare readOnlyHint=true. The description adds value by detailing tier-based limitations and authentication requirements, which are not covered by annotations.

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

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

Two sentences with all essential information: what it does, what it returns, tier differences, and auth requirement. No wasted words.

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

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

Given no output schema and readOnlyHint, the description covers return fields and restrictions. However, it could specify whether the output is a single object or array, and mention if there are any default scoping.

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

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

The input schema has no parameters (0), so schema description coverage is 100%. The description adds no parameter info, which is acceptable; baseline score of 4 applies.

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

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

The description clearly states the verb 'Get' and the resource 'portfolio summary', listing specific return fields (current value, total invested, unrealized P&L, ROI, card/unit counts). It distinguishes from siblings like get_portfolio_breakdown and get_portfolio_history by focusing on a high-level summary.

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

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

The description provides context on when to use based on tier (Free vs Premium) and requires IWMM_API_KEY. However, it does not explicitly exclude alternatives or specify when not to use this tool.

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

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

Adds value beyond annotations by disclosing premium requirement and FIFO method. However, no details on return format or behavior for empty results, which would be helpful given no output schema.

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

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

Two concise sentences covering function, method, access requirement, and authentication key. No wasted words.

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

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

For a zero-parameter tool with readOnlyHint, description is mostly complete. Could improve by hinting at output shape (e.g., returns a number or list), but not critical.

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

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

No parameters, so baseline 4 applies. Description does not need to add param info beyond what schema already provides.

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

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

Clearly states it gets realized gains from SELL transactions using FIFO cost basis. However, does not distinguish from sibling tool get_cost_basis, which may confuse an agent.

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

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

Mentions premium-gated and requires IWMM_API_KEY, providing prerequisite context. Lacks guidance on when to use this tool over alternatives like get_cost_basis.

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

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

Annotations already indicate readOnlyHint=true, so the tool is safe. Description adds that it returns current pricing and purchase URL, which is useful context for the agent but does not reveal any additional behavioral traits like potential failures 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.

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

Two concise sentences with no wasted words, front-loading the primary action and including a helpful sibling reference.

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

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

For a simple get-by-id tool with read-only annotations, the description adequately covers the return content (pricing, purchase URL). However, it lacks mention of error handling or non-existent UUID cases, but given simplicity, it is mostly complete.

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

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

Schema coverage is 100% and describes the uuid parameter with format and example. The description does not add any extra meaning beyond what the schema already provides, so baseline score of 3 applies.

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

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

Description clearly states the tool gets detail for a single sealed product by UUID, including pricing and purchase URL. It distinguishes from the sibling get_sealed_products by specifying singular vs plural action.

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

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

Explicitly directs users to use get_sealed_products for listing sealed products in a set, providing clear when-to-use guidance and differentiating from the sibling tool.

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

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

Annotations provide readOnlyHint, and the description adds detail about output (includes TCGPlayer URL). No contradictions. It does not discuss rate limits or permissions but is sufficient for a read-only list tool.

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

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

One clear, front-loaded sentence with no extraneous information. Every word adds value.

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

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

Given the tool's simplicity (one parameter, no output schema), the description adequately covers purpose and output details. Could mention pagination or ordering, but not essential.

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

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

The single parameter 'code' has no schema description (0% coverage). The description adds meaning by indicating it is a set code, compensating for the schema gap.

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

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

The description clearly states the verb (List), resource (sealed products), and scope (for a set). It also distinguishes from siblings like get_sealed_product by specifying plural products and including a TCGPlayer URL.

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

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

The description implies usage context (requires a set code) but does not explicitly compare to alternative tools like search_cards or get_sealed_product, nor state when not to use.

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

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

Annotations declare readOnlyHint=true, consistent with 'Get detail'. Description adds no behavioral surprises; it is straightforward. No additional context needed for a simple read operation.

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

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

Single sentence, no filler, front-loaded with action and resource. Every word earns its place.

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

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

Given low complexity (1 required param, no nested objects, no output schema), the description is sufficient. Could optionally mention return type (set details) but not necessary for correct invocation.

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

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

Schema has 0% coverage for 'code' parameter description, but the tool description compensates by explaining it is a set code with examples ('lea', 'mh3'). This adds essential meaning beyond the type string.

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

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

Description clearly states verb ('Get'), resource ('set'), and method ('by code'), with concrete examples ('lea', 'mh3'). Distinguishes from siblings like search_sets (list) and list_set_cards (cards of a set).

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

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

Provides clear context by explaining the input format (set code) and example values, implying usage when a specific set code is known. No explicit exclusion of alternatives, but purpose is clear enough.

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

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

Description is consistent with readOnlyHint annotation, adding context that returns aggregate value over time. No contradictions, but adds limited extra behavioral detail beyond annotations.

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

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

Two sentences, no wasted words, front-loaded with main purpose and key differentiation.

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

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

Given no output schema, description could hint at return format (e.g., time series). But for a simple get tool with good annotations and full schema coverage, it is mostly complete.

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

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

Schema coverage is 100% and descriptions in schema are clear. Description adds marginal value (e.g., 'optionally limit window') but doesn't enhance understanding beyond schema.

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

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

Description clearly states the tool gets price history for a whole set by set code (aggregate value), and explicitly distinguishes from get_card_price_history for single card history. Verb and resource are specific.

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

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

Explicitly mentions optional parameter (days) and provides alternative tool for single card history, guiding when to use this vs sibling.

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

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

The description does not contradict the 'readOnlyHint' annotation. It adds the requirement for an API key, but does not disclose other behavioral traits such as that the count is a single number, or that no side effects occur. The annotation already signals read-only behavior, so this is partially covered.

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

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

The description is a single sentence with no wasted words. It is concise and front-loaded with the purpose, followed by the requirement.

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

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

Given the tool is simple with no parameters and no output schema, the description is relatively complete but lacks details on the return value (e.g., the count as an integer) and the fact that it's a read operation. The requirement for an API key is added, but overall completeness is adequate but not thorough.

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

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

The tool has zero parameters, so the parameter schema is fully covered. The description adds no extra parameter meaning, but none is needed. Baseline score of 4 is appropriate.

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

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

The description clearly states the action ('Get'), the resource ('count of unread notifications'), and the user ('authenticated user'). It is specific and easy to understand. However, it does not explicitly differentiate from the sibling tool 'list_notifications', which might list all notifications including counts.

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

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

The description mentions a prerequisite ('Requires IWMM_API_KEY'), but provides no guidance on when to use this tool versus alternatives like 'list_notifications'. There is no mention of use cases or exclusions.

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

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

With no annotations provided, the description carries the behavioral burden. It discloses that the tool returns counts and per-row errors, which is helpful, but it does not mention idempotency, duplicate handling, or rate limits. The authentication requirement is noted.

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

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

The description is concise: three sentences, no wasted words. It front-loads the main purpose, then provides format details and return behavior, making it easy to parse quickly.

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

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

Given the single parameter with schema coverage, the description fully explains the input format and return value. The sibling context is rich with related buy-list and import tools, and the description is sufficient for an agent to understand the tool's role.

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

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

The description adds significant meaning beyond the schema's parameter description by detailing the expected CSV header columns (name, set_code, number, etc.) and noting auto-detection of external formats. This clarifies formatting requirements beyond the schema's generic description.

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

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

The description clearly states the tool bulk-adds cards to the user's buy-list from CSV text. It specifies the native format and mentions auto-detection of external exports, distinguishing it from siblings like 'add_buy_list' (single addition) and 'list_buy_list'.

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

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

The description explicitly requires 'IWMM_API_KEY' and describes the CSV format and auto-detection of external exports, indicating when to use it (bulk import). However, it does not explicitly contrast with siblings or state when not to use it.

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

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

With no annotations, the description carries the full burden. It discloses the return value (new deck id and unresolved lines) and the authorization requirement (IWMM_API_KEY). It does not mention side effects or safety (e.g., idempotency), but the disclosed information is sufficient for basic understanding.

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

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

The description is two sentences, covering the core purpose, input format, return value, and a requirement. Every part is necessary and there is no redundancy or fluff.

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

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

For a creation tool with no output schema, the description adequately explains the return value. It mentions the API key requirement. It could be improved by noting error behavior (e.g., duplicate name) but overall is sufficiently complete for basic usage.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds no significant meaning beyond the schema: it repeats the text format but does not elaborate on the 'name' or 'format' parameters. The example is helpful but not a semantic addition.

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

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

The description clearly states the tool's purpose: creating a deck from pasted decklist text. It provides an example format ('4 Lightning Bolt') and specifies the return value (new deck id and unresolved lines). This distinguishes it from siblings like create_deck or import_buy_list.

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

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

The description mentions the input format and API key requirement, which gives context for use. However, it does not explicitly state when to prefer this tool over alternatives like create_deck or import_inventory_cards, nor does it provide exclusion criteria.

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

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

With empty annotations, the description carries full burden. It discloses that the tool mutates inventory (bulk-import), returns counts of saved/deleted/skipped rows and errors, and requires authentication. However, it omits details on rate limits, idempotency, or whether the import is reversible. Moderate transparency.

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

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

Three sentences that efficiently cover purpose, input format, and output behavior without redundancy or fluff. Each sentence adds essential information, making it highly concise and well-structured.

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

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

Given the simple single-parameter input and no output schema, the description adequately covers all aspects: what it does, how to use it (input format), what it returns, and authentication requirement. No further information seems necessary for this tool.

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

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

Schema coverage is 100% with one parameter 'text', described as 'CSV text including a header row.' The description adds significant value by detailing supported header formats (native, Moxfield, etc.) and return data (counts and errors), going beyond the schema's minimal description.

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

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

The description clearly states the action (Bulk-import), the target resource (cards into the authenticated user's inventory), and the input method (pasted CSV text). It also specifies supported formats, making the tool's purpose unambiguous and distinguishing it from other import tools like import_buy_list or import_deck.

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

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

The description mentions a prerequisite (requires IWMM_API_KEY) and implies bulk use, but does not explicitly state when to use this tool versus alternatives like add_inventory for single additions. However, the name and context make the usage clear enough.

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

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

Annotations already provide readOnlyHint=true. The description adds the authentication requirement (IWMM_API_KEY) and the data returned (quantities, finish, prices). No additional behavioral quirks are needed for this simple read-only list operation.

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

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

A single, well-structured sentence that immediately states the purpose, then details the output and requirement. No wasted words.

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

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

For a parameterless, read-only list tool, the description covers purpose, output fields, and auth. It does not mention response format or error cases, but that is acceptable given the tool's simplicity.

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

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

The input schema has no parameters and 100% coverage, so the description does not need to explain parameters. Baseline 3 is appropriate; the description adds no parameter information because none exists.

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

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

The description clearly states the tool lists the authenticated user's buy-list (want-list) with quantities, finish, and current prices. It uses specific verbs and resources, and distinguishes from sibling tools like add_buy_list, update_buy_list, etc.

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

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

The description specifies the requirement of IWMM_API_KEY, implying authentication context. While it doesn't explicitly contrast with alternative tools, the sibling tool names clearly indicate this is for viewing only, not modifying the buy-list.

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

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

Annotations already indicate readOnlyHint=true. The description adds that authentication is required and specifies the return structure (id, name, format, card counts), providing useful behavioral context.

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

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

Two concise sentences, no unnecessary words. Front-loaded with purpose, then requirement.

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

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

For a parameterless list operation without output schema, the description adequately covers purpose, authentication, and return format.

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

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

The tool has no parameters, so the description cannot add parameter semantics. Baseline 4 per rules.

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

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

The description clearly states 'list the authenticated user's decks' with specific summary fields (id, name, format, card counts). This distinguishes it from sibling tools like get_deck (single deck) and create_deck (creation).

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

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

The description mentions the requirement of IWMM_API_KEY but does not provide guidance on when to use this tool versus alternatives like get_deck for a specific deck.

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

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

Annotations already provide readOnlyHint=true, so the description adds authentication requirement and pagination info. However, it does not disclose other behavioral traits like data freshness or caching. The description is consistent with annotations.

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

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

Two sentences, front-loaded with the main action. No fluff, but could benefit from structured formatting like bullet points for the return values.

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

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

The description is vague about return structure ('cards with quantities, prices, and metadata') and does not explain differ from sibling tools. With no output schema and 0% parameter coverage, the description is insufficient for an agent to use effectively.

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

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

Input schema has 0% description coverage, and the description only mentions 'paginated' without explaining 'page' and 'limit' parameters. This fails to add meaning beyond the schema, which is critical given the lack of schema descriptions.

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

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

The description clearly states the verb 'List', the resource 'card inventory', and mentions pagination. It also distinguishes from siblings like 'list_sealed_inventory' by specifying 'card inventory'.

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

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

The description does not explicitly state when to use this tool versus alternatives like 'list_sealed_inventory' or 'get_inventory_quantities'. It only mentions pagination and API key requirement, which provides minimal context.

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

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

Annotations already indicate readOnlyHint=true. Description adds that it requires IWMM_API_KEY and includes both read/unread. No contradictions. Could mention pagination but not essential.

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

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

Two sentences, front-loaded with main action, no redundant information. Efficient.

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

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

Covers core functionality, ordering, and auth. No output schema so return format is left implicit. Adequate for simple list tool.

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

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

No parameters in schema (100% coverage). Description adds auth requirement context. Baseline 4 for zero parameters.

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

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

Clearly states verb 'list', resource 'price alert notifications', ordering 'newest first', and scope 'authenticated user'. Distinguishes from sibling tools like get_unread_notification_count.

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

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

Describes what it lists (both read and unread) and auth requirement. Implicit context but no explicit when-not or alternatives. Adequate given simplicity.

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

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

Annotations declare readOnlyHint=true; description adds context about free tier caps and premium removal, plus API key requirement. No contradiction.

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

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

Two sentences, front-loaded with purpose, no filler. Every sentence adds value.

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

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

Covers purpose, constraints (limits, API key), and implicit read-only. No output schema, but return format is standard list; missing pagination info but not critical.

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

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

No parameters; baseline 4 per rule. Schema coverage is 100%, so description need not add parameter details.

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

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

Description clearly states the verb (list), resource (price alerts), and scope (authenticated user's). Distinguishes from sibling tools like list_decks or list_transactions.

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

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

Mentions prerequisite (API key) and free tier limits but does not specify when to use vs alternatives like create_price_alert or other list tools.

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

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

Annotations already declare readOnlyHint=true, so the read-only behavior is known. The description adds that results are paginated and include quantities and prices, enhancing transparency beyond the annotation.

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

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

The description is two sentences, front-loaded with core purpose, and contains no redundant or irrelevant information. Every sentence adds value.

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

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

For a simple read tool with known annotations, the description covers key aspects: what it lists, pagination, and a sibling alternative. Without an output schema, some return structure hints could help, but it remains adequate for its complexity.

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

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

Schema description coverage is 0%. The description mentions pagination but does not explain the page and limit parameters, their defaults, or usage. Without this, the agent cannot infer parameter semantics beyond the schema constraints.

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

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

The description clearly states the verb (list), resource (sealed-product inventory), and specifics (booster boxes, bundles, precons, paginated, with quantities and prices). It also explicitly distinguishes from the sibling list_inventory for loose cards.

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

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

Provides an explicit alternative ('For loose cards use list_inventory') and mentions a requirement (IWMM_API_KEY). However, it does not cover other contexts or when to avoid this tool.

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

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

Annotations already provide readOnlyHint=true. The description adds pagination and filter support details, but does not elaborate on other behavioral aspects like sorting or return structure. With annotations covering the safety profile, the description adds moderate value.

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

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

Two sentences: first states the main action with pagination, second adds filter context. No unnecessary words, front-loaded.

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

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

Given 7 parameters, 1 required, and no output schema, the description provides essential context (pagination, filters) but omits return format and sorting. Adequate for a listing tool with clear reference to sibling search_cards.

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

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

Schema description coverage is low (14%), but the description explicitly mentions the filters (rarity, type, format, legality) and pagination, significantly adding meaning beyond the schema. It does not explain page/limit defaults, but adequately compensates for low coverage.

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

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

The description clearly states the purpose: 'List all cards in a set, paginated.' It specifies the resource (cards in a set) and action (list), and distinguishes from siblings by referencing search_cards filters.

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

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

The description indicates when to use this tool: to list cards in a set, and mentions it supports the same filters as search_cards, implying search_cards is for broader queries. However, it lacks explicit when-not-to-use guidance.

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

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

Annotations already mark the tool as readOnlyHint:true, and the description confirms it lists data. Description adds value by specifying the auth requirement (IWMM_API_KEY) and tier-based data access limitation, which are not in annotations.

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

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

Three short sentences, each adding distinct information: purpose, capabilities, and constraints. No wasted words; the key details are front-loaded.

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

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

Description covers purpose, pagination, sorting, filtering, auth, and tier restrictions. However, it lacks details on pagination behavior (e.g., default limit, cursor) and does not describe the response format, which is important given no output schema.

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

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

Schema description coverage is only 40% (2 of 5 parameters have descriptions). The description only generically mentions 'sort/filter query params' without elaborating on specific parameters like page, type, or limit. It adds minimal value beyond the schema.

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

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

Description clearly states 'List the authenticated user's transactions, paginated.' The verb 'List' and resource 'transactions' directly matches the tool name. Among siblings, it is distinct as there is no other transaction listing tool.

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

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

Description mentions pagination, sort/filter support, and tier restrictions (Free vs Premium). It also notes the required API key. However, it does not explicitly state when not to use this tool or suggest alternatives, though the context makes it clear.

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

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

No annotations provided, so description carries burden. It notes authentication and action, but no details on side effects or reversibility. For a simple 0-param action, it is minimally adequate.

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

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

Single sentence, front-loaded with action and scope. No wasted words.

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

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

For a 0-param, no-output tool, the description fully covers what the tool does and its auth requirement. No additional context needed.

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

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

No parameters, so baseline 4. Description correctly implies no input needed beyond authentication.

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

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

Clearly states 'mark every notification...as read', specifying verb, resource, and scope. Distinct from sibling 'mark_notification_read' which handles individual notifications.

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

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

Only mentions authentication requirement. No guidance on when to use this bulk action vs the singular sibling tool.

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

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

Annotations are empty, so the description must disclose all behavioral traits. It states the mutation (mark as read) but does not mention side effects, idempotency, reversibility, or potential errors. The auth requirement is noted, but for a mutation tool, more context is expected.

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

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

The description is extremely concise with two short sentences. The action is front-loaded in the first sentence, and the auth requirement is appended efficiently. No unnecessary words.

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

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

Given the simple tool (one parameter, no output schema, no annotations), the description is minimalist. It does not explain return value or error conditions. While the action is clear, the lack of completeness for a mutation tool reduces its effectiveness.

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

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

Schema description coverage is 0%, meaning the schema provides no descriptions for the single parameter 'id'. The tool description also adds no semantic meaning about what 'id' refers to (e.g., 'ID of the notification'). The parameter's purpose is only implied by the tool name and the integer type.

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

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

The description clearly states the action ('Mark') and the resource ('a single notification') with the state change ('as read'). This distinguishes it from sibling tools like 'mark_all_notifications_read' which marks multiple, and 'get_unread_notification_count' which is read-only.

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

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

The only usage guidance is the auth requirement ('Requires IWMM_API_KEY'). There is no indication of when this tool should be used versus alternatives (e.g., marking all read), nor any exclusions or prerequisites beyond the API key.

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

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

With no annotations, the description carries the full burden. It discloses that the tool is a real write (not idempotent), adjusts inventory by default, and requires an API key. This is sufficient for an agent to understand the side effects and prerequisites.

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

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

The description is three sentences with no filler. It starts with the core purpose, then immediate side-effect info, then auth requirement. Every sentence adds value.

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

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

Given the tool has 10 parameters, no output schema, and no annotations, the description covers the essential purpose and side effects but lacks information about return value, error conditions, or the fact that it likely returns the created transaction. It is minimally complete for an agent to use correctly but leaves gaps.

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

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

The schema has 50% description coverage, but the tool description adds no additional meaning to any parameter. It does not elaborate on the role of 'type', 'quantity', or other key fields beyond what the schema provides. The description should have supplemented parameter understanding, especially for less obvious fields like 'skipInventorySync' which is already documented in schema.

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

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

The description clearly states the tool records buy or sell transactions and explains the default inventory adjustment (BUY adds, SELL subtracts). It distinguishes itself from sibling tools like list_transactions (read-only) and update_transaction/delete_transaction by emphasizing it is a 'real write' and affects inventory.

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

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

The description provides some context (it adjusts inventory by default, can be skipped with 'skipInventorySync'), but does not explicitly state when to use this tool over alternatives like update_transaction. No exclusions or when-not-to-use guidance are given.

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

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

No annotations provided, so description carries full burden. It mentions a requirement (API key) but does not disclose other behavioral traits like side effects, idempotency, or rate limits. Adequate but not comprehensive.

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

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

Three concise sentences: purpose, usage context, prerequisite. Front-loaded and no wasted words. Every sentence adds value.

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

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

Lacks explanation of return behavior (no output schema) and does not discuss side effects or relationship to sibling tools beyond implied refresh. Adequate but could be more complete.

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

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

No parameters exist, so description does not need to add meaning beyond schema. It explains what the tool does without parameters, which is sufficient for a 0-param tool.

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

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

The description clearly states the tool recalculates the user's portfolio P&L, a specific verb and resource. It distinguishes from read-only sibling tools by emphasizing 'fresh numbers' after a batch of transactions.

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

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

Explicitly says to use after recording a batch of transactions for immediate fresh numbers. Lacks explicit when-not-to-use but provides clear context for appropriate use.

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

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

Annotations already provide destructiveHint=true, indicating destructive nature. The description adds no further behavioral details beyond 'entirely' and auth requirement. For a destructive tool, this is adequate but minimal, as the annotations already cover the main behavioral trait.

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

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

Two sentences that efficiently state the action, scope, and auth requirement. No unnecessary words or redundant information. Perfectly concise for a simple tool.

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

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

For a simple removal tool with only two parameters and no output schema, the description covers the essential context: what it does, what it affects (card+finish row), and auth needed. It could mention irreversibility, but destructiveHint already signals that. Slightly above average due to completeness for its simplicity.

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

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

Schema coverage for parameters is 100%, so the schema already describes each parameter. The description adds extra context that the row is identified by card+foil combination, which is helpful but not significantly beyond the schema descriptions. Baseline 3 is appropriate.

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

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

Clearly states the action ('Remove') and the specific resource ('card+finish row from the authenticated user's buy-list entirely'). The verb 'remove' and resource 'buy-list' exactly match the tool's function and distinguish it from siblings like add_buy_list or update_buy_list.

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

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

The description mentions an authorization requirement ('Requires IWMM_API_KEY'), but does not provide explicit guidance on when to use this tool vs alternatives like update_buy_list or when not to use it. The usage context is implied by the purpose but not spelled out.

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

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

Annotations already indicate destructiveHint=true, and the description confirms it removes a card and row entirely. However, it does not detail side effects, reversibility, or what happens to the deck structure after removal, which would be helpful beyond the annotation.

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

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

The description is a single sentence plus an auth note, which is concise and front-loaded. It efficiently communicates the core action but omits some behavioral context.

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

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

With no output schema and 3 required parameters, the description provides the essential action but lacks details about return values, irreversibility, or conditions. It is minimally adequate but not fully informative for an agent.

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

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

Schema descriptions cover all parameters (100% coverage), so the description does not add significant new meaning. It reinforces that isSideboard indicates which board, but this is already in the schema.

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

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

The description clearly states the action ('Remove') and the resource ('a card + board row from a deck'). It distinguishes from sibling tools like 'add_deck_card' and 'set_deck_card_quantity' by specifying that it removes both the card and the entire row, which is a unique operation.

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

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

No guidance is provided on when to use this tool vs alternatives (e.g., setting quantity to zero via 'set_deck_card_quantity'). The description only mentions an API key requirement, which is not usage guidance.

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

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

The annotations already indicate destructiveHint: true, so the description adds value by specifying the authentication requirement (IWMM_API_KEY) and the precise scope of removal (card+finish row). No contradiction with annotations.

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

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

The description is extremely concise, using two short sentences with no redundant information. The key action and requirement are front-loaded.

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

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

Given no output schema, the description lacks information about return values or confirmation of successful deletion. It covers the core action and auth requirement but is minimal for a destructive operation.

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

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

With 0% schema description coverage, the description does little to explain the parameters beyond hinting that cardId identifies the card and isFoil determines the finish. It could explicitly state that cardId is a UUID and isFoil is a boolean for the finish type.

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

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

The description clearly states the specific action ('Remove') and resource ('card+finish row from the authenticated user's inventory'), effectively distinguishing it from sibling tools like add_inventory or update_inventory.

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

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

The description mentions the need for IWMM_API_KEY, implying authentication requirements, but does not provide explicit guidance on when to use this tool versus alternatives (e.g., delete_transaction or remove_buy_list) or any precautions despite the destructive hint.

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

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

Annotations already declare destructiveHint=true, but the description adds valuable context: the tool is premium-gated and requires an API key. It also states 'entirely' implying full removal. These go beyond the annotation and help the agent understand authorization and scope.

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

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

Two sentences, front-loaded with the action, and zero wasted words. Every sentence adds essential information.

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

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

For a simple destructive tool with one parameter and no output schema, the description covers the action, parameter source (implied), and necessary conditions (premium, API key). No critical gaps, and it complements the annotations and schema well.

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

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

Schema coverage is 100%, so the baseline is 3. The description does not add extra meaning beyond what the schema provides for the parameter 'sealedProductUuid'; it only implies its use through context ('from inventory').

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

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

The description starts with 'Remove a sealed product from the authenticated user's inventory entirely,' clearly stating the verb (remove), resource (sealed product), and scope (from inventory). This distinguishes it from siblings like 'remove_inventory' (general) and 'list_sealed_inventory' (listing).

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

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

The description explicitly states 'Premium-gated. Requires IWMM_API_KEY,' providing clear context on when the tool can be used. It does not mention when not to use it or alternative tools, but the prerequisite is clearly communicated.

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

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

Annotations declare readOnlyHint=true, and the description states it returns a paginated list with prices and metadata, which is consistent. The description adds context about pagination and return content, which is helpful beyond the annotations.

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

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

The description is two sentences, front-loaded with the primary purpose and filters, followed by a clear usage guideline. Every word is informative and there is no redundancy.

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

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

Given the 8 parameters with full schema coverage and no output schema, the description adequately explains the return type (paginated list, prices, metadata). It could mention that the response includes basic metadata and pagination details, but it is sufficient for a search tool.

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

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

All 8 parameters have descriptions in the input schema (100% coverage). The tool description does not add significant new meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool searches Magic: The Gathering cards by various criteria (name, set, rarity, type, format legality) and returns a paginated list with prices and metadata. It also distinguishes itself from the sibling 'get_card' tool by noting that for a specific printing, 'get_card' with set and number is preferred.

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

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

The description explicitly guides when to use this tool ('for catalog lookups') and when to use an alternative ('for a specific printing prefer get_card with set+number'), providing clear context for decision-making.

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

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

Annotations already declare readOnlyHint=true, so the description adds value by specifying return fields and optional pagination. However, it doesn't disclose any other behavioral traits (e.g., rate limits, default pagination behavior, whether it returns all sets or requires filtering).

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

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

Two sentences, front-loaded with action and outcome, no filler. Could be slightly more efficient by removing 'optionally paginated' if not critical, but overall concise.

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

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

Describes return fields, which compensates for lack of output schema. However, missing details like sorting, filtering capabilities, and whether it returns all sets or requires input criteria. For a simple list tool with 2 optional params, it's moderately complete.

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

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

Schema has 2 parameters (page, limit) with 0% description coverage. The description says 'optionally paginated' which hints at their purpose, but doesn't explain meaning or relationship beyond what the schema's numeric constraints imply.

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

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

The description explicitly states it lists MTG sets with specific return fields (code, name, release date, type, aggregate prices), using a clear verb+resource structure. It distinguishes from sibling tools like 'get_set' (single set) and 'search_cards' (cards).

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

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

No guidance on when to use this tool vs alternatives like 'get_set', 'search_cards', or other list tools. Only mentions optional pagination but doesn't provide context for selection among siblings.

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

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

With no annotations, description must disclose behavior. It states the tool performs a non-delta mutation, can remove a row (quantity 0), and requires an API key. However, it does not discuss error conditions, idempotency, or side effects, leaving gaps in behavioral transparency.

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

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

Two sentences efficiently convey purpose, key behavior, distinction from sibling, and authentication requirement. Front-loaded with the most critical information. No wasted words.

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

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

Description covers core operation and a sibling alternative but lacks return value description and error handling guidance. Given the tool's simplicity and absence of output schema, it is adequate but not complete.

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

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

Schema coverage is 100%, so description adds limited value. It reinforces the 'absolute' and 'not delta' nature already implied by the schema. No additional meaning beyond what the schema provides for individual parameters.

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

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

Description clearly states it sets an absolute quantity for a card and board in a deck, distinguishing it from a delta operation. It specifies the effect of quantity 0 and references the specific resource (card + board). This differentiates it from sibling tools like add_deck_card.

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

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

Explicitly tells when to use an alternative: 'Use add_deck_card to increment instead.' This provides clear guidance for selecting the correct tool. The requirement for IWMM_API_KEY is also mentioned, which helps agents understand prerequisites.

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

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

Describes operation as a 'real write' with 'upsert' semantics, indicating mutation. However, no annotations exist, and the description could mention more about side effects (e.g., overriding previous quantity is implied but not explicit). Still, it provides adequate transparency for a simple write tool.

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

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

Three sentences, each purposeful: operation description, sibling alternative, requirements. No unnecessary words. Front-loaded with primary action.

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

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

For a simple write operation with no output schema, the description covers purpose, parameters, behavior, and prerequisites. No relevant missing context identified.

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

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

Schema covers both parameters 100%, but description adds value: explains where to get sealedProductUuid (from get_sealed_products or get_sealed_product) and clarifies that quantity is absolute (not delta). This helps the agent understand parameter semantics beyond schema.

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

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

Clearly states the tool adds or updates a sealed product in the user's inventory by setting absolute quantity (upsert). Distinguishes from sibling remove_sealed_inventory by name. Verb+resource+operation are explicit.

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

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

Explicitly mentions when to use alternative (remove_sealed_inventory for deletion). Also states it's Premium-gated and requires IWMM_API_KEY, providing clear usage conditions.

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

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

With empty annotations, the description carries full burden. It discloses the absolute set behavior and that quantity 0 removes the row. However, it does not mention error states (e.g., if cardId is invalid) or whether the operation is reversible, leaving some behavioral gaps.

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

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

Two sentences only, each serving a purpose: first states the core action and exception for 0, second provides sibling differentiation and auth requirement. No wasted words.

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

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

Given no output schema, the description does not explain the return value or success/failure indicators. However, for a mutation tool with clear parameter semantics and sibling differentiation, it is nearly complete. Minor gap on return behavior.

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

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

Schema description coverage is 100%, providing baseline 3. The description adds value by explaining that the tool sets absolute quantity (not delta) and that 0 removes the row, clarifying the purpose of the quantity parameter beyond the schema's description.

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

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

The description clearly states the tool sets absolute quantity for a buy-list card+finish, explicitly distinguishing it from add_buy_list (which increments). The verb 'Set' and resource 'buy-list card+finish' are specific.

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

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

The description explicitly tells when to use this tool vs. add_buy_list ('Use add_buy_list to increment instead') and mentions the requirement for IWMM_API_KEY. It provides clear usage context without exclusions for other scenarios.

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

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

With no annotations, the description carries full burden. It discloses a behavioral trait: omitting format clears it. It also mentions the API key requirement. It does not detail side effects or error handling, but the behavior is straightforward for a rename/format update.

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

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

The description is two sentences, front-loaded with the main purpose ('Rename a deck or change its format'), with no unnecessary words. Every sentence adds information.

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

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

While the description covers the main behavior, it lacks mention of return value or success indicators. With no output schema, the agent might benefit from knowing what the tool returns (e.g., updated deck object). However, for a simple update, this is acceptable.

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

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

Schema coverage is 100% with each parameter described. The description adds value by clarifying that omitting format clears it, which is more explicit than the schema's 'Omit for no format.'

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

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

The description clearly states the verb ('Rename' or 'change') and the resource ('a deck'), with specific actions (rename or change format). It differentiates from sibling tools like create_deck, delete_deck, and get_deck by focusing on updating an existing deck's name and format.

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

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

The description provides a key guideline: 'Omitting format clears it,' and notes the API key requirement. However, it does not explicitly state when to use this tool versus alternatives like create_deck or delete_deck, though the purpose is clear.

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

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

No annotations exist, so description must fully disclose behavior. It confirms mutation but lacks details on idempotency, rate limits, side effects, or authorization beyond the key.

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

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

Three short sentences, front-loaded with purpose, immediately followed by alternative and requirement. No redundant text.

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

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

No output schema, no error handling, no mention of idempotency. However, the tool is straightforward and the description covers core usage. Adequate but with gaps.

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

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

Description adds no information about parameters; schema descriptions are present but tool description does not supplement or clarify them. Batch capability is implied but not elaborated.

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

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

Clearly states verb 'Update' and resource 'existing inventory rows', mentions batch capability. Distinguishes from 'remove_inventory' for deletion. Specific and actionable.

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

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

Explicitly directs to use 'remove_inventory' for deletion, and notes requirement of 'IWMM_API_KEY'. Provides clear context, though no further alternative guidance.

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

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

With no annotations, the description carries the full burden. It discloses that clearing thresholds is Premium-only, free users must keep one direction, and isActive toggles without deletion. It also mentions required API key. This covers key behavioral traits, though it omits details like reversibility or error scenarios.

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

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

The description is three sentences, each purposeful: first states purpose, second explains threshold and activation behavior, third notes authentication. No redundant words, efficient and front-loaded.

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

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

Despite lacking output schema and annotations, the description covers purpose, parameter behavior, constraints, and authentication. It lacks mention of return values or error conditions, but for a simple update tool with sibling context, it is reasonably complete.

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

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

Only the 'id' parameter has a schema description (25% coverage). The description adds critical meaning for the other three parameters: explains that null clears thresholds with Premium restriction, and that isActive toggles enable/disable. This compensates for the low schema coverage, though no additional info for 'id' is provided.

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

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

The description starts with 'Update an existing price alert,' which clearly states the verb and resource. It distinguishes from sibling tools like create_price_alert and delete_price_alert by focusing on modification. Additional details about clearing thresholds and toggling isActive further clarify specific update behaviors.

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

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

The description provides context on when to use by explaining the update function and including constraints (Premium vs free users, clearing thresholds). However, it does not explicitly advise against using this tool compared to delete+recreate or other alternatives, missing some guidance.

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

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

Discloses partial update behavior and field immutability constraints. However, with no annotations, it fails to mention side effects, success/error responses, or any other consequences of mutation. The absence of return value information is a notable gap.

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

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

Two concise sentences, front-loaded with the core action and partial update. No redundant words. Every sentence provides critical information.

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

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

Covers purpose, partial update, constraints, and auth. Lacks return value, error handling, or prerequisites beyond API key. For a 7-param mutation tool with no output schema, more detail on invocation results is needed for full completeness.

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

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

Schema description coverage is only 14%, so the description must compensate. It implies that optional fields (date, fees, etc.) are updatable, but does not explain their meaning, format, or constraints (e.g., date format, fee range). The description adds little beyond the schema's sparse property names.

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

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

Clearly states it updates an existing transaction by ID, with partial update semantics. Distinguishes from delete/re-create for card identity/type, which is a key differentiator from sibling tools like record_transaction and delete_transaction.

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

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

Explicitly says when to use (update transaction) and when not to (to change card identity/type, delete and re-create instead). Also specifies required auth (IWMM_API_KEY), providing clear prerequisites.

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