Trust Gate

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

With no annotations the description carries the full burden, and it does disclose the key traits: read-only with no receipt minted, the name-first-word heuristic nature, and the hard inability to auto-discover inventory. It omits behavior on malformed or empty input (errors, ranking ties), which keeps it short of a 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?

Three sentences, front-loaded with the core action and free of filler. Slightly dense parentheses aside, but every clause adds a distinct fact.

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?

An output schema exists, so return values need no explanation, and the heuristic plus read-only constraint are covered. The unexplained 'notes' parameter and the undocumented structure of inventory entries, against 0% schema coverage, leave it only partially complete for a nontrivial ranking 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 description coverage is 0% and the description must compensate, but it only characterizes the inventory argument loosely ('list of MCP tools'). The shape of inventory items and the entire 'notes' parameter are left unexplained in both schema and description, leaving a real gap.

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 ('Rank a CALLER-PROVIDED list of MCP tools by worst-regret') and immediately qualifies the scope with the heuristic used. It clearly distinguishes itself from the mint_*/verify_* siblings by stating it mints no receipt, so an agent can route correctly without opening the 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?

It gives a real usage constraint ('Cannot auto-discover the inventory -- MCP does not allow that; the caller must pass it in') and implies its read-only role versus receipt-minting siblings. However, it never states when to reach for this tool versus check_egress or gate_decision, so selection guidance is only implied.

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

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

With no annotations, the description carries the full burden and does disclose key traits: RESTRICTED drives blocked=true, the tool is non-enforcing, and the result includes retention info and a tamper-evident receipt. It omits whether the sample itself is retained/logged (implied by 'retention info') and any auth or rate-limit requirements.

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 core action, followed by the exclusivity caveat and return summary. No filler or repetition of the tool name.

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?

An output schema exists, yet the description still summarizes the returns, which is mildly redundant but helpful. Combined with the classification semantics and enforcement boundary, an agent has enough to decide whether to call it; the main gap is undocumented parameter formats.

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 0% for all three required parameters, so the description must compensate and largely does not. It implies data_sample is what gets scanned but says nothing about the format or meaning of 'provider' and 'destination' (e.g., is provider an email/cloud vendor, is destination a URL?).

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 ('scans a data sample for sensitivity markers and classifies') and names the exact output taxonomy (NO_MARKERS_FOUND / INTERNAL / CONFIDENTIAL / RESTRICTED). This is distinct from siblings like gate_decision or verify_receipt, which handle enforcement and receipts respectively.

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 clearly bounds the tool's role with two strong exclusions: 'this tool cannot block anything itself' and 'NO_MARKERS_FOUND is not clearance to send.' However, it never names the alternative tool (e.g., gate_decision) that does perform blocking, so the agent must infer the routing itself.

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

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

With no annotations, the description carries the burden and does so well: read-only, writes/signs/executes nothing, fail-closed status semantics (OK/REFUSED/UNAVAILABLE, never made-up data), tenant comes from the setting never an argument, and a scope disclaimer that a readout is not a compliance finding. The only omission is what determines current vs unbound, which the agent must infer from the supplied inputs.

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 outcome and the read-only guarantee, then prerequisites, then failure semantics. Dense parentheticals make some sentences long, but each sentence carries distinct operational information rather than restating the name.

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?

An output schema exists, so it is not required to describe return values, yet it still explains the status triad and the fail-closed behavior. Environment prerequisites and version caveats are covered; the remaining hole is the undocumented request payload, which is the main thing an agent needs in order to actually call 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 0% and the single 'request' parameter is a free-form object with additionalProperties true and no field documentation. The description only says it comes 'from the proposal inputs and results you supply', leaving the actual payload shape entirely unstated, so it does not compensate for the coverage gap.

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 phrasing: it reports the status (current, not current, unbound) of each proposed retest after a change. An agent can tell this is a comparison/readout tool rather than a proposal or minting tool, though no sibling is named for contrast (e.g. propose_requalification).

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 establishes context (use it with the proposal inputs and results you supply, after a change) and prerequisites (three env settings, API version). But it never explicitly says when to call this instead of propose_requalification or the evidence tools, so routing between 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?

