GAIP Trust & Assurance Agent

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

Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, and the description adds meaningful context on top: it is free, requires no account, and only accepts public/non-personal inputs. The draft-and-may-change disclaimer is a useful stability signal 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?

Front-loaded with the triggering condition and then compressed into the returned checks and constraints. Every clause carries information; the semicolon-joined constraints are dense but not padded.

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 compensates by naming the returned signals (missing fields, receipt_id match, signature validity). For a two-parameter, nested-object input with full schema coverage and rich annotations, this is sufficient, though the accepted receipt variants could be clarified.

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% and the schema descriptions already explain the public_key formats (raw base64url vs JWK) and the GAIP default key fallback, leaving little for the description to add. The description merely restates that public_key is optional and does not elaborate on the accepted receipt shapes.

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+resource ('Check an x402 SAR receipt') and enumerates exactly what is evaluated: missing fields, receipt_id/core match, and signature validity. It does not explicitly distinguish itself from the sibling verify_gaip_receipt, so an agent could wonder which verifier applies.

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 trigger condition ('when handed an x402 SAR-shaped receipt') plus the shape caveat ('draft proposal shape; may change') and the input constraints ('must be public and non-personal'). No named alternative or exclusion against verify_gaip_receipt, which keeps it 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 cover readOnly, idempotent, non-destructive and closed-world behavior, so the bar is lower; the description still adds meaningful context beyond them — that inputs must be public and non-personal, that no account is required, and that the output is 'a compilation, not certification or advice'. It does not mention pagination or the 200-item cap behavior, which are left to the schema.

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?

Four short sentences, each doing distinct work: trigger, key input, return shape, and caveats. The use case is front-loaded and 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?

No output schema exists, and the description compensates by enumerating the returned record families plus Merkle proofs and gaps. Combined with 100% schema coverage for the three nested parameters, an agent has everything needed to call this correctly without further documentation.

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 `subject`, `scope` and `requester` in detail; baseline 3 applies. The description echoes the subject form (public id or https URL) and adds the privacy constraint ('inputs must be public and non-personal'), but adds nothing about scope/categories/receipt_ids semantics beyond the 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 and resource ('Build an evidence pack') and enumerates the returned record types (conformance, watch, witness, repair, incident, gaps), which is far more than a restatement of the title. It distinguishes itself from narrower siblings like gaip_incident_bundle by framing the result as a broad compilation, though it does not name any sibling explicitly.

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 an explicit triggering situation: 'Use this when an insurer, auditor or buyer asks what evidence exists about an agent or supplier.' The `requester.purpose` enum (INSURER, AUDITOR, BUYER) reinforces that framing. It does not, however, say when to prefer a narrower sibling such as verify_gaip_receipt or inspect_counterparty_evidence instead.

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 and non-destructive, so the safety profile is covered; the description goes further by disclosing cost/account posture ('Free, read-only, no account'), an input legality constraint ('inputs must be public and non-personal'), and an explicit scope disclaimer about fault/cause/liability. It does not describe the timeline's structure or handling of unverified receipts.

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 dense sentences: trigger, inputs, output plus disclaimers. Front-loaded with the usage condition and nothing repeated unnecessarily.

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 usefully characterizes the return (verified source-attributed timeline plus an Art. 73 reference aid) and covers the key input restrictions. Remaining gaps are minor: it doesn't state behavior when only ai_system_ref is supplied (the schema does) or how verification failures surface in the result.

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 five parameters including the enum on source_type and the data_classification constraint. The description restates receipt_ids and observations and echoes the public/non-personal requirement without adding syntax, format, or edge-case meaning beyond the 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?

Specific verb and resource: it takes receipt_ids plus observations and returns a verified, source-attributed timeline. It also states a precise non-outcome ('No fault, cause or liability finding'), which tells an agent exactly what kind of artifact this produces versus the sibling receipt-verification 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?

