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

With no annotations, the description carries the full burden and covers behavior well: it includes earlier runs, returns a chain verification result, and clarifies that optional IDs are only identifiers and do not trigger a spend decision. It stops short of explicitly labeling this tool read-only, but the export semantics and non-spend-decision note make behavior largely 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?

Three sentences, each with distinct content: output, scope, then parameter semantics. The core result is front-loaded and no words are wasted.

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 no output schema or annotations, the description covers the return format, scope, and parameter semantics. It would be more complete with an explicit statement of side effects or when the chain verification result can be considered authoritative, but nothing essential for invoking the tool 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?

Schema coverage is 100%, so baseline is 3. The description adds value by stating that the IDs accept identifiers only and are bound into the signed actor by spend_decide, clarifying different treatment in read-only/cost tools beyond the schema's field descriptions.

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 action ('Export'), resource ('tenant decision ledger'), and output shape ('hash-chained array of signed receipts with a chain verification result'). The scope qualifier 'including earlier process runs' makes it distinguishable from siblings like verify_receipt.

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?

No explicit when-to-use or when-not-to-use guidance against siblings. 'Memory mode exports this process only' implies a context limitation but does not name alternatives such as verify_receipt or provenance_preview.

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 and discloses the key behavioral traits: read-only operation, no spend decision recorded, the specific attestation fields returned, and that China-origin families are flagged. It stops short of covering error behavior, authentication needs, or return formatting, but the core safety profile and output scope are clearly stated.

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 with a front-loaded purpose and the no-spend guarantee placed first. The final sentence slightly overlaps the first ('WITHOUT spending' vs 'without recording a spend decision'), but each sentence otherwise earns its place by covering outputs, parameter constraints, and cross-tool behavior.

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 read-only preview tool with no annotations and no output schema, the description covers the essential ground: what is previewed, the cost-safety property, the identifier-only constraint, and the relationship to spend_decide. It could go further by describing how China-origin flagging manifests in the output and the role of endpoint_url, but nothing needed for safe invocation 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 description adds real meaning beyond the schema for the optional IDs — 'accept identifiers only' and the fact that spend_decide signs them into the actor fields — which goes beyond the schema's $ref descriptions. However, it adds nothing for model or endpoint_url, which are the two parameters lacking schema descriptions, so the 60% coverage gap is only partially compensated.

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 and resource ('Preview the provenance AgentGuard would attest') and enumerates exactly what is previewed: model identity, weights origin country, hosting jurisdiction, retention posture. The emphatic 'WITHOUT spending' distinguishes it from the sibling spend_decide, so an agent can tell them apart without inspecting schemas.

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 for when this tool fits — checking provenance with no spend commitment — and contrasts it with spend_decide, which binds identifiers into the signed actor. It also notes that read-only and cost-configuration tools accept these fields without recording a spend decision. However, it never explicitly names an alternative or states a when-not-to-use condition, leaving routing to inference.

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 the behavioral burden. It discloses the fail-closed behavior, the pricing unit (cents per 1,000 tokens), and the semantics of optional identifiers being bound into the signed actor by spend_decide. It could mention idempotency or update behavior, but it is transparent about key side effects.

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 and well-structured: purpose first, required behavior next, optional parameter semantics last. Every sentence adds information without repetition or filler.

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 six-parameter tool with no output schema and no annotations, the description covers the essential context: when registration is needed, the pricing unit, fail-closed behavior, and how optional identifiers are used downstream. It does not describe return values or error cases, but the schema plus description are 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?

Schema coverage is only 50%, so the description must compensate. It adds crucial meaning for the two pricing parameters by specifying 'Cents per 1,000 tokens', and clarifies that optional IDs accept identifiers only. This adds value beyond the schema's type and pattern constraints.

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 and resource: 'Register a cost for a model with no built-in pricing'. It also distinguishes itself from the sibling spend/provenance tools by clarifying this is a cost-configuration action, not a spend decision or read operation.

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 gives clear usage context: required for self-hosted models and AgentGuard fails closed on unknown costs. It does not explicitly name an alternative tool or a when-not-to-use condition, but the context is strong enough to guide selection.

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 of behavioral disclosure. It fully discloses the return format (allow/block + Ed25519-signed receipt), provenance content (weights origin, jurisdiction, retention), privacy stance (content-free, never prompt content), fail-closed behavior for unknown self-hosted models, and how optional identifiers are bound into the signed actor. This is far richer than the typical 'updates settings' description.

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?

