GAIP Witness Agent

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

With readOnlyHint=false and destructiveHint=false already declaring a non-destructive mutation, the description adds real value: recording a GAIP receipt, the fact that it is free with no account, and the hard constraint that inputs must be public and non-personal. It does not address idempotency or replay-determinism, which the annotations leave as non-idempotent.

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 tight sentences, front-loaded with the trigger condition and followed by prereqs, mode choice, return values, and constraints. Every sentence carries information, though the return/constraint sentences could be marginally tighter.

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, yet the description covers the return shape (per-check PASS/FAIL/UNKNOWN plus a delivery receipt) and the auth/cost/data-handling profile. For a 7-parameter tool with two enums, the main remaining gap is guidance on which BUYER_SUBMITTED parameters to supply together.

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 already 100%, so the baseline is 3; the description still adds cross-tool provenance for terms_id (it must come from assurance_prepare) and clarifies the PUBLIC_REPLAY vs BUYER_SUBMITTED choice beyond the enum labels. It stops short of explaining the BUYER_SUBMITTED field bundle (body, http_status, content_type, body_sha256).

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 concrete action (finishing/completing a Buyer Assurance check) and names the specific output (PASS/FAIL/UNKNOWN per check plus a delivery receipt). It implicitly positions itself against assurance_prepare by consuming the terms_id that prepare produces, though it never names assurance_verify or other siblings directly.

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 finishing a Buyer Assurance check" gives clear context, and the prerequisite (terms_id from assurance_prepare) plus the two mode choices are explained inline. It lacks explicit when-not-to-use guidance against siblings like assurance_verify, 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?

Adds real context beyond the annotations: cost ('free, no account'), side effects ('records a GAIP receipt only', 'records your checks'), data constraints ('inputs must be public and non-personal'), and the consent requirement. The 'read-only check' phrasing sits against readOnlyHint=false, but it is consistent because the read-only scope refers to the check against the service while the tool itself records a receipt.

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 tight sentences: usage trigger first, then the required call shape, then cost/privacy caveats. No wasted clauses, though the consent parameter is repeated from the schema, which is slightly redundant.

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 7-parameter tool with no output schema, the description covers purpose, prerequisites, consent, side effects, and the handoff to assurance_complete. Return semantics are only sketched (terms_id), but no output schema exists so this is the appropriate place for that and it is partially covered.

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 required parameters, the checks vocabulary, and the consent const are already fully documented in structured fields. The description only restates the three required inputs and the public/non-personal constraint, adding no syntax or format detail 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 action (preflight/check a public service's delivery end to end) from the buyer's perspective, and names the output that routes to the sibling tool ('returns a terms_id for assurance_complete'). It is clear what the tool does, though it does not explicitly contrast itself with assurance_verify.

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 ('when you, the buyer, chose a public service and want its delivery checked end to end') and implies the follow-up step via terms_id. It never states when NOT to use it, e.g. when the service is private or personal-data-bearing beyond the closing constraint.

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), so the bar is lower. The description adds real value beyond them: what is returned ('the retained record and its integrity proof'), the explicit scope limit '(integrity only)', and the constraints 'free, read-only, no account' plus the public/non-personal input requirement.

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, zero filler, and the usage condition and return value are front-loaded. Every clause 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?

Although no output schema exists, the description characterizes the return (retained record plus integrity proof) and the integrity-only scope, and it discloses the privacy/account constraints. For a single-parameter read tool this is nearly complete; the only gap is no explicit tie-break against the similar verify_gaip_receipt sibling.

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?

Only one parameter, schema coverage is 100%, and the schema already states it is 'a receipt_id returned by an earlier GAIP call'. The description echoes the same origin but adds no format, provenance, or validity details beyond what the schema provides, so this is the baseline 3.

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 (confirm) and resource (Buyer Assurance terms or delivery receipt) and names the exact input it operates on. It is clear what the tool does, though it does not distinguish itself from the sibling verify_gaip_receipt, which appears to overlap.

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 this when you hold a Buyer Assurance terms or delivery receipt_id and want to confirm it.' It also states the preconditions (receipt_id from an earlier call, inputs public and non-personal) but names no alternative or when-not-to-use case, so it stops short of full routing guidance.

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 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?

Goes well beyond the read-only/non-destructive annotations: it discloses that each page is fetched exactly once, that robots.txt is respected, the exact result vocabulary including SOURCE_UNREACHABLE, and that a receipt and excerpt are returned. It also states cost/auth ('free, read-only, no account') and an input restriction (public, non-personal).

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 condition first, then the parameter shape, then behavior and return vocabulary. Every clause carries information (batching limit, fetch semantics, result codes, cost, input restriction) with no 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?

