cdk-mcp

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

No annotations are provided, so the description must convey behavior. It describes the tool as listing filter options but does not discuss data source, freshness, or side effects. However, with zero parameters, the behavior is straightforward.

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. First sentence states purpose, second provides usage guidance. Perfectly concise 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?

For a tool with no parameters, no output schema, and no annotations, the description fully covers what the agent needs to use it correctly.

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

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

There are zero parameters, so schema coverage is 100%. The description adds no parameter info, but baseline for zero params is 4. Nothing 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 the verb 'list' and the resources 'platforms, devices, regions, and languages' for filtering digital product searches. It distinguishes this tool from siblings which handle orders, purchases, and reviews.

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?

Explicit guidance is given: 'Call this first to know what filter values are valid.' This implies it should be used before searches. No alternatives are mentioned, but siblings are unrelated.

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 wallet_address is required to retrieve the product key and that pending orders are polled automatically. It implies a read operation but lacks details on side effects or security implications.

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

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

Two concise sentences with no waste. The first sentence states the primary purpose, the second adds key additional details. 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?

For a simple status check tool with no output schema, the description covers the main behaviors: checking status, retrieving key, and automatic polling. Missing details like error handling or response format, but adequate for the 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 is 100%, baseline 3. The description adds value by explaining the purpose of wallet_address (to retrieve product key), going beyond the schema text 'Buyer wallet address'. Order_id is adequately described 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 tool checks the status of a purchase order and can retrieve the product key. It is distinct from sibling tools like confirm_purchase or get_price_quote, though not explicitly differentiated.

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 (wallet_address for key retrieval, automatic polling for pending orders) but does not specify when not to use this tool or offer alternatives. Usage is implied rather than explicit.

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 full burden. It discloses the two payment flows, conditional parameter requirements, and gasless settlement, but does not cover error handling or post-payment behavior (e.g., what happens on failure). Generally 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 concise with two sentences covering all key aspects. It is front-loaded with the main purpose, but could be slightly more structured (e.g., bullet points) for readability. Still 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 the complexity of conditional parameters and two flows, the description covers essential usage context. However, it lacks explicit mention of the output (e.g., whether it returns a product key or confirmation), and no output schema is provided. Still, it is mostly complete for an agent to invoke 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?

Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the conditional logic between 'tx_hash'+'quote_id' and 'x_payment,' which is not fully captured in the schema. However, it does not elaborate on parameter formats 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?

The description clearly states the tool's purpose: 'receive the product key after paying.' It specifies the verb 'receive' and the resource 'product key,' and distinguishes this tool from siblings like 'get_price_quote' and 'check_order' by focusing on payment completion.

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 explains two payment flows, implying usage after obtaining a quote from 'get_price_quote.' However, it lacks explicit guidance on when not to use this tool (e.g., for order status checks, which might be handled by 'check_order'). Sibling differentiation is present but not exhaustive.

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 carries full burden. It describes the tool as retrieving detail information, which implies read-only, but doesn't explicitly state behavior (e.g., no side effects, authentication needs). 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?

Single sentence, front-loaded with purpose, no wasted words. Efficiently conveys key 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?

Given one required parameter and no output schema, the description covers what the tool does and where to get input. Missing details about output format or error cases, but sufficient for a simple retrieval 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?

Only one parameter (game_id) with schema description 'Game ID (UUID) from search results'. The description reinforces this ('Use the game_id from search_games results'). Schema coverage is 100%, so baseline is 3; description adds minimal additional semantics beyond usage hint.

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 provides detailed information about a specific digital product, listing examples (game key, gift card, DLC) and attributes (price, activation instructions, delivery time). Distinguishes from siblings by referencing game_id from search_games.

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 instructs to use game_id from search_games results, implying proper usage context. Could be improved with explicit when-not-to-use or alternatives, but the guidance 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 provided, so description carries full burden. Mentions locking price (non-destructive) and quote_id validity. Adequately discloses behavioral traits for a read-like 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?