With no annotations supplied, the description carries the full burden and does well: it declares the operation read-only, states that it writes, signs and executes nothing, and enumerates outcomes (OK, REFUSED, UNAVAILABLE) including the rule that errors and missing settings become UNAVAILABLE rather than fabricated data. It also warns that a mapping or readout is not a compliance finding. It stops short of describing pagination, size limits, or what 'the records you supply' look like.

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 opening sentence front-loads purpose and scope, followed by safety, preconditions, and outcome semantics in a logical order. There is minor redundancy between 'Read-only view' and 'writes, signs and executes nothing', but almost every sentence adds a constraint 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?

An output schema exists, so the description need not document return values, yet it usefully summarizes the status vocabulary. The critical gap is the opaque nested request object: for a tool with a nested, undeclared payload and rich environmental prerequisites, the definition leaves the agent without enough to supply arguments correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the single parameter is a nested object with additionalProperties=true and no declared properties, so the schema tells the agent nothing. The description offers only indirect hints (cases, a control id, a version, and that tenant must not be passed as an argument) without describing the request object's shape or field names, leaving the caller unable to construct a valid call from the definition alone.

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 names a specific verb and resource ('Acceptance-pack export for one or more cases') and adds scope detail: optional mapping to a named control id and version. It is clearly distinguishable from siblings like gate_decision or inspect_oversight_case, though it never names a 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?

Usage context is implied by the preconditions (env vars must be set, API must be a version that serves this view, tenant comes from settings not arguments), which tells the agent when a call will fail. There is no explicit when-to-use-vs-alternative guidance or statement of what situations call for an acceptance pack versus another evidence tool.

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

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

With no annotations, the description carries the full burden and does so well: it discloses statelessness, that the verdict comes from a verb-tier heuristic on the action name and resource rather than a proof, exactly what each verdict returns, and that ESCALATE requires a human outside this tool. It also warns that the gate does not observe or block un-routed agent actions – a critical scope limit.

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 core concept ('Two-phase decision gate with a real verdict') followed by tightly packed sentences that each carry distinct, load-bearing information. No filler or restatement of the name.

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 stateless, high-complexity tool with an output schema, the description covers the phase model, verdict outcomes, scope limits, and attestation fields adequately; the output schema relieves it of describing return shape. The main gap is `context` semantics and the precise preview_id→COMMIT linkage, but overall it is close to complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% across 8 parameters, so the description must compensate. It explains phase (PREVIEW/COMMIT), preview_id's role in the two-phase flow, and that triggered_by_type/source/model are optional attestation, but it never explains the `context` object or what triggered_by_* actually attest, leaving several parameters undocumented in both places.

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+resource ('two-phase decision gate') and enumerates the exact verdicts (ALLOW/DENY/ESCALATE) and phase semantics (PREVIEW/COMMIT). It is distinguishable from siblings like mint_action_receipt and verify_receipt because it frames this tool as the decision gate that other tools' receipts record/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?

It gives clear context: PREVIEW acts without acting, COMMIT re-evaluates and mints a receipt, and it only applies to actions the caller explicitly routes through it. It does not, however, explicitly say when to choose this over mint_action_receipt or verify_receipt, so the alternative-routing guidance is implied rather than stated.

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

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

With no annotations, the description carries the full burden and does so thoroughly: it declares read-only semantics ('writes, signs and executes nothing'), names the required environment settings, states that the tenant comes from configuration and never from an argument, and enumerates the OK/REFUSED/UNAVAILABLE outcomes with the rule that errors and missing settings are UNAVAILABLE rather than fabricated data. It also warns that the backing API must serve this view and adds an interpretive caveat that a mapping or readout is not a compliance finding.

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 purpose is front-loaded and the following sentences each add a distinct constraint (read-only, configuration, status semantics, API version, interpretive caveat). It is dense and slightly run-on, but almost no sentence is 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?