With no output schema, the description carries the return-value burden and does so by naming the status codes, excerpt, and receipt. Combined with fully described parameters and annotation-provided safety profile, an agent has everything needed to call this correctly on the first try.

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 url/quote/claimed_title/claimed_date and the data_classification enum are already documented structurally, which sets the baseline at 3. The description usefully restates the 1-20 bound and the public/non-personal restriction, but adds no per-field syntax or format detail 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+resource ('verify citations or quotes') with a quoted user phrasing that maps directly to the task, and the returned status vocabulary (QUOTE_FOUND etc.) makes the output contract unambiguous. Clearly distinct from siblings like gaip_watch_register or witness_dispute_bundle, which handle different lifecycle stages.

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 asked to verify citations or quotes ("do these sources really say this?")' gives a clear triggering condition, and the 1-20 citation constraint implies the batch scope. No explicit when-not or alternative-tool routing (e.g., vs. verify_gaip_receipt), 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 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 declare a non-read-only, non-idempotent, open-world write that is not destructive; the description usefully explains the side effect is limited to recording a GAIP receipt, and that there is no account or fee. It also discloses that delivery_check causes GAIP to fetch and test a public URL immediately and that its verdict overrides delivery.status, which is real behavioral context beyond 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?

Front-loads the use case, then inputs, then returns, then caveats in a compact block with no filler. Slightly telegraphic phrasing ('delivery_check {url, checks} has GAIP test delivery now') costs a little readability but every clause carries 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?

With no output schema and 16 parameters including nested objects, the description does the needed work by naming the return artifacts and the receipt-only side effect. Remaining gaps are minor: no explicit idempotency/duplicate-call behavior and no note on rate limits or size caps.

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% across 16 parameters, so the schema already documents nested shapes, enums, and defaults. The description names the four required inputs and explains delivery_check's timing/verdict behavior, but adds little that the schema does not already say, so the 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 concrete purpose: assess whether an outcome-priced task delivered and at what cost, and names the outputs (dossier, running totals, receipt). It also scopes out a related question ('No ROI claim'), which sharpens what the tool is not. No siblings exist, so no cross-tool differentiation is needed.

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?

Opens with an explicit trigger ('Use this when asked whether an outcome-priced task delivered and what it cost') and adds a hard precondition ('Inputs must be public and non-personal'). No alternatives are named, but none exist in this toolset, so the guidance is essentially complete.

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?

Without relying on annotations, it discloses that the tool is free, read-only, requires no account, and that inputs must be public and non-personal. It also notes it is a 'free preview', implying possible limitations. It does not describe output format details beyond listing entry fields, but that is substantial behavioral context.

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 front-loads the primary use case, then parameters, then returns, then constraints. Every sentence adds information, though the listing of return fields and the final constraints make it slightly dense.

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 lookup tool with full schema description coverage and no output schema, the description covers purpose, usage trigger, key parameters, return content, and access constraints. It is nearly complete, missing only explicit mention of the `limit` parameter and any pagination behavior.

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 naming the key parameters (`url`, optional `since`, `until`) and the context that the URL is an agent card, MCP endpoint, or shop product page. It omits `limit`, but the schema covers it fully.

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: extracting GAIP's record about a URL as proof of declaration on a date. It is clearly distinguished from siblings like gaip_evidence_pack or gaip_receipt_export by naming exactly what is returned (entries with chain positions, hashes, daily anchors, signature).

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 trigger: 'Use this when you need proof of what an agent or shop page declared on a date.' This frames the use case well, but it does not name alternative sibling tools or state when not to use it.

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 declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false, and the description usefully adds what the write actually is ('records a GAIP receipt only') plus cost/auth context ('Free, no account'). With no output schema, it also discloses the return shape (per-claim what GAIP saw, what you reported, whether they agree), which is the right burden to carry.

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 tight sentences with the core action front-loaded, then inputs, then return shape, then constraints. No filler or restated name/title content.

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 an 11-parameter, nested-object tool with no output schema, the description covers the meaning of the main flow, the optional live-test path, and the return semantics. Secondary params (episode_id, task_class, continuity_handle, synthetic) are left to the schema, which documents them adequately, so completeness is solid though not exhaustive.

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, but the description adds meaning beyond the schema: it explains the claim object's id requirement and the non-schema `check_url` field that triggers immediate GAIP testing, and clarifies that observations are your reported results versus GAIP's own findings. That earns above baseline.

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 what an agent, API or supplier claims') and spells out the core mechanic (pass claims, optionally add check_url for GAIP to test live, supply observations). There are no siblings to distinguish from, and the scope is unambiguous.

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 clear when-to-use context ('Use this to check what an agent, API or supplier claims') plus a hard precondition ('Inputs must be public and non-personal'), and notes it is free with no account required. It stops short of explicit when-not-to-use guidance, but with no sibling tools the practical gap is small.

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 carry readOnly/idempotent/non-destructive, but the description adds genuinely new context: it is free, needs no account, and requires inputs to be public and non-personal. It also discloses the shape of the result, which the annotations do not.

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 tight sentences with the trigger front-loaded and the return payload second. 'Read-only' is restated even though annotations cover it, a small redundancy, but nothing else is 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?

