Boundary Guard x402

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

Annotations already declare readOnly, idempotent, not destructive, so the bar is lower. The description adds useful context: 'deterministic,' 'pre-action receipt,' and 'no external action is executed,' which clarifies the tool's side-effect-free and audit-focused behavior. It does not contradict annotations and adds value beyond them.

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 fluff. The first sentence states purpose and inputs; the second gives usage timing and reassurance about safety. Every word earns its place and the key information 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?

Given the presence of an output schema, full schema coverage, and robust annotations, the description is complete enough. It explains what the tool does, when to use it, what inputs are expected, and that no external action occurs. No critical gaps remain for an agent 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?

Schema coverage is 100%, so the baseline is 3. The description goes slightly beyond by enumerating the core inputs ('request, policy, and optional result evidence'), which maps to three of the four parameters and helps the agent understand their roles. It omits 'nextStep' but the schema covers that.

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+resource: 'Create a deterministic, read-only pre-action receipt' and clearly scopes it to 'from request, policy, and optional result evidence.' It distinguishes itself from sibling tools by emphasizing it is a pre-action audit receipt with no external action, which separates it from launch packs and resource probes.

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?

It explicitly states when to use: 'Use before an agent posts, spends, lists, or writes so the decision can be audited.' It also clarifies a key exclusion ('no external action is executed'). However, it does not explicitly name alternative tools or when not to use it, so it stops short of a 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 readOnlyHint, openWorldHint, idempotentHint, and destructiveHint as safe. The description adds valuable behavioral context: deep/report tiers perform 'unpaid 402 probing' when paid_path is supplied, which indicates active probing of a paid endpoint without making a payment. It also lists the discovery surfaces scanned, which is not present 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?

The description is two well-structured sentences. It front-loads the core purpose, then lists key parameters and behavioral triggers. No filler, redundant information, or repetition of schema elements; every clause 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 existence of an output schema, the description appropriately focuses on selection and invocation context. It explains what the tool does, when deep/report tiers probe, which parameters matter, and the cost tiers. It is complete for an agent to decide when to use it and how to invoke it, especially with sibling tools available for alternative operations.

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 covers all 7 parameters with descriptions (100% coverage), so the baseline is 3. The description adds extra meaning beyond the schema: it explains tier pricing ($1/$5/$10), the optional parameters to pass, and the relationship between tier and paid_path (deep/report tiers add unpaid probing). This semantic enrichment goes beyond the schema's bare definitions.

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 ('check') and resource ('x402/agent-facing tool') and clearly states the purpose: readiness for agent routing, marketplace listing, and paid-path monitoring. It lists concrete discovery surfaces, and the surrounding sibling tools (probe_x402_paid_path, scan_x402_resource) make the differentiation 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 gives clear context on when to use the tool: to check readiness for routing, listing, and monitoring. It also explains tier options and when deep/report tiers trigger unpaid 402 probing. It does not explicitly name alternatives or exclusions, but the sibling tool names and the phrase 'unpaid 402 probing' imply when this tool is the right gate versus actual probing 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?

The description adds the 'deterministic' trait and a critical security warning about omitting raw auth headers, cookies, keys, etc. This goes beyond the annotations (readOnly, idempotent) and provides practical behavioral guidance for safe invocation.

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 the main purpose first. The second sentence is a long list of prohibited data types, which is a bit dense but still structurally clear. 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?

The tool has an output schema and 5 parameters with rich schema descriptions. The description covers input constraints but omits when to use the tool in context with sibling tools. Given the complexity, the description 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?