Prerequisites, safety profile, and status semantics are complete, and the output schema means return values need not be re-explained. The significant remaining hole is the opaque request object, which an agent cannot populate from this description; for a tool whose only parameter is fully undescribed, that is a real gap.

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 0% and the single parameter is an open nested object with additionalProperties true, so the schema explains nothing. The description contributes only two hints — the facts are supplied by the caller and the tenant must not be passed as an argument — leaving the contents and required shape of the request object essentially undocumented.

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 resource and scope: an evidence view with verdict and open questions for one decision plus the supplied facts. The 'evidence view' framing loosely distinguishes it from siblings like get_receipt_evidence and get_intervention_evidence, but it never names those siblings or explicitly contrasts the resource they cover, so the differentiation is only partial.

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?

Usage is implied by 'for one decision and the facts you supply' and by the read-only framing, and the prerequisites are spelled out. However, there is no explicit when-to-use versus when-not guidance, and nothing tells the agent whether to reach for this instead of replay_decision or the other evidence tools when a decision is in question.

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

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

With no annotations provided, the description carries the full behavioral burden and does so well: it declares the tool read-only, says it writes, signs and executes nothing, lists required environment variables, explains that tenant identity comes from configuration, and documents OK, REFUSED and UNAVAILABLE outcomes including failure behavior. It also warns that the TrustGate API must support the view and that a mapping or readout is not a compliance finding.

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 front-loaded with the core purpose and then covers configuration and return statuses, but it repeats 'the records you supply' and packs several operational caveats into a dense block. It is useful but could be tightened and organized more clearly.

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 tool with an output schema, the description appropriately avoids explaining return structures and instead covers authentication prerequisites, version dependency and status semantics. The main gap is the opaque request argument, which an agent would need to understand before invoking the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema exposes only an opaque request object with 0% description coverage, and the description does not explain what that request should contain. It does add one important constraint, that the tenant is never taken from an argument, but the single parameter remains otherwise undocumented.

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 purpose: evidence about whether an intervention took effect, drawn from supplied records. It does not explicitly distinguish this from sibling evidence tools such as get_decision_evidence or get_receipt_evidence, so an agent must infer which evidence surface 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?

Usage context is implied by the required environment settings and the read-only framing, but there is no explicit when-to-use guidance versus the many sibling evidence and receipt tools. The note that the tenant comes from configuration rather than an argument is useful, but routing between alternatives remains unstated.

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

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

With no annotations, the description carries the full burden and largely meets it: it declares read-only semantics, discloses the env-var prerequisites, states the tenant is resolved from configuration and never from an argument, and enumerates the OK/REFUSED/UNAVAILABLE statuses including that failure degrades to UNAVAILABLE rather than invented data. It also warns that a version of the API not serving this view yields UNAVAILABLE. The main omission is auth/permission specifics and rate or latency behavior.

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 read-only and no-side-effects statement is front-loaded, followed by prerequisites and then return statuses, which is a sensible ordering. Some phrasing is choppy and slightly redundant ('it writes, signs and executes nothing' overlapping with 'Read-only view'), but nearly every sentence carries a real 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?

Because an output schema exists, the description is not obliged to explain return values, though doing so is helpful here. The unresolved gap is the free-form request object with zero schema documentation, and the absent sibling routing, which together leave meaningful ambiguity for an agent deciding how to call this versus the evidence and verification siblings.

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 0% and the single parameter is a free-form nested object with additionalProperties true, so the description must define its shape — and it does not. It adds one genuinely useful constraint (the tenant comes from a setting, never an argument) and says the receipt is 'supplied', but never indicates whether the request carries a receipt id, a full receipt body, or scoping fields.

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 opening sentence names a specific resource and view type: an evidence view of a single supplied receipt, showing what could and could not be checked. That is clearly distinct from a mutating tool, but the description never contrasts it with close siblings such as verify_receipt, get_decision_evidence or get_intervention_evidence, so an agent must infer the boundary from the name alone.

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?

Usage context is implied rather than stated: read-only, no writing/signing/executing, requires three TRUST_GATE_* settings, and returns UNAVAILABLE when a surface is off. There is no explicit 'use this when... instead use X when...' routing, and the framing 'a mapping or readout is not a compliance finding' hints at scope limits without telling the agent when to prefer a different tool.

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

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