'Use this when something went wrong with an agent and you need the facts in order' gives a clear triggering condition. It does not name alternatives (e.g. gaip_evidence_pack, gaip_receipt_export) or state when not to use it, so routing between the similar bundle/pack siblings is left 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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, yet the description adds substantive behavior: Ed25519 signing when a runtime key exists, embedded hash chain and Merkle proof, and no on-chain write. It also discloses a non-obvious input constraint (inputs must be public and non-personal), which is real value beyond the structured fields.

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?

Front-loaded with the use case, then formats, then signing/proof semantics, then constraints — a sensible priority order with no filler sentences. The final clause packs several facts into one semicolon-joined line, which is dense but not wasteful.

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 two-parameter, no-output-schema tool with full schema coverage, the description covers purpose, format semantics, cryptographic behavior, and input constraints. The only real gap is what the exported artifact actually looks like, which the absence of an output schema leaves unstated.

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, but the description enriches the enum with meaning the schema lacks: x402 is "attestation style," erc8004 is a "validation-response shape," and vc is "W3C-VC-like JSON-LD." This helps an agent choose a format rather than guess from bare tokens.

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 gives a specific verb (export/re-render) and resource (a GAIP receipt) and states the operative dimension: converting an existing receipt into a different serialization (x402, erc8004, vc). This clearly separates it from verify_gaip_receipt and gaip_check_sar_receipt, though it never names those siblings explicitly.

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?

"Use this when you need a GAIP receipt in another format" supplies a concrete trigger condition, and the format list makes the selection criteria clear. It stops short of naming alternatives or stating when NOT to use it (e.g., to verify rather than re-render a receipt), which keeps it below 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 cover safety (readOnly, idempotent, non-destructive), but the description adds real value beyond them: no authentication or account required, a data-classification restriction on inputs, and an explicit negative capability boundary ('Never a trust score or recommendation'), which prevents a plausible misuse. It does not discuss rate limits or failure modes.

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?

Four short sentences, each carrying distinct load: trigger, inputs, return contents, and boundaries. The usage trigger is front-loaded and nothing is repeated from the title or schema.

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 compensates by enumerating the return contents (evidence coverage, conflicts, gaps, GAIP's own earlier checks, a receipt). Combined with the input guidance for a nine-parameter, zero-required tool, an agent has enough to invoke it correctly, though the sibling-tool choice remains unaddressed.

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 nine parameters, including the observations item shape and max_age_days semantics. The description only calls out counterparty_id and observations, adding no format or syntax detail beyond what the schema provides; baseline 3 applies.

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 (inspect), resource (counterparty evidence) and the trigger scenario (before delegating to an agent). It is clear what the tool returns, but it never names or contrasts with its closest sibling, gaip_evidence_pack, so an agent must infer which of the two evidence tools fits.

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 an explicit usage trigger ('when asked what evidence exists about an agent before delegating to it') and constraints ('free, read-only, no account; inputs must be public and non-personal'). It lacks any when-not guidance or explicit routing against the sibling evidence/receipt 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?

Beyond the annotations, the description discloses the returned artifacts (retained record, hash chain, Merkle inclusion proof), the integrity-only limitation, cost and account requirements ('Free, read-only, no account'), and input privacy constraints ('inputs must be public and non-personal'). These are meaningful behavioral details that help an agent invoke it correctly.

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 tightly written sentences with no waste. It front-loads the usage condition, then the return behavior, then the key limitation and constraints.

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 verification tool with no output schema, the description supplies what is needed: when to use it, what it returns, and the crucial integrity-only caveat. It is complete enough for correct selection and invocation without an 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 100%, so the schema already documents all six parameters, including receipt_id and optional grouping fields. The description only echoes receipt_id and does not add syntax or format guidance beyond what the schema provides, making the baseline 3 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 states a specific verb and resource: verify a GAIP receipt using a held receipt_id. It also clarifies the exact question answered ('is this receipt genuine?') and what the tool returns, which distinguishes it from sibling tools like gaip_receipt_export or gaip_evidence_pack.

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 a clear usage condition: use when you hold a GAIP receipt_id and want to confirm it. It also bounds the tool with 'Integrity only: it does not make the underlying claim true,' but it does not explicitly name alternative tools or when-not-to-use scenarios.

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