Since all 5 parameters have detailed schema descriptions (100% coverage), the baseline is 3. The tool description's security warning is somewhat redundant with schema descriptions but does consolidate a global constraint, adding marginal value.

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 'Generate a deterministic trust receipt from sanitized request/policy/result/payment summaries' with a specific verb and resource. It clearly distinguishes from sibling tools like boundary_guard_check or generate_x402_launch_pack which serve different purposes.

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 generating trust receipts from sanitized data but provides no explicit 'when to use' vs alternatives. It does not mention alternatives or conditions for use, so guidance is only implied.

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 agent knows this is safe. The description adds the tier-related behavioral detail that service/premium packs include readiness evidence, but it does not disclose the potential network probing behavior implied by paid_path (though the schema covers that). With annotations providing the core safety profile, 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 two sentences long, front-loads the core purpose, and packs in the essential input guidance and tier pricing without any fluff. Every sentence earns its place, making it highly efficient 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 tool's complexity (11 parameters, output schema present), the description gives a solid high-level overview of the main inputs and outputs. It doesn't mention every parameter, but the schema descriptions and output schema fill in the gaps. It could have noted the existence of optional parameters like method or expected_resources, but the description is still complete enough for an agent to understand the tool's role and 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 the schema already documents all 11 parameters. The description names several key optional parameters (product_name, audience, primary_use_case, marketplace_url, paid_path) and clarifies that target is required, but it repeats tier pricing already in the schema. It adds only marginal meaning beyond the schema, such as tying readiness evidence to service/premium tiers.

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 a specific action ('Generate marketplace-safe launch assets') and specifies the resource (x402/MCP seller) and the exact deliverables (listing copy, buyer FAQ, checklist, approval packet, claim boundaries). It is unmistakably distinct from sibling tools like probe_x402_paid_path or scan_x402_resource, which focus on validation rather than asset generation.

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 for when to use the tool: when a seller needs launch assets. It explains the basic input pattern ('Pass target plus optional...') and notes tier-specific behavior. However, it does not explicitly state when not to use it or mention alternative tools, so it falls just short of a 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 readOnlyHint and idempotentHint, but the description adds valuable context: 'without signing or paying' implies no side effects, and 'receive a deterministic health receipt' clarifies output behavior. This goes beyond the annotations without contradicting them.

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 core action, and no filler. The second sentence adds actionable details about parameters and output. 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?

The description covers the core action, input expectations, and outcome (deterministic health receipt). Output schema exists, so return values need not be spelled out. It could elaborate on mode/method options, but these are already documented in the schema, making the description sufficient for this 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?

Schema description coverage is 100%, so the baseline is 3. The description mentions 'target plus optional expected network/asset/price', which corroborates the schema but adds no new semantic detail 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 identifies the verb ('probe'), the resource ('public x402 paid endpoint'), and distinct behavioral aspects ('without signing or paying', 'parse the HTTP 402 challenge'). It also mentions the deterministic health receipt, which sets it apart from sibling tools like scan_x402_resource.

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 for when to use the tool—probing a paid endpoint without payment and verifying payment metadata. It does not explicitly exclude alternatives or name sibling tools, but the intended use case is evident from the wording.

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, openWorldHint, idempotentHint, and non-destructiveness. The description adds the concrete guarantee that no private endpoints are called and that the result includes a readiness score, issues, and fixes, enriching the behavioral picture 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?

Two tightly written sentences: the first states purpose and scope, the second states inputs and outputs. Every word earns its place, and the most important information (read-only, public URL) 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?

With an output schema present, the description sufficiently covers what the tool does, what it accepts, and what it returns (score, issues, fixes). The sibling context and annotations fill in remaining gaps, but the description itself doesn't explicitly address alternative use cases or edge conditions, so it's strong yet not maximal.

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% description coverage for all three parameters. The description simply lists the parameter names (url, marketplace_url, expected_resources) and doesn't add new semantics beyond what the schema offers, 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 opens with a specific verb ('scan') and resource ('public API/provider URL'), and enumerates the metadata types scanned (x402, OpenAPI, pricing, agent-discovery). This clearly distinguishes it from sibling tools like probe_x402_paid_path, making the tool's purpose unmistakable.

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?

It states the tool is for read-only scanning of public URLs and explicitly notes no private endpoints are called, which gives clear context for when to use it. However, it does not name alternative tools or provide explicit 'when not to use' guidance, so it falls just short of the top score.

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