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

No annotations are provided, so the description carries the full burden. It discloses the return shape (gate values PROCEED / PROCEED_WITH_HUMAN_CHECK / BLOCK_AUTONOMOUS_ACTION plus exit_code) and the word 'static' hints at a non-mutating read, but it never states read-only behavior, permissions, or side effects explicitly.

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 sentences, zero filler, front-loaded with the purpose and followed by the return values and the parameter rule. Every clause 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?

There is no output schema and no annotations, so the description is right to spell out the returned gate values and exit_code, and it covers the one parameter's omission behavior. It is nearly complete for a simple read tool; only explicit read-only/side-effect disclosure 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?

With 0% schema description coverage and one parameter, the description must compensate, and it does: it explains that scenario_key selects a single scenario and that omitting it returns the whole ledger summary. That is meaningful semantics the bare string schema does not convey.

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 operation on a specific resource: the current trust state / gate decision of a scenario. The enumerated return values make the tool's output concrete. It does not explicitly contrast itself with siblings like verify_prediction or list_scenarios, so it stops short of 5.

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

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

The description gives one clear usage rule: omit scenario_key to get the whole ledger summary rather than a single scenario. That is useful context, but it never says when to choose this tool over verify_prediction or ledger_provenance, so guidance is implied rather than explicit.

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 usefully discloses the return shape (a fillable skeleton with x, y_pred, y_std) and the constraint to leave x unchanged, but says nothing about read-only behavior, error cases, auth, or rate limits.

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 no waste, and the core action and the downstream workflow step are front-loaded. 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?

No output schema exists, so the description must explain the return value; it does so reasonably by describing the skeleton's fields and the required edit pattern. It is nearly complete for a one-parameter fetch tool, missing only edge-case or failure behavior.

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

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

There is a single input parameter (scenario_key) with 0% schema description coverage. The description implies it selects 'a scenario' but adds no format, source, or validity details beyond that, so it only partially compensates for the schema 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?

States a specific verb (Fetch) and resource (a scenario's held-out INPUT points as a fillable skeleton), and identifies the follow-up tool verify_prediction so the agent understands its role in the workflow. It does not explicitly contrast with siblings like list_scenarios, but the resource is precise.

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 gives clear procedural guidance: fill y_pred (and optionally y_std), keep x unchanged, then call verify_prediction. This tells the agent when and how to use the tool relative to a named sibling. No explicit when-not 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 full behavioral burden. It usefully discloses that the tool returns a summary plus specific digest fields, but says nothing about read-only safety, auth requirements, or side effects. It adds real content beyond the empty schema, yet leaves the safety profile unstated.

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 sentences, no filler, with the payload list front-loaded before the purpose statement. The digest vocabulary is dense but each item earns its place by describing the return content.

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

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

For a zero-parameter probe with no output schema, the description adequately explains what comes back (summary + provenance digests) and why an agent would call it. It does not relate itself to sibling tools such as gate_decision or verify_prediction, which is the one remaining 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. Schema coverage is 100% on an empty object, so no compensation is required.

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 the specific resource (gate ledger) and enumerates the provenance payload it returns: engine git commit, engine all_digest/core_digest, and oracle_digest. That is far more concrete than a tautology, though it uses a noun phrase rather than an explicit retrieval verb and does not directly contrast itself with siblings like gate_decision.

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

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

It gives a clear when-to-use condition: 'Use it to check whether the gate you are consulting matches the code you think you trust,' which tells the agent the intent is provenance verification. No explicit alternatives or exclusions are named, so it stops short of a 5.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the returned content (verdict, gate) for these published scenarios, which helps, but says nothing about permissions, pagination, or result size for what could be a large list.

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 zero filler; the core purpose is front-loaded and the workflow hint follows immediately.

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?

There is no output schema, but the description names the key return fields (verdict, gate) and its role as the entry point for obtaining a scenario_key. For a no-parameter listing tool this is nearly complete, with only scale/pagination behavior unaddressed.

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

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

The tool takes zero parameters, so the schema is trivially complete and the baseline of 4 applies; there is no parameter syntax for the description to add.

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 ('List') and resource ('published held-out scenarios'), and further specifies the returned fields (verdict and gate). An agent can distinguish this from siblings like gate_decision or verify_prediction 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?

'Call this first to find a scenario_key' gives clear ordering guidance and reveals the workflow role of the tool. It does not explicitly name which alternative tool to use instead if a scenario_key is already known, so it stops short of full when/when-not coverage.

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 enumerates the verdict values, the exit_code meanings (0 PROCEED / 3 human check / 2 BLOCK), and a strong fail-closed contract (misaligned/wrong-length input refused, ERROR maps to BLOCK). It omits auth requirements and idempotency, but the safety-critical behavior is unusually well disclosed.

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?

Dense and front-loaded with 'THE GATE' before the mechanics, with every clause conveying a distinct fact (returns, exit codes, fail-closed policy). The terse fragments are economical, though the shorthand is jargon-heavy for a reader without domain context.

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 must explain results itself and does so (verdict, R^2, coverage, kappa, exit_code). The main remaining gap is that it doesn't explain how predictions are sourced or what scenario_key identifies, which matters for a 2-param submission tool.

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

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

Schema coverage is only 50% and scenario_key is documented nowhere. The description does compensate partially by tying 'only when y_std is supplied' to the optional y_std field and by flagging wrong-length submissions, which reinforces the array-ordering/aligned-length requirement on predictions, but scenario_key remains 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?

States a specific verb (score/verify) and resource (predictions against a published held-out set whose ground truth is server-held), making the operation concrete. It doesn't reference the sibling get_held_out_template that an agent would need to obtain predictions in the first place, so differentiation from siblings is implicit rather than explicit.

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 the tool is the scoring gate you run on submissions, and the exit_code semantics hint at the follow-on decision flow, but it never states when to use this versus alternatives or any prerequisite ordering (e.g., fetch the template first). Usage is inferred, not specified.

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 useful conceptual traits: literature ranges are never point estimates, parameters come from fitting a noise-free oracle, and outputs are graded AGREE/NEAR/CONTRADICTED/UNANCHORED. However, it does not state whether the tool is read-only, whether it has side effects, or what the response structure 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?

The description is three dense sentences that front-load the tool's identity and role in the evidence chain. There is little waste, though the first sentence is syntactically heavy and could be clearer as a standalone purpose statement.

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 no output schema and no annotations, the description should do more to explain what callers receive and how to interpret the grades. It covers the conceptual behavior and the comparison with the V&V chain, but it leaves the return structure and listing behavior largely to the schema.

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

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

Schema description coverage is 100%, so the single optional 'key' parameter is already fully documented in the input schema. The description adds no additional meaning about the parameter or its accepted values, 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 identifies the tool as the 'second evidence chain' dealing with literature ranges and implied parameters, which is a specific resource in this domain. It also distinguishes this chain from the V&V chain, but it never states a clear verb like 'retrieve' or 'list', leaving the exact operation slightly implicit.

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: read both the V&V chain and this chain, then gate on the more conservative one. That names an alternative evidence source and a decision rule, but it does not explicitly state when not to use this tool or how it relates to siblings like gate_decision.

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