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

Since no annotations are provided, the description carries full responsibility. It discloses a significant behavioral limitation (cannot auto-discover the inventory) and mentions the signed receipt as output. It avoids contradictions and adds concrete context beyond the basic action, though it does not discuss permissions or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, with the action front-loaded and every clause earning its place. It conveys purpose, output, and a critical limitation in a tight, efficient structure.

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

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

With an output schema present, the description need not detail return values. It covers purpose, input, output, and the main limitation for a tool with only one required parameter. The tool is simple enough that this description is sufficient for an agent to select and 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?

With 0% schema description coverage, the description compensates by explaining the core 'inventory' parameter as a 'CALLER-PROVIDED list of MCP tools'. The optional 'notes' parameter is not described, but its meaning is evident from the name. The description effectively clarifies the primary parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Rank') and a clear resource ('CALLER-PROVIDED list of MCP tools'), with the ranking criterion ('by worst-regret if they act') and output ('with a signed receipt'). This distinguishes it from sibling tools focused on receipts, verification, or gating by focusing on inventory audit.

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

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

The description explicitly states a key prerequisite: the caller must provide the inventory because auto-discovery is not possible in MCP. While it does not name alternatives, this constraint clearly communicates the expected usage context and necessary input, making it more than 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. It discloses that scanning is heuristic, defines the classification levels, explicitly states that RESTRICTED-class egress is blocked, and mentions the return of classification, retention info, and a receipt. This is substantial behavioral context, though it doesn't cover side effects or 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?

The description is two sentences with no fluff. It front-loads the core purpose ('Egress classification check') and then adds essential details about classification and blocking. Every sentence earns its place.

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

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