Five sentences, each earning its place: purpose, metadata constraint, return value/provenance, prerequisite, and identifier semantics. The main action is front-loaded ('Gate a model call BEFORE it runs'), and there is no filler or repetition.

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 7 parameters and no output schema, so the description must cover return values and edge behavior. It explains the allow/block decision, the signed receipt with provenance, fail-closed behavior, and identifier restrictions. It does not describe every error path, but for a gating tool the core context an agent needs to call it correctly is present.

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 adds meaningful semantics: it classifies model, token counts, and endpoint_url as metadata, warns never to pass prompt content, restricts agent_id/task_id/workflow_id to identifiers, and clarifies that unrecognized endpoint_urls route as self-hosted. This goes beyond the schema's per-parameter descriptions, though it doesn't exhaustively elaborate every field.

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 and resource: 'Gate a model call BEFORE it runs.' This clearly states what the tool does and distinguishes it from siblings like spend_status (status reporting), export_receipts (exporting), and verify_receipt (verification). The return value (allow/block plus a signed receipt) further pins down its unique role.

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 explicitly states when to use this tool ('before a model call runs'), what to pass ('metadata only... never prompt content'), and names a prerequisite alternative: 'Unknown self-hosted models need set_model_cost first (fail-closed).' It also clarifies that read-only and cost-configuration tools accept the optional fields without recording a spend decision, giving agents a clear decision boundary.

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?

Since no annotations are provided, the description carries the full burden. It explicitly discloses the read-only nature ('Read-only...tools accept these fields without recording a spend decision') and that passing identifiers does not cause a spend record. It also clarifies that the parameters accept identifiers only, which is a key behavioral constraint. This is transparent for a status 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 three concise sentences. The first states the purpose with a clear list of returned components; the second constrains the parameter types; the third clarifies the read-only behavior and distinguishes from spend_decide. There is no filler or 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?

The tool has no output schema, and all parameters are optional, so the description must convey what it returns and how parameters behave. It does both: it lists the status elements returned and explains the effect of the optional parameters. For a read-only status query tool, this is fully complete; no pagination or permission details are necessary.

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 already describes each parameter as an identifier and states how it is signed on spend_decide. The description adds that these identifiers are accepted by read-only tools without recording a spend decision, and that spend_decide is the binding tool. This behavioral context is not present in the schema, providing real added value despite 100% schema coverage.

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 action ('Show') and a specific resource ('the active policy'), enumerating the exact components returned (caps, tenant, enforcement mode, decisions, signer identity). It also differentiates from spend_decide by noting that spend_decide binds identifiers into the signed actor, making the scope 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 provides clear context that the tool is read-only and accepts optional identifiers without recording a spend decision, and contrasts spend_decide as the tool that binds them. This implies when to use this tool (status viewing) versus spend_decide (decision recording). However, it does not explicitly exclude other sibling tools like provenance_preview or verify_receipt, so the guidance is 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?

There are no annotations, so the description carries the full burden. It discloses the boolean return, the effect of tampering, and the identifier-only semantics of optional fields. It does not note the public_key_hex default or possible error behavior, but the core behavioral contract is sufficiently 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?

Three sentences with no filler: the first states the function and return value, the second describes the tampering guarantee, and the third explains optional field semantics. The most important 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 no output schema, the description adequately states the return format and verification behavior. It covers the main success/failure condition (tampering) and clarifies optional parameter semantics. Minor gaps like the public key default exist, but they are captured in the schema rather than the description.

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%, with each parameter already well documented (e.g., 'signed as actor.taskId on spend_decide'). The description adds a useful clarification that these fields 'accept identifiers only' and are not recorded as a spend decision, but it does not meaningfully expand on receipt_json or public_key_hex.

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 and resource: 'Independently verify an AgentGuard signed receipt.' It also states the return type ('valid true/false') and the tampering condition, which clearly distinguishes it from the sibling tools (preview, status, export, set cost, spend decide).

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 explicitly say 'use when you need to validate a receipt,' but the context is clear: it verifies a receipt and contrasts with spend_decide behavior. It clarifies that optional identifiers are not bound to a spend decision here, helping an agent avoid misusing fields across sibling tools.

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