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

Beyond annotations (which mark non-read-only, non-idempotent, open-world), the description adds evidence durability and automatic transport, provider-API runtime behavior, stub gating, and a capability-token requirement for existing sessions. This is meaningful context not inferable from annotations, though it leaves out cost and blocking 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?

Three sentences, each introducing a distinct facet: core action, evidence handling, and runtime/auth conditions. No filler; the most decision-relevant facts are front-loaded.

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 10-parameter tool with no output schema, the description gives the operational essentials (real vs stub, auth, evidence handling) but omits what the call returns, whether it blocks, and the semantics of required inputs like `task` and `draft`. The rich sibling set partially compensates, but an agent would still be guessing about the outcome and required content.

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

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

Only 30% of parameters carry schema descriptions, so the description must compensate. It does clarify `evidence` (durable, SHA-256-addressed, auto-transported) and `session_id` (verified capability token needed), but leaves required `task`, `draft`, and `caller` without additional explanation; the coverage gap is only partially filled.

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 opens with a specific verb-resource pair ('Run a real API review round against selected peers'), names the exact input vector ('evidence') and how it is transported, and distinguishes the real-provider path from stubbed mode. This clearly separates it from session-management siblings.

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 states when the real API path is used vs stubs ('stubs run only when CROSS_REVIEW_STUB=1') and explains the session auth condition, plus the implicit alternative to session_attach_evidence in the evidence parameter description ('attaches the same material out of band'). It does not explicitly name competing siblings like session_start_round or when to prefer them.

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?

The description richly discloses side effects and invariants beyond the write-only annotation: it stamps a contestation record on the original session, initializes a new session with a back-link, preserves chain of custody, and throws specific errors for in-flight sessions. It also notes the authentication requirement (capability token). This fully covers the behavioral profile even though annotations are minimal.

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 and verbose, but it is front-loaded with the core purpose and then provides necessary details. The sentence structure is logical (purpose, constraints, preconditions, side effects, invariants). While it could be trimmed, the complexity of the operation justifies most of the length. Every sentence contributes to understanding the tool.

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 complex tool with no output schema, the description covers preconditions, postconditions, side effects, error conditions, and invariants. It does not describe the return value or what the new session's response looks like, which could be important, but the absence of an output schema makes it acceptable. Overall, it is reasonably complete for an agent to invoke 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%, so the description must explain all parameters. It only mentions `caller` and `reason` (with the 4000-character limit), but leaves `session_id`, `new_task`, `new_caller`, `response_format`, and `new_initial_draft` undocumented. For a 7-parameter tool, this is a significant gap. The description adds some value for two parameters but doesn't compensate for the rest.

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: to contest a final verdict and open a new deliberation cycle. It uses specific verbs and resource nouns ('contest', 'final verdict', 'new deliberation cycle'), and the context clearly differentiates it from sibling tools like session_init or session_finalize. The chain-of-custody detail further clarifies its unique role.

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 explicit conditional guidance: use it when petitioner is NOT_READY, not when READY, and only against a final-state session. It also warns about contesting the latest session and that a session cannot be contested twice. While it doesn't name specific alternative tools, these conditions are sufficient to guide selection. The precondition about the capability token is also clearly 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering safety. The description adds useful behavioral context beyond annotations: it performs outbound calls to provider APIs, relies on current API keys, applies a selection heuristic, and checks reachability.

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 a single dense sentence with no filler and a front-loaded verb, making it easy to scan. Every phrase contributes meaning.

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 two simple enum parameters, the description adequately conveys the tool's function and side-effect profile. However, there is no output schema and the description does not explicitly state what the tool returns, which is a notable gap given that return values must be inferred from the described actions.

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 for parameter meaning, but it does not mention either parameter by name. The enum values are self-explanatory, and the phrase 'provider APIs' hints at the caller parameter, but response_format is never addressed.

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 specific verbs and a clear resource: it queries official provider APIs, discovers available models for the current API keys, selects the highest-capability documented model, and verifies provider reachability. This clearly distinguishes it from sibling session/peer tools, even without naming 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?

The description implies the use case: when an agent needs to know what models are available/authorized under current API keys and whether providers are reachable. However, it provides no explicit comparison to alternatives like ask_peers and no exclusion criteria.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds 'stable' which aligns with idempotency, and mentions 'active tool list' giving some context on output. However, it does not elaborate on what the contract contains or any operational nuances, so it only partially supplements the annotations.

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

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

The description is a single, concise sentence that front-loads the verb and object. There is no filler or redundancy; every word 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?

