Evercraft Machine Commerce

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds that the catalog is authoritative and public, but mostly restates 'read-only' without adding deeper behavioral context 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 a single front-loaded sentence with no filler. Every phrase contributes meaning: the action, the resource, and the read-only nature.

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 one-parameter, read-only discovery tool with rich annotations and sibling context, the description is largely sufficient. It doesn't need to enumerate return shape since it is a free-form catalog match, though a bit more detail about output would push it higher.

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 intent parameter has 0% schema description coverage, so the description must compensate. The phrase 'user problem' tells the agent that intent should contain the user's request, but it does not specify format, examples, or constraints beyond the schema's maxLength.

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 uses a specific verb, 'Match', with a clear object: the authoritative public Evercraft commercial catalog. It signals a discovery/semantic-matching role that is distinct from siblings like get_evercraft_offers or prepare_evercraft_checkout.

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 conveys that the tool maps a user problem to catalog entries, which implies when to use it. However, it never explicitly states when not to use it or names alternatives such as get_evercraft_offers or get_evercraft_order_status.

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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description's 'Return' is consistent with these hints but adds no new behavioral context, such as the nature of the rules or any side effects. With annotations carrying the safety profile, the description provides minimal extra transparency, so a 3.

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, front-loaded sentence with no filler. It communicates the core action and object efficiently. Full marks for conciseness.

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 no-parameter, read-only retrieval tool, the description is reasonably complete. However, without an output schema, the agent is left to infer the structure or format of the returned 'rules,' which are described in domain-specific terms. This is adequate for a simple getter but leaves some ambiguity, so a 3.

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 accepts zero parameters, so there are no parameter semantics to clarify. The description's mention of 'rules' does not add parameter-related meaning, but none is needed. Per the rubric, 0 params warrants a baseline of 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 states a clear verb 'Return' and identifies the resource as 'shared authority and truth rules for machine commerce.' It does not explicitly contrast with sibling tools, but the resource is distinct enough from services, offers, order status, and checkout to infer its purpose. This is clear but lacks sibling differentiation, so a 4.

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 no guidance on when to invoke this tool versus alternatives. There are no conditions, caveats, or references to sibling tools. This is a clear absence of usage direction, so a 2.

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, idempotentHint, and destructiveHint, so the description's main job is to add behavioral context. It does so by confirming 'live product gateway' access and explicitly ruling out checkout, invoice, charge, or payment obligations, which is valuable for a commerce-related 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?

The description is two short sentences with no filler. The core purpose is front-loaded, and the side-effect clarification earns its place by preventing misuse.

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 read-only tool with strong annotations, the description is mostly adequate, but it lacks explicit guidance on how it relates to sibling tools and what 'current terms' will contain in the response, especially since there is 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 0%, so the description must compensate for the single service_id parameter, but it never mentions service_id or how to choose a value. The enum values are self-descriptive, yet the description adds no parameter-level meaning beyond what the raw schema field name implies.

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 uses a specific verb ('Read') and resource ('current terms from a live product gateway'), clearly indicating a read operation. It also explicitly states it creates no checkout, invoice, charge, or payment obligation, which separates it from commerce-related sibling tools.

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 the tool is for reading current service offer terms, but it does not explicitly state when to use this instead of siblings like discover_evercraft_services or get_evercraft_commerce_rules. The no-side-effect wording is a negative guarantee, not a direct usage guideline.

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 operation as read-only and idempotent, so the bar for additional disclosure is lower. The description adds meaningful behavior beyond the annotations by noting that details are passed to the product gateway and that supported gateways independently verify provider payment before reporting paid state. This helps the agent understand the external verification behavior without contradicting 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 compact at two sentences with no filler, and the second sentence adds genuinely useful behavioral context. The only structural weakness is the slight mismatch between the tool name's 'get' action and the description's 'Pass ... back' phrasing, which could confuse on first read.

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, the description should explain return semantics, but it only hints at 'reporting paid state' without defining other possible statuses, errors, or what happens when payment is not verified. It also omits practical details like what to put in the details object and how to choose among the service_id enum values. An agent would likely need further information to invoke this reliably.

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%, and the details parameter is an arbitrary object with no property descriptions, so the description must compensate. It only says 'product-specific tracking details' and never explains which fields belong in details or how service_id maps to specific gateways/products. This is too thin to construct the request correctly.

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 title and tool name clearly supply the verb+resource: get verified Evercraft order status. The description adds the mechanism ('Pass product-specific tracking details back to the product gateway'), and the scope is distinct from siblings like get_evercraft_offers or prepare_evercraft_checkout. It is not perfectly explicit that the tool returns the status, but the intent is recoverable.

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 when you have product-specific tracking details and need gateway-verified payment/order status, but it never explicitly names alternatives or states when NOT to use this tool. Sibling tools are not referenced, so the guidance is contextual rather than exclusionary.

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 this as non-read-only and open-world, and the description adds value by stating the human-confirmation gate and the caveat that checkout creation is not payment proof. This gives agents useful behavioral context beyond the structured fields, with 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?

The description is only two sentences, with the condition front-loaded and the 'not payment proof' caveat earning its place. There is no redundant or filler content.

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 output schema, a free-form details object, and a 9-value service_id enum, the description leaves the agent without guidance on return values or how to populate details. It covers the gating condition but not enough to call the tool correctly beyond the literal 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 0%, so the description must carry parameter meaning. It indirectly maps 'human explicitly agrees to pay' to user_confirmed_payment and 'product-specific checkout details' to details, but it says nothing about service_id, its enum values, or the expected structure of 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?

The description uses a specific verb ('route') and resource ('product-specific checkout details to the verified product gateway'), clearly stating what the tool does. It also semantically distinguishes the tool from the read-oriented siblings (discover/get_*) by framing it as the checkout-creation 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?

The first clause gives an explicit precondition: use only after the human explicitly agrees to pay. However, it does not name alternative tools or provide when-not-to-use guidance, so it stops short of a full routing rule.

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