With no output schema, the description usefully summarizes return fields and auth requirements, and the nested continuity_handle is documented in the schema. It is close to complete; pagination/ordering of the returned events is left 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 description coverage is 100%, so the schema already documents limit, watch_id, and continuity_handle. The description only reinforces the continuity_handle's ownership role ('proves you own these watches'), adding marginal meaning over 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+resource ('Read watch change events') and enumerates what comes back (verdict before/after, change summary, receipt and webhook delivery status). It implicitly separates itself from gaip_watch_list and gaip_watch_register, but never names the alternative explicitly, so a sibling-aware agent still has to 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?

'Use this when asked what changed on a watched agent or service' gives a clear triggering context, and it tells the caller to pass continuity_handle and optionally watch_id. It stops short of naming when NOT to use it (e.g., listing watches vs. reading events).

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 adds genuinely new behavioral context: exactly which fields come back (kind, target, last verdict, last/next check, webhook endpoint), that the secret is never returned, and that the operation is free with no account — a solid supplement beyond 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?

Three compact sentences: trigger first, the single required input second, the return shape and safety limits last. No filler, no repetition of the name or title.

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 present, the description compensates by enumerating the returned fields and explicitly noting the secret is excluded. Combined with the annotations covering the safety profile and the fully-described single parameter, an agent has everything needed to call this 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?

Only one parameter exists and schema description coverage is 100%, with the schema itself explaining that the handle 'proves you own these watches.' The description only restates 'pass your continuity_handle,' adding no format or provenance detail beyond the schema, so the 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 and resource — listing the watches the caller owns — and names the trigger explicitly ('when asked which agents or services you are watching'). It implicitly separates itself from gaip_watch_events (events vs. watch list) and gaip_watch_register/remove, but it never names a sibling outright, so it stops short of a 5.

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 asked which agents or services you are watching' gives a clear, concrete activation context, and the read-only/free framing tells the agent this is safe to call unprompted. No explicit when-not or named alternative is given, so it is clear context without exclusions.

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 annotations only covering safety flags, the description adds substantial operational context: a 24-hour re-check cadence, a 3-free-watch quota, receipting of each change, optional webhook delivery, no account required, and the public/non-personal input constraint. These are exactly the traits an agent needs and none are duplicated from 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?

Front-loaded with the usage trigger, followed by compact operational facts in two dense sentences with no filler. A slightly tighter structure could separate the quota/cadence facts from the input constraints, but nothing is 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?

For an 8-parameter tool with a nested handle object and no output schema, the description covers cadence, quota, receipting, webhook, cost, and data constraints. It does not describe how watch results are retrieved (presumably via gaip_watch_events), a minor omission given no output schema exists.

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 every parameter including the kind enum, interval_hours bounds, and the nested continuity_handle. The description only names continuity_handle, kind and target_url, which restates the schema rather than adding format or precedence detail, matching the baseline 3.

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 clear verb and resource ('keep an eye on an agent or MCP server') and the title adds 'Watch ... for changes', so the agent can tell this registers a monitoring watch rather than reading or removing one. It does not explicitly name the sibling tools it differs from (gaip_watch_list, gaip_watch_events, gaip_watch_remove), so it stops short of a 5.

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 concrete invocation trigger with a user phrasing example ('tell me if it changes or goes down'), which tells the agent when this tool applies. There is no exclusion or explicit alternative-routing (e.g., use watch_events to read results), so it is clear context without alternatives.

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 declare destructiveHint=true, but the description goes well beyond them: it specifies exactly what is destroyed (stored events), what survives (retained receipts stay verifiable), the cost/auth model (free, no account), the side effect (records a GAIP receipt), and an input constraint (public, non-personal). This is unusually rich behavioral disclosure for a destructive operation.

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, front-loaded with the trigger condition, then the required inputs, then the destructive/retention semantics. No filler and no repetition of the 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?

