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

With no annotations at all, the description carries the full burden, and it does disclose a meaningful trait: 'zero-drift AST rational arithmetic' tells the agent results are exact rather than floating-point. It stops short of covering failure behavior for malformed expressions, operator support, or limits on expression size, which matters for an unannotated evaluation 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?

A single sentence that front-loads the action and ends with the distinguishing precision claim. Nothing is repeated from the title or name, and 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?

For a one-parameter tool with no output schema, the description is nearly sufficient: it explains both what goes in and what comes back (fraction and decimal). The only real gap is error/precision edge-case behavior, which is modest for a tool this simple.

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's own example ('(144 / 12) + 7') already illustrates the accepted syntax, so the baseline of 3 applies. The description adds the notion that the expression is parsed as an AST and evaluated rationally, but no further syntax rules beyond what the schema provides.

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 (compute) and resource (a numeric expression), and goes further by naming the output shape: exact rational fraction plus decimal. It doesn't distinguish itself from the sibling solve_equation, so an agent still has to guess whether an expression with a variable belongs here or there.

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 never says when to reach for this versus solve_equation or verify_step, and gives no preconditions on expression syntax. Usage must be inferred purely from the word 'numeric expression,' which is not enough given an overlapping sibling.

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; 'Check' implies a side-effect-free read, but the description never confirms that, nor does it describe latency, network dependencies, or failure modes. It does, usefully, enumerate the three status dimensions reported, which goes beyond the (empty) 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?

A single front-loaded sentence naming the action and the reported dimensions 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?

For a zero-parameter diagnostic tool with no output schema, naming the three reported dimensions is close to sufficient. It would be ideal to know the return shape or how tier values should be interpreted, but no critical caller information is missing.

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

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

The tool takes zero parameters, so the baseline is 4; there is nothing further the description could clarify about inputs.

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 ('Check') plus the exact resources reported: health, execution tier, and IP protection status of the zeroH MCP server and Sovereign Enclave bridge. It is clearly distinguishable from sibling compute/verify tools, though it doesn't 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?

Usage is only implied — an agent can infer this is the diagnostic/status probe to run before or after compute/verify work. There is no explicit 'use when' framing, no exclusions, and no mention of 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?

With no annotations present, the description carries the full disclosure burden. 'Automatic hallucination veto' hints at a rejection capability, but it does not say what triggers the veto, whether the call is pure evaluation or records state, whether results are deterministic, or how a vetoed proposal surfaces. The BFT claim implies multi-agent corroboration but the single-call semantics are left unexplained.

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?

Two compact sentences, front-loaded with the tool's identity and followed by what it evaluates. Efficient, though the density of unexplained acronyms makes the brevity partly a liability rather than pure economy.

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 decision-gate tool with no output schema and no annotations, the description should explain the shape of the verdict and what each lattice tier implies, since those entries drive interpretation of the result. Neither is provided, leaving an agent unable to reason about the return value or act on a rejection.

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 four parameters (agent_id, proposal, confidence, contradiction) are already documented with ranges. The description adds no meaning on top of that, which is the expected baseline when the schema does the work.

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 verb+resource are identifiable ('Evaluates agent proposals' via a consensus gate), but the core terms QATI, ZANNI_GHALIB, SHAKK and WAHM are opaque jargon with no gloss, so an agent cannot tell what the tiers mean or how the verdict is formed. It also fails to distinguish itself from the closely related siblings validate_claim and verify_step.

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?

There is no statement of when this gate should be used instead of validate_claim, verify_step or compute. No prerequisites, no exclusions, and no indication of what a caller should do with the result.

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 full behavioral burden. It does disclose one valuable operational fact — an authenticated Sovereign Enclave connection via ZEROH_API_URL is required — and "Query" weakly implies a read. But it says nothing about whether the token is consumed/intercepted (as the name suggests), whether lookups are logged, what happens when a token is not found, or what the call returns. For a tool whose name implies a potentially sensitive operation, this is a significant gap.

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?

Two compact sentences with the operation front-loaded and the prerequisite trailing. No filler, though the second sentence is a prerequisite buried at the end when it could be stated as a gate before invocation.

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 annotations and no output schema, the description is the only source of behavioral information, and it omits what a lookup returns, whether the operation is side-effecting, and error behavior for an unknown token. Given the name implies interception, the omission of any statement about side effects is a real gap for a one-parameter 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 100% with a single required `token` parameter, so the schema already defines it as a token or reference identifier. The description adds no format, encoding, or validity constraints (e.g., whether root references use a different syntax than tokens), so it neither compensates nor detracts. 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?

The description states a concrete verb and resource ("Query the Sovereign Enclave canonical ledger for a token or root reference"), but the tool name `intercept_token` implies interception of a token rather than a ledger lookup, which creates genuine ambiguity about what actually happens. The vendor-specific jargon ("Sovereign Enclave canonical ledger") doesn't help an agent map this to a familiar operation. It is not tautological, but the name/description mismatch keeps it below a 4.

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?

There is no indication of when to use this tool versus siblings such as `enclave_status`, `validate_claim`, or `zk_verify_receipt`, all of which touch the same enclave domain. No prerequisites beyond the connection URL, no exclusions, no stated outcome. The agent must infer everything about selection.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the key output condition (FULLY_PROVEN only if every active step is deterministically proven) and the SHA-256 Merkle head hash, but it does not state whether sealing is irreversible, what permissions are needed, or what happens if the session is not fully proven.

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, front-loaded with the core action and immediately followed by the critical output condition and hash. Every sentence adds relevant information without redundancy.

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

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

