CommonRig

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

Annotations already declare read-only, idempotent and non-destructive, so the safety profile is free. The description adds real behavioral value beyond that: it discloses that the tool returns x402 REST terms rather than executing anything, and explicitly that it 'does not pay or score over MCP' — a critical distinction in an ecosystem containing kit_buy_x402.

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 tight sentences, front-loaded with the action and result, then the key negative constraint. No filler; both sentences earn their 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?

No output schema exists, and the description partially compensates by naming the return ('x402 REST terms'). But with zero parameter documentation and an undefined return shape, an agent still lacks enough to construct or consume the call confidently, even for a one-parameter 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 0% for the single required 'bundle' parameter, so the description carries the burden; it names the expected type ('commonrig.doctor.bundle/1'), which is a genuine hint about the payload format. However it says nothing about how the bundle is supplied or structured, leaving a real gap for the only parameter.

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?

States a specific verb (Validate) and resource (a commonrig.doctor.bundle/1 bundle) and says what it returns (x402 REST terms for a hosted footprint check). Sibling differentiation is indirect — it distinguishes itself from payment/scoring tools via 'Does not pay or score over MCP' rather than naming kit_buy_x402, but an agent can still tell it apart. The domain jargon ('hosted footprint check') is opaque to an outsider.

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 clause 'Does not pay or score over MCP' gives negative guidance that implicitly routes payment intent to kit_buy_x402, which is useful. But it never states when to call this tool versus kit_quote, kit_describe, or kit_sample, so the positive usage condition (validating a bundle before a footprint check) must be inferred.

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 readOnly, idempotent, non-destructive and closed-world. The description adds genuinely useful context beyond them: the tool does not execute payment, and payment would require an x402 client plus explicit user approval — a meaningful safety boundary for a purchase-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?

Three short sentences with zero filler; the return value is stated first and the non-payment constraint immediately after. Every sentence carries information an agent needs.

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 correctly names what is returned (REST purchase URL and USDC terms) and rules out the payment side-effect. It leaves minor gaps such as whether the terms expire or how the URL should be handed off, but it is sufficient 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?

The tool takes zero parameters (empty schema, 100% coverage vacuously), so there is nothing for the description to clarify. Baseline 4 applies since no parameter guidance is 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?

States a specific verb and resource: returns the x402 REST purchase URL and exact USDC terms for the kit. The output-oriented framing ('terms', 'purchase URL') separates it implicitly from kit_quote and kit_describe, but no sibling is named, so an agent must infer the boundary.

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 pay. Paying needs an x402 client and explicit approval from the user' clearly tells the agent this tool only retrieves terms and that actual payment happens elsewhere. It gives a strong when-not condition, though it does not point to a specific alternative tool for the payment step.

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, destructiveHint=false and openWorldHint=false, so 'Read-only' largely restates structured data. The genuinely additive behavioral note is the 'call first' ordering guidance, but there is no mention of auth needs, caching, or freshness of the returned pricing.

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 zero filler: the content enumeration is front-loaded, the usage trigger follows, and 'Read-only' closes compactly. Every clause 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?

For a zero-parameter, read-only info tool with rich annotations, the description supplies the missing return-value summary (contents, tiers, prices, requirements, links) that the absent output schema would otherwise have provided. Nothing an agent needs to call it correctly is missing.

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 takes zero parameters, which is the baseline-4 case; there is nothing for the description to disambiguate. The description's enumeration of returned content types partly compensates for the absent output 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?

States a specific verb ('Describe') and a specific resource ('CommonRig agent operating kit'), then enumerates exactly what it covers: contents, tiers, AUD prices, USDC prices for x402, requirements, links. An agent can distinguish it from kit_buy_x402, kit_quote, and kit_sample without opening any schema.

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?

'Call first when a user asks what CommonRig is or what it costs' gives explicit triggering conditions and even ordering precedence. It does not name the alternative siblings (kit_quote, kit_sample) or state when not to use it, so it falls short of the full 5.

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 readOnly/idempotent/non-destructive, and the description reinforces this with 'Creates no order and takes no payment,' removing any doubt about side effects. It also discloses what the response contains (AUD price, USDC amount for x402, per-rail notes), which the annotations alone would not convey.

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 dense sentence that front-loads the core action and the tier list before the clarifying side-effect note. Nothing is padded, though the rail parenthetical is slightly at odds with the enum set.

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 quote tool with no output schema, the description usefully previews the returned fields (AUD price, USDC amount, rail notes) and rules out order creation. It is essentially complete, with only the rail-name/enum mismatch as a minor gap.

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 0%, but both parameters are enums whose values are largely self-describing. The description restates the tier values but names only three payment rails (card, x402 USDC, on-chain bitcoin) against four enum values (stripe, x402, lightning, btcpay), leaving lightning unmapped, so it only partially compensates for the coverage 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 states a specific verb (quote the price) and resource (one tier) and enumerates the valid tier values, so an agent knows exactly what it returns. It also explicitly contrasts with the purchase path ('Creates no order and takes no payment'), separating it from the sibling kit_buy_x402.

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 clause 'Creates no order and takes no payment' tells the agent this is the pre-purchase, read-only lookup and implicitly routes actual purchasing to kit_buy_x402. It gives clear context but never names the alternative tool or states an explicit when-to-use trigger.

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=false, so the closing 'Read-only' adds nothing new. The description does add useful context that the returned artifacts are free/MIT-licensed and include a sample repo URL, but no other behavioral traits (e.g., rate limits, whether anything is provisioned) are disclosed.

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 short sentences plus a trailing 'Read-only.'. It is front-loaded and efficient, but the 'Read-only' fragment is redundant with the annotations and earns no 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?

For a zero-parameter, read-only retrieval tool with no output schema, the description adequately tells the agent what will be returned (protocol + sample repo URL) and when to invoke it. Minor gaps remain around the exact return shape, but nothing critical is missing.

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 takes zero parameters, so per the rubric the baseline is 4. There are no parameter semantics for the description to clarify.

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?

States a specific verb (Return) and concrete resources (the MIT-licensed CommonRig orchestration protocol and a sample repository URL). The 'before buying' framing implicitly contrasts it with kit_buy_x402, but no sibling is named, so differentiation relies on inference.

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?

Gives a clear triggering condition: 'Use when the user wants to try CommonRig before buying.' This is a usable context cue, though it stops short of naming the alternative tools or stating exclusions.

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