policy-gate

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

With no annotations provided, the description carries the transparency burden. It clearly states that the tool initiates a $42 payment and returns a complete list of payment rails (card, USDC, BTC, x402, Zelle, invoice). It does not disclose prerequisites or failure handling, but the core financial action is explicit.

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: action, output list, business rule. Front-loaded with the core verb and object, no redundant phrases. 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?

Despite having no annotations or output schema, the description lists all return values (Stripe card_uri, USDC uri, BTC uri, x402 POST /v1/sponsor, Zelle, GET /v1/invoice) and clarifies the settlement rule. This fully covers what an agent needs to know to call and interpret 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 input schema has zero parameters, so the schema conveys nothing. The description compensates by defining the fixed $42 amount and enumerating the return items, giving the agent complete semantic understanding of the no-input call.

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: 'Pay Fieldproof $42' with a specific amount and recipient. It also specifies what is returned (live rails with specific URIs), distinguishing it from sibling policy-check 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 provides clear context that this tool satisfies the first-$42 payment requirement ('One settlement meets the first-$42 bar') and returns payment rails. It does not explicitly list when not to use it, but the sibling tools are policy-related, so the usage intent is unambiguous.

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 the full burden. It discloses the paid per call via x402 cost and the unpaid signing-instructions behavior, which is valuable context. It also states the output format; the word 'proposed' implies no action execution, though it does not state this explicitly.

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 and outcomes, with no filler. The cost note is essential and compactly integrated.

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 core outcome vector and the payment failure mode, which is sufficient for a tool with no output schema. It does not mention cumulative ledger edge cases, but those are documented in the parameter schema, so overall 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?

The tool description itself adds no parameter-level semantics, but the input schema provides 75% coverage with rich descriptions for request.action, ledger fields, and policy_id. Since coverage is neither very high nor very low, a baseline 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?

Clearly states it evaluates a proposed agent action against a policy and returns allow/require_approval/deny with rule and rationale. This is a specific verb and resource, but it does not explicitly differentiate from sibling tools like policy_rules or policy_example.

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 mention when to use this tool versus alternatives or when not to use it. It provides no exclusions or references to sibling tools like policy_rules, policy_example, or first_42_sponsor.

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 the full burden. It reveals that the tool is free and returns verdicts from a live engine, but it does not mention side effects, safety, rate limits, or whether the live engine has any impact. The description lacks information about behavior beyond the basic function.

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 short (one sentence plus a fragment), but the phrasing is awkward and contains a typo. The sentence is front-loaded with 'Free' but then becomes verbose with 'so you can judge the service before paying for it'. It is concise but not polished.

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 tool with no output schema, the description covers the key purpose (verdicts) and value proposition (free trial). However, it does not explain the output format or explicitly differentiate from policy_check and policy_rules, leaving some context 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 tool has zero parameters, and the schema coverage is 100% (vacuously). The description correctly does not attempt to explain parameters. With no parameters, the baseline of 4 is appropriate, and the description adds no irrelevant 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?

The description states it returns allow/require_approval/deny verdicts from the live policy engine, which is a specific verb+resource. It also distinguishes itself from siblings by emphasizing it's free and for pre-purchase evaluation. The minor typo ('Worked' instead of 'Works') slightly weakens clarity, but the intent is clear.

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 evaluating the service before payment ('so you can judge the service before paying for it'), but provides no explicit guidance on when to use this tool versus the sibling tools (first_42_sponsor, policy_check, policy_rules). No exclusions or alternatives are mentioned.

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 shoulders the burden of behavioral disclosure. It states the tool is 'Free' and emphasizes full transparency ('Nothing hidden'), which gives the agent confidence about scope and cost. However, it does not explicitly confirm a read-only nature, although the zero-parameter design makes side effects impossible.

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: two short sentences that immediately convey cost, scope, and completeness. There is no filler or redundancy, and the most important information ('full built-in policy') is 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 simple, parameterless informational tool, the description is fully complete: it explains what is included (tiers, rules, conditions, rationale) and explicitly addresses transparency. No output schema or complex behaviors require further clarification.

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 there is nothing to explain. Per the rubric, a 0-parameter tool receives a baseline of 4, and the description adds useful context about what the tool returns instead of needing to describe 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 that this tool exposes the complete built-in policy, including every tier, rule, condition, and rationale. It distinguishes itself from siblings like policy_check and policy_example by emphasizing 'full' and 'every', making the resource scope 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?

The phrase 'Nothing about how a verdict is reached is hidden' implies use this tool when you need the complete policy rationale, as opposed to simply checking a verdict or viewing an example. While it does not name alternatives explicitly, the 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.