With only two simple parameters and no output schema, the description provides a basic idea of what is returned (contract and tool list) but lacks detail on the structure or content of the contract. Given that the tool likely serves as a discovery mechanism, more detail on output format would be helpful. However, the annotations cover safety and the tool is low-complexity, so the description is minimally adequate but not 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 description coverage is 0%, so the description must compensate for undocumented parameters. It does not mention 'caller' or 'response_format' at all. The parameter names and enums are somewhat self-explanatory (caller identifies the runtime, response_format chooses format), but the description offers no additional meaning, leaving the agent to rely solely on naming conventions. This is a notable 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 clearly states the tool returns a 'stable cross-review runtime capability contract and active tool list'. The verb 'return' with the specific resource distinguishes it from session_* and other sibling tools that focus on session operations or server info. This is a specific and unambiguous purpose.

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 guidance on when to use this tool versus alternatives like server_info or probe_peers. The description simply states what it does without explaining context, prerequisites, or exclusions. An agent would have to infer usage from the name alone, which is insufficient given many sibling tools.

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

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

Annotations only flag readOnly=false, idempotent=false, and openWorld=true. The description adds valuable behavioral context: evidence is 'persisted durably and transported automatically,' review rounds hit 'real API' peers, and an explicit lead_peer === caller is rejected server-side via 'caller_cannot_be_lead_peer' as a 'workspace HARD GATE.' This goes beyond the annotations, though it does not cover side effects like session creation or response 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 description is dense but not bloated. The core purpose is front-loaded in the first sentence, followed by evidence-transport behavior and the relator-lottery rules. The 'judicial panels' metaphor is mild color but supports understanding. The version marker and hard-gate detail are useful, though the description is longer than strictly necessary for the tool's most common 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?

This is a complex, open-world, mutating tool with 14 parameters and no output schema. The description explains the main loop, evidence flow, and relator constraint, but it does not describe return values, output format, session-related side effects, cost behavior, or how to set up peers and initial drafts. An agent could call it correctly with task and caller, but many behavioral expectations remain underspecified.

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 only 36%, so the description must compensate. It does add meaningful semantics for key parameters: evidence (durable, SHA-256-addressed, no attachment needed), caller and lead_peer (relator lottery, non-caller constraint, server rejection), and max_rounds (termination ceiling). However, most other parameters — mode, peers, initial_draft, response_format, until_stopped, and reasoning_effort_overrides — are left to the schema or omitted entirely, leaving a partial compensation 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 opens with a specific verb and resource: 'Generate or revise a draft and continue real API peer-review rounds until unanimous READY or the configured max_rounds is reached.' This clearly states the tool's core behavior and terminal condition, making it distinguishable from sibling session-control tools like session_start_round or session_poll.

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 clear operational guidance: evidence is automatically persisted and transported, so 'no separate attachment step is required' — a direct hint about when not to use the sibling session_attach_evidence. It also explains how to use the relator lottery via caller and lead_peer, including the rejection rule. It stops short of explicitly naming when to prefer run_until_unanimous over session_start_unanimous or ask_peers, so no exclusions 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful context about the server being API-only and the specific runtime fields returned, but it does not disclose additional behavioral traits such as response behavior or potential errors. It is consistent with the annotations, so no contradiction exists.

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 a single, compact sentence that front-loads the core action and then lists the specific data returned. There is no filler or redundant phrasing, and every part of the sentence adds meaningful 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?

For a simple read-only informational tool with strong annotations and a self-explanatory schema, the description covers the essential purpose and output contents. It is slightly incomplete in that it does not clarify how response_format changes the response, but no output schema exists and the description names the key fields, which is sufficient for basic 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?

The description provides no information about the 'caller' or 'response_format' parameters, and schema description coverage is 0%. The input schema's enums and default value are self-documenting, which mitigates the gap, but the description itself makes no attempt to compensate for the low coverage.

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 ('Return runtime information') and resource ('API-only Cross Review MCP server'), and enumerates the returned items: version, data directory, and active security mode. It is clear on its own, but it does not explicitly distinguish itself from sibling tools like runtime_capabilities, which could plausibly overlap.

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

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

There is no guidance on when to use this tool versus alternatives such as runtime_capabilities or session_*. The description implies a general informational purpose but does not state use cases, exclusions, or conditions under which a sibling tool would be more appropriate.

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

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

Annotations only indicate a non-read-only mutation, so the description carries the burden of behavior. It adds valuable context: the artifact is durable, carries `caller_submitted_unverified` provenance, promotes nothing, and requires the petitioner's verified capability token. No contradiction with annotations, though it stops short of describing removal or overwrite 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?

Three sentences deliver the core action, scope, provenance, and usage guidance without obvious padding. It is dense but well front-loaded, though the long middle sentence about provenance could be slightly streamlined.

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 7 parameters and no output schema, this description covers the why, when, and who well, but leaves parameter semantics and return behavior unaddressed. An agent can understand the tool's role, but may still struggle to craft a fully correct call without additional schema descriptions.

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%, yet the description never explains session_id, label, content, extension, content_type, or response_format. It only gestures at 'artifact' and provenance, leaving the agent to infer parameter meaning from names alone. The enums and defaults in the schema help, but the description 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?