Two sentences, no wasted words, front-loaded with main action. Efficient and clear.

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 notes quote_id return. Sibling tools provide context. Adequate for a simple price quote tool with 2 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 description coverage is 100%, baseline 3. Description does not add parameter-specific meaning beyond what is in the schema; it focuses on overall behavior.

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 locks current price for a digital product and provides USDC payment instructions. It specifies the return value (quote_id) and validity period, distinguishing from sibling confirm_purchase.

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 implies usage context by mentioning the flow: get quote, then pay, then use confirm_purchase. It does not explicitly state when not to use, but the flow is clear and references a 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?

No annotations provided, so description carries behavioral burden. It discloses processing times for different reason types, but does not mention side effects, authority requirements, or result format. 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, front-loaded with main action, no filler. Every sentence adds value: action, condition, and processing details.

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 complete parameter schema and no output schema, the description still explains outcomes for different reasons. Lacks return value description, but sufficient for a refund submission 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%, baseline is 3. The description mentions the time constraint (30 days) which is not in schema, but repeats reason enum semantics without adding significant new meaning.

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's action: 'submit a refund claim for a purchased product key'. It distinguishes from siblings like check_order and confirm_purchase by specifying the refund 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?

Provides explicit condition 'Must be within 30 days of purchase' and explains outcomes for different reasons (auto-approved for not_delivered, verified within 24 hours for key issues). Does not explicitly list when not to use, but offers good 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?

With no annotations, the description bears full responsibility. It discloses that the tool uses 'smart matching' and returns 'a best match with alternatives', which is transparent for a search tool. It lacks details on rate limits, authentication, or error handling, but these are less critical for a search operation.

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

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

The description is two concise sentences, front-loaded with the core purpose. Every word contributes value, 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?

For a search tool without output schema, the description adequately explains the return type ('best match with alternatives') and provides actionable context (use browse_filters first). No critical information is missing for effective agent 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?

The schema covers 100% of parameters, so the description's value-add is limited. It mentions filtering by title, platform, device, region, or language, which aligns with the schema but adds no substantial new meaning beyond 'smart matching'.

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: searching a catalog of digital products (game keys, gift cards, DLC) by multiple criteria. It distinguishes itself from sibling tools like browse_filters and get_game_details by specifying search behavior.

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 advises using browse_filters first to see valid filter values, providing clear context. However, it doesn't explicitly state when not to use this tool or mention alternatives 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?

No annotations are provided, so the description carries full burden. It discloses the action (rating) and uniqueness constraint (one per order), but does not state side effects like whether reviews are editable, if confirmation is received, or if specific authentication is needed beyond wallet ownership. Given the lack of annotations, this is a significant gap.

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

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

Three sentences front-loaded with purpose. The first sentence gives the core action and benefit. The second adds a constraint. The third lists verified requirements. No filler or repetition. Could omit 'Helps improve the service' without loss, but overall 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 no output schema and moderate complexity (5 params, 3 required), the description covers purpose, key constraint (one per order), and required params (order_id and wallet_address). However, it lacks information about the response format, confirmation, or edit capabilities, which would help the agent fully understand the tool's 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?

The input schema has 100% description coverage for all 5 parameters. The description adds context that wallet_address must match the order and reinforces that rating is 1-5 and order_id is required. However, it does not add meaning beyond what is already in the schema for parameters like comment or agent_name. 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 rates a completed purchase on a 1-5 star scale and mentions it helps improve the service. The verb 'rate' and resource 'completed purchase' are specific, and the star scale is explicit. It distinguishes from sibling tools like confirm_purchase or check_order, though not directly comparing.

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 implicit usage context: after a completed purchase, with required parameters order_id and wallet_address. The constraint 'One review per order' guides use, but there is no explicit mention of when not to use this tool or alternatives like request_refund for issues.

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