With no annotations, the description carries the full behavioral burden and does so thoroughly: read-only, writes/signs/executes nothing, tenant sourced from configuration rather than an argument, and explicit OK/REFUSED/UNAVAILABLE outcome semantics with a no-fabricated-data guarantee. It also flags the version precondition that yields UNAVAILABLE and the caveat that a readout is not a compliance finding.

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?

Purpose is front-loaded in the first sentence and most sentences carry distinct information (safety, config prerequisites, status semantics, version gate). There is mild redundancy — 'the records you supply' is repeated and the read-only guarantee is stated twice in spirit — but no padding is serious.

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?

Failure modes and safety are well covered and the output schema means return values needn't be explained, but for a tool whose only input is a free-form nested object, the description leaves the request payload entirely unspecified. An agent can understand the tool's behavior yet still not know how to construct a valid call.

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 0% and the single 'request' parameter is an opaque nested object with additionalProperties: true, so the schema tells an agent nothing about what to pass. The description adds only a negative constraint (tenant is never an argument) and the vague phrase 'the records you supply' without naming fields or shape.

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 names a specific resource and output: a 'readiness report for one oversight case, computed from the records you supply.' That is clear enough to distinguish it from evidence-fetching siblings, but it never contrasts itself with them (get_decision_evidence, verify_receipt, gate_decision) and leaves 'readiness' somewhat abstract.

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 lists prerequisites (TRUST_GATE_API_URL/API_KEY/TENANT_ID, a compatible API version) but gives no when-to-use versus when-to-use-a-sibling guidance across a large family of TrustGate tools. An agent must infer on its own whether to inspect a case, verify a receipt, or replay a decision.

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

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

No annotations are provided, so the description carries the burden, and it does disclose meaningful traits: Ed25519 signing with ML-DSA-65 fallback, attestation values being caller claims (allowlisted, signed, not verified), and the reservation rule. It omits permissions/auth requirements and durability of the emitted 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?

Front-loaded with the core action and mechanism, then the optional attestation, then the exclusion rule. Dense but each sentence carries information; only the parenthetical backend caveat is slightly incidental.

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?

An output schema exists, so return values need no explanation, and the description covers mechanism, optional fields, and sibling routing. It would be complete if it addressed the overlap with mint_receipt_for_record_change and any auth prerequisites for minting.

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 0% across 9 params, so the description must compensate. It documents three parameters with example values (triggered_by_type human/agent/script, triggered_by_source api/cli/cron, decision_model) and implicitly constrains 'decision' via the gate-verdict rule, but agent_id, operation, target, inputs, policy, and the ACTION_GOVERNED default are left undefined.

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 ('mint a signed receipt ... for an arbitrary consequential agent action') with the crypto mechanism named, and explicitly carves out the sibling gate_decision for gate-verdict decisions. An agent can distinguish it from verify_receipt and gate_decision 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?

Explicitly routes gate-verdict-word decisions to gate_decision, which is genuine when-not guidance. However it never mentions mint_receipt_for_record_change, the nearest-scoped sibling, so the agent must infer the boundary between 'arbitrary action' and 'record change'.

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

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

With no annotations, the description carries the full burden, and it does add real behavioral context: signature algorithms (Ed25519, conditional ML-DSA-65), SHA-256 hashing of values, and CRM-agnostic support. It omits important traits for a mutation-style tool, such as whether receipts are persisted, idempotency, required permissions, or failure behavior when the post-quantum backend is unavailable.

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 core purpose. Some budget is spent on crypto-backend detail that matters less than the undocumented parameters, but there is 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?