States a specific verb and resource: attach one durable evidence artifact to an existing session, out of band from a review round. It explicitly contrasts itself with the routine `evidence` field and clarifies that this tool 'promotes nothing', distinguishing it from review-round evidence tooling.

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 instructs when to use it: for material that does not belong to a specific round, and to prefer the `evidence` field for the routine path. It also states the auth constraint that only the session's own petitioner may call it, so an agent knows when not to attempt it.

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

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

Annotations already indicate non-read-only, non-destructive, and idempotent behavior. The description adds meaningful behavioral detail: cancellation is a request, the reason is capped at 300 characters, only the original petitioner can cancel, and providers receive an AbortSignal when supported. No contradiction with the annotations.

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

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

Three concise sentences with no filler: the first states the purpose, the second covers constraints and authorization, and the third describes provider-side behavior. The structure is front-loaded and each 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?

With no output schema and zero parameter descriptions, the tool lacks critical context such as what a successful cancellation returns, how the optional job_id affects scope, and what errors may occur. The auth and AbortSignal details are useful, but an agent still cannot fully predict the outcome of an 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%, so the description must carry the parameter-documentation burden, but it only restates the reason max length that is already in the schema. It does not explain session_id, job_id, caller, or response_format, and leaves the optional job_id behavior ambiguous. This provides almost no added meaning beyond the raw 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 uses a specific verb ('cancel') and a specific resource ('running background jobs in a durable session'), making the tool's purpose immediately clear and distinguishable from siblings like session_poll or session_sweep. The phrase 'Request cancellation' is slightly indirect, but the intent is unambiguous.

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

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

The description gives clear usage context: it targets running background jobs in a durable session and explicitly states that another peer cannot cancel the job, which acts as a when-not for non-petitioners. It does not name an alternative tool, but the condition is strong enough for the common case.

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

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

Annotations already indicate readOnlyHint=true and idempotentHint=true, and the description adds behavioral context about not calling providers, which aligns with and supplements the annotations without contradiction.

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 a single, concise sentence that front-loads the key information (return value and behavior) with no unnecessary words.

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?

Despite having only two parameters and no output schema, the description lacks parameter details, expected return format, and error states, and does not address how this tool fits among many sibling session tools.

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 tool description provides no information about the parameters (session_id pattern or response_format enum), leaving the agent with only the schema names and types.

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 returns 'the latest durable convergence state, health and scope for a saved session' and specifies it does so 'without calling providers,' distinguishing it from sibling tools like session_read that likely involve provider calls.

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 a lightweight check ('without calling providers') but does not explicitly state when to use this tool versus alternatives like session_read or probe_peers, nor does it provide exclusions or prerequisites.

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?

It discloses default read-only behavior, the opt-in write path, a token requirement for repair, scope to the caller's own sessions, and a precise constraint on what repair changes. This adds substantial context beyond the annotations, which only signal idempotent/non-destructive and not-readonly.

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 text is a single dense paragraph and somewhat long, but every clause adds operational detail and the main purpose is front-loaded. It could benefit from bullets, but nothing is 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 complex tool with no output schema, it covers the key behaviors, scope, security, version caveats, and flag-driven variants, and even names response elements like totals.self_lead_metadata and the repaired array. It does not sketch the full response shape, but the essentials for correct invocation are present.

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 carries the burden and does explain the meaningful flags: include_terminal_findings, include_legacy, and repair. It does not explain limit, caller, or response_format, though their schema types/enum values are largely self-explanatory.

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 opens with a specific verb ('audit') and a precise resource ('durable sessions'), then enumerates the distinct categories it covers (open/stale/blocked cases, legacy metadata, evidence asks, Grok errors, token-event noise). This semantically separates it from sibling list/read/metrics tools even without naming 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?

It gives clear context for when to invoke the tool and how to adjust scope via include_terminal_findings, include_legacy, and repair. It does not explicitly name sibling alternatives or state when not to use this tool, so it stops short of full exclusion guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds valuable context: that events are 'durable' (persisted), pagination is via 'next_seq' and 'has_more', and token-delta telemetry is excluded by default. This goes beyond annotations without contradicting them, providing practical behavioral expectations for the agent.

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 comprised of three concise sentences, each adding distinct value: the first defines the operation, the second clarifies a special parameter, and the third provides pagination guidance. It is front-loaded with the core purpose and has zero fluff. This is exemplary conciseness with high information density.

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 moderate complexity (5 parameters, pagination) and no output schema, the description covers the essential points: what events are read, the main optional parameter, and how to paginate. It does not explain the output format or the meaning of response_format, but the schema's enum and default handle that. The description is almost complete for effective usage, with only minor gaps in return value documentation.

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

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