The description covers the main workflow and outputs, and an output schema exists. However, missing semantics for destination and provider, plus unclear details about how blocking is enforced, leave gaps. The description is adequate but not complete for a security-related tool with three required parameters.

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 only implicitly references the 'data_sample' parameter. The required 'destination' and 'provider' parameters are not explained. The description fails to compensate for the lack of schema descriptions, leaving two of three parameters ambiguous.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's specific verb and resource: 'Egress classification check.' It then details exactly what it does: scans a data sample, classifies into four sensitivity levels, and blocks RESTRICTED-class egress. This distinguishes it from sibling tools like verify_receipt and gate_decision, which focus on receipts or gates.

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 implied usage is when you need to classify a data sample before egress, but there is no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The description mentions blocking RESTRICTED-class egress, giving some context, but does not say when not to use the 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 provided, the description carries the full burden of behavioral disclosure. It discloses key behaviors: PREVIEW does not act, COMMIT requires matching inputs, mints a tamper-evident receipt, returns an execution permit, and the tool is stateless. It also mentions optional attestation fields. This is substantial, though it omits error handling (e.g., what happens if inputs don't match) and any permission requirements, so a perfect score is not warranted.

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 sentences with front-loaded key information ('Two-phase decision gate'). Each sentence adds unique value: the first defines the overall structure, the second details both phases, and the third covers statelessness and optional attestation. No redundant words or repetition of schema fields.

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

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

Given the tool's complexity (8 parameters, output schema present, related sibling tools), the description covers the essential workflow well: it explains the phase sequence, the importance of preview_id, and optional attestation. The presence of an output schema means return values don't need detailing. Minor gaps include the lack of prerequisites or edge cases, but overall it is sufficiently complete for an agent to understand the tool's context.

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 has 8 parameters with 0% description coverage, so the description must compensate. It does clarify the meaning of 'phase' (PREVIEW/COMMIT), 'preview_id' (needed for COMMIT), and identifies three optional attestation parameters. However, it does not explain the required parameters 'action', 'resource', and 'context', which are central to the tool's purpose. This partial compensation earns a mid-range score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool is a 'two-phase decision gate' and describes what happens in each phase: PREVIEW returns a risk assessment and preview_id without acting; COMMIT requires preview_id, verifies inputs, mints a receipt, and returns an execution permit. This distinguishes it from sibling tools like mint_receipt and verify_receipt, which focus on receipts rather than the full decision workflow.

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 through the phase description: an agent should use PREVIEW first to get a risk assessment, then COMMIT with the preview_id to finalize. However, there is no explicit statement about when to choose this tool over alternatives (e.g., check_egress or run_exit_drill), nor any exclusion criteria. The description lacks direct 'when to use / when not to use' 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?

With no annotations, the description must disclose behavioral traits. It does indicate that the tool creates a receipt and mentions an input constraint ('Allowlisted to safe chars'), but it does not describe permissions, side effects, or reversibility, leaving some behavioral transparency gaps.

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 concise and front-loaded: two sentences that state the core purpose, list the most relevant optional parameters, and note a safety constraint. 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?

Given the tool has 9 parameters and no schema descriptions, the description covers only a subset of optional parameters and provides no guidance on when to use it versus the sibling tool 'mint_receipt_for_record_change'. This leaves significant gaps in the agent's ability to invoke it correctly, despite having 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?

The description adds meaning for three optional parameters (triggered_by_type, triggered_by_source, decision_model) by explaining their allowed values. However, the required parameters (agent_id, operation, target) are not explicitly described, though their names are fairly self-explanatory. With 0% schema coverage, this partial compensation merits a baseline-plus score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'mint' with a clear resource 'post-quantum receipt' and a clear scope ('arbitrary consequential agent action'). It distinguishes itself from the sibling 'mint_receipt_for_record_change' by targeting arbitrary actions, not just record changes.

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

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

The description implies usage for any consequential agent action, as opposed to record-specific receipts, but does not explicitly name alternatives or state when not to use this tool. It gives clear context without explicit 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?

No annotations are provided, so the description bears the full burden. It discloses that values are hashed (SHA-256) and the receipt is post-quantum, but does not mention side effects, storage, permissions, or reversibility. For a minting operation, this lacks important 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 two concise sentences with no fluff. The first sentence states the core action and scope, while the second provides additional context about hashing and CRM compatibility. Every sentence earns its place.

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

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

This is a complex tool with 8 parameters, no annotations, and a terse description. While an output schema exists, the description does not explain return behavior, prerequisites, or the meaning of policy and tenant. Given the tool's sophistication, the description is insufficient for an agent to use it confidently.

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%, so the description must compensate. It explicitly explains old_value and new_value are SHA-256 hashes, adding meaning. However, other parameters like record_id, object_type, field, and changed_by_agent are left undefined, and the description does not clarify their formats or roles beyond the tool name.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool mints a post-quantum receipt for a CRM record change, using a specific verb and resource. It distinguishes from sibling tools like mint_action_receipt by focusing on record changes rather than general actions, and mentions SHA-256 hashes and CRM compatibility.

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

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

The description implies usage for CRM record changes and says it works with any CRM, but provides no explicit guidance on when to use this tool versus alternatives like mint_action_receipt or verify_receipt. No exclusions or when-not-to-use conditions are given.

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 explicitly states 'Informational -- no side effects,' which is a strong guarantee. It also discloses that it performs checks and returns a receipt, covering the key behavioral aspects for a zero-parameter tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences that front-load the main purpose and follow with the return value and side-effect profile. Every word adds value 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?

The description covers the purpose, the specific checks performed, the output format, and the side-effect guarantee. With an output schema defined and zero parameters, this is a complete description for the tool's complexity level.

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 has zero parameters, so per the rubric the baseline is 4. The description adds meaningful context by naming exactly what will be checked, which enhances understanding even though there are no input parameters to explain.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose as a 'Vendor exit readiness drill' and lists specific checks ('local signing key', 'local model access (Ollama)', 'local data export capability'). It also specifies the return value ('step-by-step results and a tamper-evident receipt'), making it distinct from sibling tools like verify_receipt or check_egress.

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 phrase 'Vendor exit readiness drill' provides a clear context for when to use this tool, implying it is for pre-exit assessment. However, it does not explicitly contrast with alternatives or mention when not to use it, which prevents a score 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?

With no annotations, the description carries full behavioral burden. It discloses the default for require_pq via OAO_REQUIRE_PQ, the failure condition when PQ legs are missing, and the security rationale (anti-downgrade). It does not explicitly mention non-mutation, but 'verify' implies it; the extra details are valuable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two dense sentences, front-loaded with the core purpose and then the key security parameter behavior. Every word adds value; no fluff or redundancy.

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

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

The description covers the most non-obvious behavior (PQ default and failure mode) and the output schema likely documents return values. It does not detail the receipt's internal structure, but the schema's additionalProperties hint and the 'certificate alone' phrasing give reasonable context for a crypto verification 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%, so the description must compensate. It adds significant meaning to require_pq (fail behavior, default source) but leaves the receipt parameter largely unexplained beyond the schema's 'object' type. Since the receipt is the primary input, more detail would be needed for full compensation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Verify'), the resource ('Trust Gate receipt'), and the method ('from the certificate alone (offline)'). This distinguishes it from sibling mint tools (e.g., mint_receipt_for_record_change, mint_action_receipt) and conveys the offline verification scope.

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

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

The description implies usage for offline verification from the certificate alone, and the downgrade attack defense suggests when to set require_pq. However, it does not explicitly contrast with alternative verification approaches or state when not to use this tool, so guidance is implicit rather than explicit.

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