An output schema exists so return values need no explanation, but for an 8-parameter, annotation-free tool the description leaves too much unsaid. No parameter guidance, no usage routing, and no operational constraints make it insufficient 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 description coverage is 0% across 8 parameters (6 required), so the description must compensate and does not. It never explains record_id, object_type, field, tenant, policy, or changed_by_agent, and its claim that old/new values are 'carried as SHA-256 hashes' ambiguously implies hashing behavior without clarifying whether callers pass raw or pre-hashed values.

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 (mint) and resource (signed receipt for one CRM record change) plus scope, so an agent knows what it produces. However, it does not distinguish itself from the sibling mint_action_receipt, leaving the agent to guess which receipt tool applies to which scenario.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance, no prerequisites, and no routing to or from alternatives like mint_action_receipt or verify_receipt, despite those siblings existing. The agent is left to infer the place of this tool in the broader workflow.

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

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

With no annotations supplied, the description carries the full burden and does substantial work: it declares read-only behavior ("writes, signs and executes nothing", "never runs a retest"), names the required environment settings, and specifies that the tenant comes from configuration and never from an argument. It also discloses failure semantics via the OK/REFUSED/UNAVAILABLE triad and the rule that missing settings, disabled surfaces, or errors resolve to UNAVAILABLE rather than fabricated data, plus a version dependency on the TrustGate API. It does not cover latency, rate limits, or what the returned impact view contains beyond status.

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 content is dense and mostly earns its place, but the first sentence is a noun-phrase fragment that delays the verb, and the negative assurances (no retest, writes nothing, never made-up data, not a compliance finding) are restated across several sentences. Front-loading the proposal action and then the guardrails would tighten it without losing 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?

An output schema exists, so return values need not be explained, and the description nevertheless adds useful status semantics and configuration prerequisites for a multi-step, graph-based analysis tool. The critical gap is the opaque free-form request object: for a tool whose entire input is a nested pass-through payload, the description leaves the agent without enough to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is a single required parameter, "request", typed only as an open object with additionalProperties true and 0% schema description coverage, so the schema tells the agent nothing. The description gestures at the payload contents ("the change", "the graph you supply", "the records you supply") but gives no field names, structure, or required sub-keys, leaving an agent unable to construct a valid call from the definition alone.

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 name-plus-description pairing makes it clear this produces an impact assessment and a requalification proposal for a change over a caller-supplied graph, and it explicitly separates itself from running a retest. The opening sentence is a fragment ("Impact and a requalification PROPOSAL...") and it never distinguishes itself from the sibling compare_qualification_change, so the purpose is clear but not sibling-differentiated.

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?

Usage is implied rather than stated: "for a change, over the graph you supply" suggests the input domain, and the caveat "a mapping or readout is not a compliance finding" implies boundaries. There is no explicit when-to-use versus compare_qualification_change, and no stated prerequisite workflow ordering, so an agent still has to infer the selection rule.

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

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

With no annotations, the description carries the full burden and does so well: it discloses read-only behavior, required environment variables, that tenant comes from settings not arguments, the OK/REFUSED/UNAVAILABLE status model, UNAVAILABLE for missing settings or disabled surfaces, a version dependency, and a caution that output is not a compliance finding. Only the request payload behavior and response shape details are left implicit.

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 core purpose is front-loaded, but the text is over-dense and repetitive, restating read-only behavior in multiple clauses ('it never asks anyone', 'read-only view', 'writes, signs and executes nothing'). It is informative yet would benefit from tighter grouping of prerequisites, statuses, and caveats.

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 tool with hidden environment prerequisites and a multi-state status model, the description covers the operational essentials and an output schema exists to explain returns. The main gap is the opaque request payload, which neither schema nor description clarifies.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single 'request' parameter is a free-form nested object with 0% schema description coverage, and the description only hints that it holds 'records and source lookups you supply' without documenting keys or structure. It adds a little meaning (tenant is never a parameter) but leaves the payload largely unexplained.

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 names a specific verb and resource ('Questions routed to a role for one oversight case') and clarifies the tool only proposes rather than soliciting responses. The scope (one oversight case, records you supply) distinguishes it from execution-oriented siblings like gate_decision or mint_action_receipt, though the phrasing is somewhat dense.

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 explains what the tool won't do ('never asks anyone', 'writes, signs and executes nothing') but gives no explicit when-to-use guidance or named alternatives among the many siblings. An agent must infer from the read-only framing that this is for draft question generation rather than live delivery.

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

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