Schema coverage is 0%, so the description must compensate for the undocumented parameters. The description mentions 'bounded page' (implying limit), 'next_seq' (since_seq parameter), and 'token-delta telemetry' (include_token_deltas). It also states the default exclusion of token deltas, which aligns with the default false. However, it does not describe response_format or the meaning of since_seq beyond pagination, but given the schema has defaults and clear types, this is a solid 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 'Read a bounded page of durable session events' which specifies the verb (Read), resource (session events), and key characteristic (bounded, durable). It distinguishes itself from siblings like session_list (list sessions) and session_metrics (aggregate metrics) by focusing on raw event logs. The mention of token-delta telemetry exclusion further clarifies its 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 provides strong context: 'Continue with next_seq while has_more is true' gives explicit pagination guidance, and 'Token-delta telemetry is excluded by default; opt in only for streaming forensics' tells when to use the include_token_deltas parameter. However, it does not explicitly mention alternative tools for other event-related operations (e.g., session_metrics for aggregated data), which would strengthen the usage 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?

Despite annotations already setting readOnlyHint=false, the description adds substantial non-obvious behavior: self-judge causes fail-closed consensus, promotion requires unanimous verified-satisfied judgments with non-empty rationales and zero parser warnings, shadow mode never mutates state (implying active mode does), and the pass spends the petitioner's budget on paid provider calls. No contradiction with the annotations; this is exactly the kind of context annotations can't express.

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

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

Four dense sentences, front-loaded with the core purpose and requirements; every sentence earns its place. The opening 'Multi-peer evidence judgment' is a fragment rather than a true verb-phrase, and 'multi-peer' slightly overlaps with 'at least two distinct enabled judge peers,' but overall it is tight and well-ordered.

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

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

For a 9-parameter, mutating, budget-spending tool with no output schema, the description covers the critical constraints well (peer minimums, fail-closed self-judge rule, promotion criteria, mode semantics, billing). Gaps remain: what 'draft' and 'item_ids' refer to, what review_focus does, how the output is returned, and how the verified capability token is supplied given it is not a parameter.

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 schema description coverage at 0%, the description carries the full burden—yet it only partially clarifies judge_peers (requires at least two distinct) and shadow_mode (non-mutating). The remaining seven parameters—draft, round, caller, item_ids, session_id, review_focus, response_format—receive no semantic guidance, and the 'verified capability token' mentioned has no corresponding parameter at all.

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 phrase 'Multi-peer evidence judgment' plus the title 'Run Evidence Judge Consensus Pass' conveys a specific action—running a consensus pass over evidence across multiple judge peers—and the active-mode sentence clarifies that unanimous satisfied judgments get promoted. However, it never names or contrasts its nearest sibling 'session_evidence_judge_pass', so an agent must infer the differentiation rather than having it stated.

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 operational context: it requires at least two distinct enabled judge peers, a verified capability token of the session petitioner, and it explains when to use active vs shadow mode. It stops short of naming alternatives like run_until_unanimous or session_evidence_judge_pass, so there are no explicit exclusions—just clear context.

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

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

Annotations provide only hints, so the description carries the full burden. It discloses that the tool mutates state (promotes items), explains the promotion rule (satisfied=true AND confidence='verified'), states that terminal/already-addressed items are untouched, notes the self-judging prohibition, mentions shadow_mode for non-mutating runs, and requires a verified capability token because it spends the petitioner's budget. This is comprehensive and adds significant value beyond the annotations.

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

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

The description is dense but efficient, with no filler. It front-loads the purpose and then covers key behaviors and constraints. The length is justified by the complexity of the operation, though a slightly tighter organization could improve readability.

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

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

For a complex tool with 9 parameters, no output schema, and mutating behavior, the description covers the most critical aspects: promotion logic, auth requirements, and non-mutating mode. However, it lacks details on the return format (only 'structured judgment') and does not explain several parameters or the relationship to the consensus variant, leaving some gaps for the agent.

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 explicitly references 'draft', 'judge_peer', and 'shadow_mode', but it does not explain other parameters like item_ids, round, review_focus, response_format, or caller. Many parameters remain undocumented in both schema and description, leaving the agent to infer their meaning.

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 action: running a judge pass for evidence checklist items against a draft. It explains the promotion criteria and scope. However, it does not explicitly contrast with the sibling tool session_evidence_judge_consensus_pass, so it lacks direct sibling differentiation.

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 when to use it (for judging evidence items against a draft) and mentions shadow_mode for non-mutating runs, but it does not explicitly state when to prefer this over the consensus pass variant or other session tools. No exclusions 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?

The description goes beyond annotations by disclosing the identity forgery check, requiring the caller to match the peer host's token/clientInfo, and stating that the 'converged' outcome is only sealed by the runtime. It also notes the max characters for reason and that 'max-rounds' is only written by runtime/sweep. These are significant behavioral traits not present in the annotations (which only provide idempotentHint/destructiveHint). There is no contradiction with annotations.

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

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