For a destructive, two-parameter tool with nested inputs and no output schema, the description covers the trigger, the required arguments, destruction scope, retention behavior, cost/auth, and input constraints — everything an agent needs before invoking it.

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% and the schema already documents both watch_id (returned by gaip_watch_register) and continuity_handle (proves ownership). The description restates that both must be passed but adds no format or edge-case detail beyond the schema, so the baseline of 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?

The description states a specific verb and resource — stop/remove a watch on an agent or service — and pairs it against the register flow via the required watch_id, so an agent can tell it apart from gaip_watch_register or gaip_watch_list without opening a 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?

"Use this when asked to stop watching an agent or service" gives an explicit trigger condition. It does not name a when-not case or explicitly contrast with gaip_watch_list (view) versus this removal tool, so the guidance is clear but 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?

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.

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

Adds real context beyond the annotations: cost and auth ('Free, no account'), the side effect ('records a GAIP receipt only'), the return value ('an agreement_id naming both parties'), and a data constraint ('Inputs must be public and non-personal'). It does not clarify re-invocation behavior despite idempotentHint=false, which for a two-party acceptance flow would be useful.

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 trigger condition, then packs invocation, return, and constraints into three dense but purposeful clauses. The semicolon-heavy style is compact; nothing is obviously wasteful, though the density trades off some readability.

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 an 11-parameter, nested-object tool with no output schema, the description covers the purpose, trigger, core inputs, return value, and constraints adequately, and the schema carries the full parameter burden. It omits the optional higher-complexity paths (finding_mode, seller_key_proof, mandate_check_receipt, consumer_contract), which are left entirely to the 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 11 parameters in detail, including the nested acceptance_rule and seller_key_proof objects. The description reinforces a few key params (terms_id, continuity_handle, business_purpose_statement, agreement_id) and their cross-parameter relationship, but adds little that isn't already in the schema. 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 (accept), resource (registered terms), and the caller's role ('the other party'), which cleanly separates it from witness_register_terms. An agent can distinguish it from its siblings 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?

Opens with an explicit trigger ('Use this when you are the other party to terms a buyer registered') and explains the two-sided flow where the buyer later confirms with an agreement_id. It doesn't explicitly state when not to use it or name the alternative tool for the registering party, 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 read-only/idempotent/non-destructive, and the description adds real context beyond them: free, no account, inputs must be public and non-personal, and the shape of the result (PASS/FAIL/UNKNOWN per check, deltas since last time, a receipt). No output schema exists, so disclosing the return contents is genuinely valuable here.

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 mode guidance, then the result summary and constraints; every clause earns its place. The embedded quoted question and stacked parenthetical slightly crowd the prose but do not waste space.

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 12-parameter tool with a nested object and no output schema, the description covers the essentials: trigger, mode choice, terms_id provenance, return shape, and privacy constraints. The optional continuity/consent/classification parameters rely on the 100%-covered schema, which is acceptable.

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 beyond the schema by stating where terms_id comes from (witness_register_terms) and clarifying the two modes' semantics, though the optional fields (continuity_handle, research_consent, data_classification, episode_id) are left entirely to 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: check whether a service delivered what was agreed, with the trigger question quoted back. It also names the sibling witness_register_terms as the source of terms_id, so the agent can tell it apart from the registration tool without opening 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?

Gives a clear triggering condition ('when asked whether a service delivered what was agreed') and explains which mode to pick (PUBLIC_REPLAY vs BUYER_SUBMITTED) plus the public/non-personal input constraint. It does not explicitly rule out or route to other verification siblings such as gaip_verify_supplier_claims or verify_gaip_receipt, so it stops short of full when-not guidance.

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 read-only, idempotent, non-destructive. The description adds genuinely new context: it is free, needs no account, requires public and non-personal inputs, and makes 'no judgement of who is right' explicit. That is useful beyond the structured hints.

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 trigger, then the input choice, then what is returned, then constraints. Every sentence earns its place with no 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?

With no output schema, the description explicitly enumerates the returned bundle contents and states the access/cost constraints, so an agent has everything needed to call it and understand 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 coverage is 100%, so the baseline is 3, but the description adds the one-of selection rule ('Pass terms_id or a delivery receipt_id') that the schema (0 required params, no oneOf) does not encode, clarifying how to satisfy the input.

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 (export/hand over) and resource (a hash-stamped delivery evidence bundle containing terms, checks, receipts, timeline, summary), and its 'delivery failed / dispute' framing separates it from siblings like witness_delivery and gaip_receipt_export.

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?