The tool has no annotations and no output schema, so the description must convey behavioral and return details. It covers the primary success condition and one returned artifact, but leaves gaps around other possible return states, error behavior, side effects of sealing, and authentication requirements.

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 input schema has 100% description coverage for the single 'session' parameter, so the schema already explains its meaning. The description does not add syntax, format, or validation details 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 gives a specific verb and resource: 'Seal and audit all steps submitted in a reasoning session.' It implies a distinction from step-level tools like verify_step by emphasizing all steps in a session, but it does not explicitly name or contrast with any sibling tool.

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 provides a clear context for use: finalizing/auditing a reasoning session after steps have been submitted, with the precondition that FULLY_PROVEN requires every active step to be proven. It does not explicitly state when not to use it or name alternative tools for related operations.

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. It does disclose a meaningful behavioral trait: solutions are checked by exact substitution, not numerically. However, it says nothing about behavior on unsolvable/ambiguous equations, error cases, or what the verification result looks 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?

A single front-loaded sentence with no filler; the core action and the verification guarantee both earn their 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?

With no output schema and no annotations, the description should say more about the return shape (solutions plus per-solution verification outcome) and failure modes. As-is it is adequate to call but leaves an agent guessing about the result structure.

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

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

Schema description coverage is 100%, with equation, unknown, and claimed all documented in the schema. The description's 'verify every solution' hints at the claimed parameter but adds no format, default, or constraint details beyond what the schema already provides.

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 ('Solve an algebraic equation') plus an added behavior ('verify every solution by exact substitution'). It is clear enough to distinguish from siblings like verify_step or compute, but it never explicitly names or contrasts with them.

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?

There is no explicit when-to-use or when-not-to-use guidance, and no mention of alternatives such as compute or verify_step. The dual solve+verify phrasing implies a use case, but the agent must infer 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?

With no annotations, the description carries the full burden and does disclose the return surface: Coherence Index, Confidence Score, and the four Deterministic Status values. It does not state that this is a non-destructive/read-only operation or name any cost, latency, or side effects, which is the remaining gap.

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?

Two tight sentences with the action front-loaded and the return values enumerated after. Every clause carries information, though the status enum list is dense and could be structured more readably.

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 tool with no output schema, the description supplies the missing return-value detail, which is exactly its job. An agent has enough to call it and interpret results, though the absence of any safety/behavior profile is a modest 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 100%, so both parameters are already documented, making 3 the baseline. The description adds no semantics for 'claim' or 'context' beyond what the schema states.

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: 'intercept and validate a factual, mathematical, or scientific claim' with the scoping condition 'before presenting it.' It is distinguishable from siblings like compute or solve_equation, though it never explicitly contrasts itself with verify_step or epistemic_consensus.

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 'before presenting it' implies the usage moment (pre-output gating), but there is no explicit when-not guidance and no routing to alternatives such as verify_step or epistemic_consensus, which appear to overlap in purpose.

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 the ledger is tamper-evident and SHA-256 based and that steps must be submitted before being stated, which is genuine context. It is silent on failure semantics (does a mismatched 'compute' value get rejected or merely recorded?), on whether sessions must pre-exist, and on the return value.

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?

Two short sentences: the action and its ordering constraint first, then a compact enumeration of the supported step kinds. Every clause carries information; nothing is padding.

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 nested-object tool with no annotations and no output schema, the description should close more gaps than it does. Step payload shapes are covered well, but failure behavior, session prerequisites, and whether verification actually gates the call remain 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 baseline is 3, but the description goes beyond the schema: the schema only says 'Step object containing kind and kind-specific parameters', while the description enumerates the four kinds and their exact payload shapes. That is material added meaning, though it is not structured as a real enum.

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: submit a single reasoning/math step to a tamper-evident SHA-256 session ledger. That is far more informative than the bare name 'verify_step'. It does not explicitly contrast itself with the compute or solve_equation siblings, even though its 'compute'/'solve' step kinds appear to overlap with them.

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?

'before stating it' gives a real timing rule: log the step before you assert it. Beyond that, there is no when-not guidance, no statement of how this differs from calling compute or solve_equation directly, and no note on what to do when a step fails verification.

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. It hints at an external dependency ('connected Sovereign Enclave'), which is useful, but does not say whether the receipt is persisted, whether the enclave path is fallback or opt-in, what happens when no enclave is connected, or what permissions or latency are involved.

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?

A single front-loaded sentence with the primary action first and the alternate mode in parentheses. No waste, though the jargon density ('R1CS', 'Sovereign Enclave') without explanation slightly reduces immediate comprehension.

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 and no annotations, so the description must explain what comes back (a receipt string? a proof blob? an ID) and how the enclave mode differs. Instead it leaves the return shape, failure modes, and mode-selection unaddressed for a tool whose output an agent likely needs to act on.

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 both parameters are already documented, including the default authority label. The description adds only the 'bind into a receipt' framing, which is marginal beyond 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 and artifact: generate a cryptographic commitment receipt bound to a claim, with a parenthetical alternate mode (R1CS proof via Sovereign Enclave). This distinguishes it reasonably from validate_claim and verify_step, though 'over a verified claim' is ambiguous about whether the claim must already be verified elsewhere.

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 guidance on when to call this versus validate_claim or verify_step, no prerequisites stated (must the claim be pre-validated?), and no explanation of how to choose between the default receipt path and the enclave R1CS proof path. The agent must infer everything.

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