The description is dense but appropriately sized for the complexity, covering the core purpose first, then auth requirements, then runtime constraints. The sentences are structured logically, front-loading the primary action. It could be slightly more concise by cutting the last clause about 'max-rounds-sweep', which is tangential, but it's acceptable.

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 (auth checks, runtime-only outcomes, limited outcomes), the description covers the essential use case and constraints. It lacks explicit mention of return values (no output schema, so description could mention what is returned, e.g., confirmation or error details), and it doesn't explain what happens if the session is already terminal. However, most critical decision-making info is present.

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 explain parameters, and it does partially. It explains 'reason' (optional, max 200 chars) and 'caller' (must be host's own identity, forgery check), but does not explain 'session_id' format (though schema has pattern) or 'response_format' (schema has default). It doesn't add much beyond the schema for session_id, but for caller it adds crucial semantics. With 0% coverage, description should carry more, but it covers the most important behavioral 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 clearly states that the tool closes a non-terminal durable session as 'aborted' with an optional reason, which is a specific action on a specific resource. It does not explicitly differentiate from siblings, but the outcome enum (only 'aborted') and the mention of 'non-terminal' make its purpose distinct, though not explicitly naming alternatives.

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 some context on when to use it: it's for aborted sessions, and it explains that 'converged' is only sealed by the runtime, not by this tool. However, it doesn't explicitly say 'use this instead of session_cancel_job' or similar, and doesn't mention when-not-to-use it (e.g., if the session is already terminal). The guidance is implied through the outcome constraint but not 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?

Annotations only provide flags (readOnlyHint false, openWorldHint true, idempotentHint false, destructiveHint false), so the description carries the burden of behavioral disclosure. It adds meaningful context: the session is durable, the tool does not invoke reviewer models, and the runtime persists evidence automatically. This goes beyond the annotations, though it does not cover duplicate-call behavior or return details.

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

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

The description is compact and front-loaded with the core purpose in the first sentence. The remaining two sentences add behavioral and workflow context without excessive fluff. The third sentence is slightly tangential to the tool itself but still earns its place by preventing misuse of session_attach_evidence.

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 the description does not state what the tool returns (e.g., a session ID needed by session_read, session_poll, or session_start_round). It also leaves the relationship to 'probing provider availability and model selection' ambiguous. For an initialization tool that subsequent siblings depend on, this is a significant completeness 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 50%; task and review_focus have descriptions, while caller and response_format are only represented by enums/defaults. The description does not elaborate on any current parameters, only mentions the evidence field of a subsequent step. The parameters are reasonably inferable from the schema, so this is adequate but not enhanced by the description.

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: 'Create a durable cross-review session'. It adds useful scope by noting it does not call reviewer models yet, which distinguishes it from round-starting siblings like session_start_round. However, it does not explicitly name sibling alternatives, so it falls short of full differentiation.

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 implied sequencing: 'after probing provider availability and model selection' and a workflow note about submitting evidence without session_attach_evidence. But the description never explicitly says when to choose this tool over session_preflight_check, session_start_round, or session_start_unanimous. Usage context is present but not 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?

Goes well beyond the provided annotations (readOnlyHint, idempotentHint, destructiveHint) by disclosing a genuinely subtle behavioral trait: decisions whose item.last_round equals the judge round AND no later round exists are excluded as 'no ground truth,' with an explanation of why ('we cannot tell if the ask would have come back'). This is exactly the kind of non-obvious scoping an agent needs to interpret results. Also adds version context and result shape. No contradiction with annotations.

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

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

Substantial but every sentence earns its place: version marker, function, inputs, algorithm, output, exclusion rule, and consumer decision. The most important behavioral detail (the no-ground-truth exclusion) is front-staged where it can't be missed, and the dangling operational references ('v2.14.0', 'item 2 / v2.13') add provenance without bloat.

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 complex analytical tool doing multi-session aggregation with a non-trivial ground-truth determination rule, this description is remarkably self-sufficient: it covers inputs, mechanism, output contract, edge-case exclusion, and the downstream decision it serves. The only marginal gap is the lack of a defined return schema, but no output schema exists and the prose already enumerates the return shape (per-peer TP/FP/TN/FN plus precision/recall/F1).

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 carries full weight, and it largely delivers: it adds meaning to three of the four parameters by embedding them in the algorithm ('via session_id, or filtered by judge peer / since timestamp'), clarifying that 'peer' means the judging peer and 'since' is a timestamp filter. response_format is left undiscussed, though its name and default make it self-explanatory. Strong compensation for the schema's silence, though not exhaustive.

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?

Opens with a specific verb+resource: 'compute precision/recall/F1 of the shadow judge against the empirical ground truth,' then details the exact event stream, correlation mechanism, and output shape. The extreme specificity of the resource ('session.evidence_judge_pass.shadow_decision' events vs. 'evidence_checklist resurfacing behavior') makes confusion with siblings like session_metrics or session_peer_reliability_report implausible, even without naming them 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?

Provides a concrete 'when to use' statement: 'Operator uses this to decide whether to flip a peer from shadow to active mode (item 2 / v2.13),' which ties the tool to a real decision gate. However, it never names the overlapping alternatives (session_peer_reliability_report, session_metrics, session_doctor) nor states when NOT to use it, leaving the exclusion side implicit.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, freeing the description from safety disclaimers. The description adds valuable behavioral context by explaining WHY the default is summary ('to keep stdio transports bounded') and that detail='full' returns a 'bounded page of full metadata.' This reveals the tool's internal rate-limiting rationale, which is genuinely useful behavior not evident from annotations alone.

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 fluff. The first sentence states the core purpose, the second explains behavior, rationale, and points to the alternative. Every clause contributes to the user's decision-making: what, why, and when-not. The most important information is front-loaded 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?

Given the tool has 5 parameters and no output schema, the description adequately covers the main usage decision (how to get full vs summary, and where to go for a single session). It could mention `outcome_filter` since that's a domain-specific filter, but the defaults and self-explanatory names reduce the ambiguity. The presence of annotations for read-only/idempotence fills the safety gap. Minor omissions prevent a 5, but the description is complete enough for an agent to use the tool correctly in most intended scenarios.

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 description coverage is 0%, so the description carries the burden of explaining parameters. It does explain the `detail` parameter's effect (summary vs full) and implies pagination via 'paginated,' which covers `limit` and `offset` conceptually. However, it leaves `outcome_filter` and `response_format` unexplained, and doesn't explicitly map the pagination wording to the parameter names. The description adds meaning for the most crucial parameters but still leaves the agent to infer the rest from names 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 opens with a clear verb-resource-scope triplet: 'List durable sessions saved under the local data directory.' This precisely distinguishes it from siblings like session_metrics or session_read, and the contrast with session_read is explicitly stated. The purpose is immediately understandable and differentiates from other session_* tools.

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

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

The description explicitly routes the agent: 'use session_read for one full session or detail='full' for a bounded page of full metadata.' This names the alternative tool (session_read) and provides the selection condition, leaving no ambiguity about when to choose this tool versus the alternative.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that the tool returns metrics for all or one session, but does not disclose further behavioral traits (e.g., data freshness, pagination, or performance). With annotations covering safety, the description provides some 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?

A single sentence that efficiently conveys the purpose and optional scoping. No wasted words.

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 2 parameters and no output schema, the description is brief. It does not explain the structure of the returned metrics or any usage constraints. While adequate for a simple read-only tool, more detail would improve completeness.

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 add meaning. It does: explains that session_id is optional and scopes results to one session. However, it does not describe what 'aggregate observability metrics' includes or the meaning of response_format beyond the 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?

The description clearly states the verb 'Return' and the resource 'aggregate observability metrics', and specifies scope (all sessions or one with session_id). This distinguishes it from sibling tools which focus on session actions like cancel, attach evidence, etc.

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 explicit guidance on when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or when not to use it.

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

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

Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it is 'Observational only' and enumerates the telemetry fields, providing useful context beyond annotations.

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

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

The description is three sentences, front-loaded with the purpose, and lists data fields efficiently. Minor redundancy could be removed, but overall well-structured.

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 simple read-only tool with two optional parameters and good annotations, the description provides sufficient behavioral context. It explains what data is returned, though it lacks output format details.

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%. The description does not explain the two input parameters (session_id and response_format) at all, leaving the agent without guidance on how to invoke the tool.

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 specifies 'Read-only per-peer reliability telemetry' and lists the exact data fields, clearly defining the tool's function. It distinguishes from siblings as no other tool in the list explicitly provides similar reliability metrics.

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?

States 'Observational only; does not change peer selection or mutate sessions,' giving clear context on when to use. However, it does not mention when not to use this tool compared to alternatives like session_report.

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?

Discloses non-blocking behavior, default detail filtering, and persistence of state beyond annotations; no contradiction with readOnly, idempotent, destructive hints.

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

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

Two sentences efficiently covering purpose, behavior, and parameter guidance with no redundant 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?

Given annotations, schema, and sibling tools, the description provides sufficient context for an agent to correctly invoke the tool in a polling workflow.

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%, but description adds meaning for 'detail' parameter; however, does not explain 'response_format' parameter, leaving some semantic 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 clearly states the tool returns 'durable session state and background job status' and distinguishes from blocking operations and sibling session_read by mentioning polling behavior and when to use alternative.

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 states when to use default detail=summary vs detail=full and recommends session_read for full forensic data, providing clear context for tool 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?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds valuable context beyond annotations: providers are not called, and inline/structured evidence is treated as review material without an attachment step. No contradiction with the annotations exists.

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 the central behavior front-loaded: 'Run the same enabled evidence and truthfulness gates used by a real review round, without calling providers.' Every clause earns its place, and there is no filler or repetition of schema/annotation details.

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 six-parameter tool with no output schema and no parameter descriptions, the description does not specify what the preflight result contains or how task/draft/evidence relate to the gates. However, the concise behavioral statement plus annotations make it minimally viable for an agent to choose and invoke the tool.

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

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

Schema description coverage is 0%, so the description must compensate for undocumented parameters. It only hints at evidence as 'inline/structured' and gives no semantics for task, draft, caller, session_id, or response_format. This leaves most parameters underspecified for an agent trying to construct a correct call.

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

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

The description states a concrete action: 'Run the same enabled evidence and truthfulness gates used by a real review round, without calling providers.' It clearly identifies the resource as submission preflights and distinguishes itself from a real review round. However, it does not explicitly differentiate from the sibling 'session_truthfulness_preflight_check', so it stops short of full sibling differentiation.

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 use before a real review round to validate gates without provider calls, and it explicitly notes that peer-submitted inline/structured evidence requires no separate attachment step, steering agents away from session_attach_evidence. It lacks explicit when-not-to-use guidance or named alternatives, but the context is clear enough for an agent to select it appropriately.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds the 'durable' aspect, suggesting persistent storage, but does not disclose error behavior, auth requirements, or rate limits. Given annotations cover the main behavioral aspects, a 3 is appropriate.

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. It efficiently communicates the core action and resource, earning its place with minimal verbosity.

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 simple read operation with annotations covering safety and a self-explanatory schema, the description is nearly complete. It lacks explicit mention of return structure, but the response_format parameter implies output formatting. The absence of an output schema means the description could state that the response contains the meta.json content, but this is minor given the tool's simplicity.

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 by explaining parameter meaning, but it does not mention either parameter. The schema itself provides clear semantics via the UUID pattern for session_id and enum for response_format, but the description adds no value for parameter understanding.

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 ('Read') and resource ('durable session meta.json') keyed by session_id. This is distinct from sibling tools like session_list (for listing) or session_events (for event data), and the term 'meta.json' clarifies the exact artifact being read.

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 when you need the raw meta.json content of a durable session, but it does not explicitly contrast with alternatives or state when not to use it. With many session-related siblings, explicit routing would be helpful, but the specificity provides some implied guidance.

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

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

Annotations already declare idempotent=true and destructive=false, and the description does not contradict them. It adds useful behavioral context: only stale in-flight rounds are affected, only the caller's own sessions are recovered, and a verified capability token is required.

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 focused sentences: the first front-loads the core action and context, the second adds necessary constraints. No filler or redundancy.

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

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

The description covers what, when, and preconditions, which is largely sufficient for a simple two-parameter tool. However, it does not define what qualifies as 'stale,' explain the return/output behavior, or clarify how response_format affects the result, and there is no output schema to fill that 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 description does not mention the caller or response_format parameters at all. The enum values are somewhat self-explanatory, but the description adds no guidance on how these parameters affect recovery or the output.

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 action with a concrete resource: marking unfinished sessions with stale in-flight rounds as recovered after an MCP host restart. This clearly distinguishes the tool from sibling list/read/poll/finalize tools.

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

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

It gives clear context for when to use the tool (after a host restart, before explicit resumption) and adds restrictive conditions (owned sessions only, verified capability token required). It does not name alternative tools or explicitly state when not to use it, but the context is sufficient.

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?

The description says 'save a Markdown report,' implying a write operation, but annotations set readOnlyHint=true, indicating it should not modify state. This is a direct contradiction.

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 a single sentence, concise and front-loaded with the main purpose. However, it sacrifices clarity for brevity, leading to ambiguity.

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 two parameters, the description is incomplete. It does not describe the return value or parameter details, and the contradiction with annotations undermines completeness.

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 does not explain any of the two parameters (session_id, response_format). Schema description coverage is 0%, so the description should compensate but fails to do so. Additionally, the description mentions Markdown but response_format defaults to json, causing further confusion.

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 it generates and saves a Markdown report listing specific contents (convergence, peer decisions, etc.), which provides a clear verb and resource. However, it does not distinguish from sibling tools like session_events or session_check_convergence, which might overlap.

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

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

There is no guidance on when to use this tool versus alternatives. No context about prerequisites or typical use cases is provided.

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?

The description adds meaningful behavior beyond annotations: the operation is asynchronous, returns immediately, persists evidence durably, transports it automatically, and imposes capability-token requirements when resuming an existing session. Annotations only convey readOnlyHint=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false; the description enriches that with execution and authentication 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 three dense, front-loaded sentences with no filler. The core action and return behavior appear first, followed by evidence handling and the session capability caveat. Every sentence earns its place and no information is repeated from the schema.

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

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

For a complex async tool with 10 parameters and no output schema, the description covers the key operational essentials: it starts a background round, returns a pollable ID, persists evidence, and clarifies auth requirements. It does not explain the polling lifecycle or the meaning of task/draft/caller beyond their names, and without an output schema some return-format detail is left unspecified, but the description is still reasonably complete for selecting and invoking the tool 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 description coverage is low at 30%, so the description must compensate for many parameters. It does add meaning for `evidence` (durable persistence, automatic transport) and `session_id` (capability-token requirement), which are genuinely helpful. However, the other seven parameters — task, draft, caller, peers, caller_status, response_format, and reasoning_effort_overrides — receive no additional semantic clarification in the main description, leaving gaps for a low-coverage 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: "Start a real peer-review round in the background and return immediately with a session_id/job_id for polling." This clearly distinguishes the tool from read-oriented siblings like session_read or session_poll, and from the related start_unanimous tool by emphasizing a background, pollable round.

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 concrete usage context: it positions itself as the routine path by saying evidence is "transported automatically; no separate attachment step is required," implicitly routing away from session_attach_evidence. It also clarifies the existing-session condition: opening a new session does not require the petitioner's capability token, while resuming does. It does not explicitly compare against alternatives like ask_peers or session_start_unanimous, so it falls just 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?

The description adds meaningful behavioral detail beyond the annotations: background/asynchronous execution, durable persistence of evidence, automatic transport to reviewers, and a token requirement for existing sessions. This is consistent with annotations declaring readOnly=false and idempotent=false, and it gives the agent a clearer picture of side effects and prerequisites.

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 well-organized: the first sentence states the core purpose, the second covers evidence behavior, the third points to sibling semantics, and the fourth addresses session security. There is little wasted text, and important information is front-loaded.

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 15-parameter background job with no output schema, yet the description does not explain the return value, how to monitor progress, or how parameters such as task, mode, peers, and lead_peer interact. Delegating key semantics to run_until_unanimous helps, but the definition is not self-sufficient for an agent trying to invoke it correctly in diverse situations.

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 semantics for key parameters: evidence is persisted durably, session_id has a token requirement, caller semantics are delegated to run_until_unanimous, and termination depends on max_rounds or budget. However, schema description coverage is only 33%, and the description still leaves many parameters — such as task, mode, peers, lead_peer, initial_draft, and response_format — without meaningful explanation.

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 opens with a specific action and resource: starting real API generation/revision rounds in the background. It states termination conditions (unanimity, max_rounds, or budget limit) and distinguishes itself from siblings by emphasizing background execution and referencing run_until_unanimous. This is sufficient for an agent to identify what the tool does and how it differs from session_start_round.

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 clear context: uses background rounds, persists evidence automatically so no separate attachment step is needed, and explains the capability-token requirement when resuming an existing session. It does not fully articulate when not to use this tool versus other siblings, but the context is clear enough for most selection decisions.

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

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

Annotations already declare destructiveHint and idempotentHint, but the description adds significant behavioral detail: it removes stale quarantine entries only when prune_corrupt is opted in, requires a verified capability token, and clarifies that the token belongs to a different identity than the affected petitioner. This goes well beyond what the annotations convey.

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 compact: three sentences front-load the core purpose and then add auth and version-specific behavior. The token-file warning is slightly elaborate but relevant to safe invocation, so no sentence is pure 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?

The description covers purpose, auth requirements, and destructive scope, which are critical safety aspects. However, there is no output schema, yet the description does not mention return values or response_format behavior, and most parameters remain semantically unexplained. It is adequate for safety but incomplete for confident 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%, so the description carries the burden of explaining parameters. It only clarifies reason's 200-character limit and prune_corrupt's quarantine behavior. The other five parameters—caller, outcome, idle_minutes, response_format, and corrupt_min_age_days—are left undocumented, which is insufficient for a 7-parameter tool.

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: 'Finalize unfinished sessions whose metadata has been idle for at least 24 hours.' It also distinguishes the tool from siblings by noting it is 'the one mutation that acts ACROSS owners,' which prevents confusion with per-owner session mutations.

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 usage context: sweep is for idle unfinished sessions and is uniquely cross-owner, which helps an agent select it over owner-scoped alternatives. It also provides an exclusion by warning that a self-declared identity is refused and this is 'no way out of a token-file failure.' It does not explicitly name alternate tools, so it stops short of a 5.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior. Description adds that the top-level pass reflects both enabled runtime gates and no longer emits truthfulness-only false positives, but does not define 'runtime gates' or the pass semantics, so the added value is real but incomplete.

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, no filler; the alias fact and the behavior delta are front-loaded. However, it is concise at the expense of content, so this is efficiency rather than fully informative 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?

For a tool with 6 params, no output schema, and many preflight-related siblings, the description does not cover what the check returns, what inputs mean, when to use it, or how the two gates interrelate. An agent has no basis to invoke it correctly beyond guessing compatibility with session_preflight_check.

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?

All six parameters are undocumented in the schema (0% coverage), and the description names none of task, draft, evidence, caller, session_id, or response_format. The schema only gives structural constraints like enums/pattern, so an agent cannot know what values mean.

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?

Description identifies this as a backward-compatible alias for session_preflight_check, so an agent can map it to a known sibling, but it never states the underlying operation independently. The title adds 'Check Submission Preflights,' yet the actual checks, inputs, and decision criteria are left to inference.

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 advice on when to call this vs session_preflight_check or any sibling. 'Backward-compatible alias' and 'Legacy Alias' imply the canonical sibling is preferred, but this is implicit, not an explicit routing rule.

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