Opens with an explicit trigger: 'Use this when a witnessed delivery failed and you must hand the facts to the other party or a resolver.' Clear context for invocation, though it does not name alternative siblings or state when NOT to use it.

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 declare destructiveHint=false and readOnlyHint=false, but the description adds behavior beyond that: 'Evidence only; no sum of money. Free, no account; records a GAIP receipt only.' This clarifies the call is non-financial and produces a receipt as a side effect, which is useful context the annotations don't convey. It doesn't address idempotency or what happens on repeated calls, so it doesn't reach 5.

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 five short, front-loaded sentences with no repetition or filler. Each sentence contributes a distinct detail: when to use, what to pass, the return values, the evidence-only scope, the cost/auth model, and the input constraint.

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-like, non-destructive tool with no output schema and full schema coverage, the description is complete: it covers the trigger condition, required inputs, return format, and any side effects (a receipt). There is no apparent missing information that would cause an agent to misuse 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?

Schema coverage is 100%, so the baseline is 3, and the description adds meaningful guidance by naming `agreement_id` (from witness_accept_terms) and `continuity_handle` as the parameters to pass. It also states the input constraint 'Inputs must be public and non-personal,' which reinforces the data_classification enum. This is more than what the schema alone provides, justifying a 4.

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 — it returns a signed GAIP finding (MET/NOT_MET/INDETERMINATE) on the agreed rule for an agreement. It clearly distinguishes itself from siblings like witness_accept_terms, witness_delivery, and witness_signoff by clarifying it produces an evidence-only verdict, not a delivery record or a signoff.

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 precondition: 'Use this when deliveries exist for an agreement.' That context tells the agent when the tool is applicable. It doesn't name alternative tools or state when NOT to use it (e.g., if no deliveries exist or if a dispute bundle is wanted), so it falls short of the 5 tier.

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 mark this as a non-read, non-idempotent write with no destruction; the description corroborates and enriches this by disclosing it records only a GAIP receipt, is free, requires public/non-personal inputs, and returns a terms_id (implying a fresh record per call). It doesn't spell out consequences of repeating the call, so it's strong but not exhaustive.

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 short, front-loaded sentences: trigger, required input, defaults, return value/next step, then constraints. Nothing is wasted and the call-relevant facts come first.

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 supplies the return value (terms_id), the workflow it belongs to, and input constraints. For a 5-param, 1-required tool this 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?

Schema coverage is 100% so the baseline is 3, but the description adds genuine value by explaining the default check behavior (HTTP 200 + non-empty body) and enumerating check categories (JSON keys, latency, size, regex) beyond the schema's field list.

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 ('register what a service should deliver') and frames it as creating neutral evidence of a public service's contract. It also names the downstream sibling (witness_delivery), so an agent can distinguish this registration step from the delivery-verification step without opening a 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?

Gives a clear trigger ('when about to depend on a public HTTPS service') and the follow-up action ('then call witness_delivery'), plus prerequisites (public, non-personal inputs; free, no account). It lacks an explicit when-not or named alternative, so it falls just short of 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?

Beyond the annotations (write, non-idempotent, non-destructive, closed-world), the description adds real behavioral context: the return is a chained, signed decision entry attributed to the role and not GAIP, the call is free with no account, and inputs must be public and non-personal. It does not state repeat-call behavior explicitly, but the chained-entry framing plus the non-idempotent hint communicate the key trait.

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 compact sentences, front-loaded with the use condition, then the key arguments, then the return and constraints. Every sentence carries information with no filler, though the parameter list slightly duplicates the 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?

For a 9-parameter write tool with no output schema, the description covers the essential operational facts: what it returns, that it is a receipt only, and the public/non-personal input constraint. The absence of explicit idempotency/retry guidance is a minor residual gap given the annotations already flag non-idempotency.

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 every parameter is already documented in the schema, including enum values and hash length constraints. The description names proposal_sha256, decision, and agreement_id but adds no syntax or semantics beyond what the schema provides, so it sits at the baseline.

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: recording a role's decision (sign-off) on an agent's proposal, with the exact vocabulary of roles and decisions. It is clear what the tool does, though it never explicitly contrasts itself with siblings like witness_finding or witness_accept_terms, leaving the agent to 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?

"Use this when a role ... decided on an agent's proposal" gives a clear trigger condition, and the named enums narrow when it applies. However, no alternative tool or exclusion is named, so the agent is not told which tool to use instead when the condition does not hold.

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