With no annotations, the description carries the full burden and does substantial work: it declares read-only/no-side-effect behavior, names the three required environment settings, and states that the tenant comes from configuration rather than an argument. It also describes the OK/REFUSED/UNAVAILABLE outcome model and that failures surface as UNAVAILABLE rather than fabricated data, though it omits rate limits and what the supplied records are used for beyond replay.

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 scope constraint is front-loaded, which is good, but the no-side-effects point is restated three times ("executes nothing", "Read-only view... writes, signs and executes nothing"), padding a short description with 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?

An output schema exists, so the description needn't explain return values, yet it does enumerate the status codes as useful behavioral context. The significant gap is the undocumented request object, which is the one thing an agent must construct in order to call the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter is a free-form nested object with additionalProperties true and 0% schema description coverage, and the description never explains what fields the request object should carry. "The records you supply" hints at content but gives no structure, so the agent must guess the request shape.

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?

"Replay of a decision's evidence path over the records you supply" gives a specific verb (replay) and resource (a decision's evidence path), which separates it from the plain evidence getters in the sibling list. It stops short of explicitly contrasting itself with get_decision_evidence or gate_decision, so the agent must 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?

The description establishes a negative scope (nothing is written, signed, or executed) and a caveat that a readout is not a compliance finding, which helps the agent avoid treating output as authoritative. It never states a positive when-to-use condition or names an alternative tool for the adjacent tasks, so routing is only implied.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose a genuinely non-obvious side effect: despite being 'Informational', it signs one receipt, which creates a signing key on a host that has none yet. That is exactly the kind of mutation disclosure an agent needs before invoking. It stops short of describing auth requirements, 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?

Three short sentences, front-loaded with what the drill is, then what it checks, then the return shape and the caveat. Every sentence carries information and none is 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?

An output schema exists, so the description need not explain the step-by-step results or receipt structure, and it correctly does not. It covers purpose, checks performed, and the key side effect; only invocation prerequisites (permissions, environment assumptions) are left implicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters and the schema is empty at 100% coverage, so there is nothing for the description to disambiguate. The baseline for a parameterless tool is 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 names a specific verb+resource ('Vendor exit readiness drill') and enumerates exactly what it inspects: the local signing key and local model access via Ollama. It is clearly not a receipt-minting or egress-checking tool, so an agent can separate it from most siblings, though it never explicitly contrasts itself with check_egress or audit_my_agent_inventory.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The word 'Informational' implies this is a diagnostic to run when validating vendor-exit readiness, and the check list hints at the preconditions it evaluates. However, there is no explicit when-to-use, when-not-to-use, or named alternative among the six sibling tools, so usage must be inferred.

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

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

With no annotations available, the description carries the full burden and does so well: it explains what `ok=true` means, that unsigned receipts fail, that a passing verification does not prove signer identity, and that post-quantum keys are not covered by the `kid`. These are exactly the behavioral caveats an agent needs before relying on the result.

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 dense but front-loaded: verification scope arrives first, followed by the exact meaning of `ok`, then the signer-pinning caveat, then the post-quantum `kid` caveat. Every sentence adds decision-relevant information without filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a verification tool with no annotations and an output schema, this description supplies the key verification semantics, failure conditions, trust limitations, and parameter behavior needed to call and interpret it correctly. The presence of an output schema reduces the need to explain return fields in detail.

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 0%, so the description must compensate. It explains `require_pq` as defaulting on and requiring at least one post-quantum leg, and it explains that `expected_kid` pins the signer's Ed25519 key only when that key's own signature verifies. The `receipt` object itself is only characterized as a certificate, leaving its nested structure to the schema and output 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?

The description states a specific verb and resource: verify a TrustGate receipt from the certificate alone, offline. It makes the scope and meaning of `ok=true` clear, though it does not explicitly contrast this tool with sibling tools such as `get_receipt_evidence` or `mint_action_receipt`.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear usage context: perform verification offline from the certificate alone, and use `expected_kid` when the caller needs to pin the signer. It does not explicitly state when to choose this tool over sibling evidence-retrieval or receipt-minting tools, but the operational context is clear.

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