cross-review

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v4.4.16
Disambiguation3/5
Several tools overlap in function: session_init, session_start_round, ask_peers, run_until_unanimous, and session_start_unanimous all initiate or run review rounds with evidence handling. Distinct names help but the descriptions repeatedly impose the same evidence-persistence caveat, and session_preflight_check vs session_truthfulness_preflight_check are near-aliases despite the backward-compat note.
Naming Consistency4/5
Most tools follow a consistent session_* or ask_/run_/probe_/contest_/regenerate_/escalate_ verb-noun pattern. The few deviations like session_evidence_checklist_update, session_evidence_judge_pass, and session_judgment_precision_report are longer but still reasonably predictable. Minor inconsistency: some begin with 'session_' while others start directly with verbs, but the overall catalog feels coherent.
Tool Count3/5
With 31 tools, the server is on the heavier side but the domain (durable sessions, peer review, evidence broker, operator governance) is complex enough to justify many. Still, the count exceeds the typical 3-15 range, and several tools (e.g., session_truthfulness_preflight_check as an alias) could be merged or deprecated, pushing it toward the 'heavy' edge.
Completeness4/5
The surface covers the full session lifecycle: init, read, poll, start rounds, recover, cancel, finalize, sweep, plus evidence verification and judgment tools. Notable gaps: there's no tool to list or query evidence items directly (only checklist status updates), and no public tool to modify session metadata once created, but operators have finalize and recovery paths, so core workflows are largely complete.
Average 3.8/5 across 31 of 31 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 215 commits in the last 12 weeks
- Last stable release on September 5, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations by revealing that the top-level pass now reflects both enabled runtime gates, eliminating truthfulness-only false positives. Annotations already provide readOnlyHint and idempotentHint, so the bar is lower, but the description meaningfully extends transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences) and front-loaded, but it omits critical information about parameters and usage. While concise, it sacrifices clarity and completeness, earning a middle score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters (with 0% schema description coverage) and no output schema, the description is woefully incomplete. It does not explain what the tool returns, how to use inputs, or any prerequisites. Only the behavioral quirk is addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description provides no information about any parameters (session_id, task, draft, evidence, caller, response_format). The description does not compensate at all, leaving the agent without guidance on parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it is a backward-compatible alias for session_preflight_check and explains a behavioral change, but does not clearly state the core function of checking submission preflights. The title helps, but the description is ambiguous for an agent unfamiliar with the original tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., session_preflight_check). The description implies legacy use but does not provide practical usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior. The description adds specific context by naming the exact information returned (version, data directory, security mode) and specifying the server scope, which helps an agent understand the tool's output beyond what 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is efficient in stating purpose but omits critical parameter usage. It is front-loaded with the main verb, but the lack of parameter context makes it less effective. Could be improved by briefly noting parameter options.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is simple with two optional parameters and no output schema, the description should at minimum indicate that caller and response_format customize the output. It does not address this, leaving a significant gap in understanding how to invoke the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no parameter descriptions in schema) yet the description provides no explanation of the two parameters (caller and response_format). Both have enums and defaults, but an agent cannot know their purpose from either the schema or description. Description fails to compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns runtime information for a specific server ('API-only Cross Review MCP server') and lists the included fields (version, data directory, active security mode). This distinctively separates it from sibling tools which are session-focused.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 lacks context like 'Use this to check server status before performing actions' or any mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true), and the description is consistent with these — no contradiction. The description adds useful context about the operator token and host requirement beyond the annotations. However, it misses the most agent-relevant behavioral details for a state-mutating operation: whether finalization is terminal, whether it can be resumed, what happens to in-flight rounds, and what the return looks like. Annotations lower the bar, but the description still leaves side effects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with every clause earning its place; the operator scope is front-loaded ahead of the action, and the token/host requirement is packed into the second sentence. The only minor waste is restating the 200-character reason limit that already exists in the schema's maxLength constraint. Otherwise remarkably tight for the amount of information conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderate-complexity mutation tool with no output schema, the description covers the core operation and access model competently. However, with no output schema to document return values, the burden on the description rises, and it leaves unexplained: whether finalization is terminal, the return/confirmation format, and error behaviors (e.g., unknown session_id, finalizing an already-finalized session). The absence of any guidance on interaction with concurrent rounds is notable given siblings like session_recover_interrupted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description bears a heavy burden, but it adds almost nothing beyond restating the 200-character reason cap already present in the schema's maxLength. It offers no guidance on the semantics of choosing among 'converged' vs 'aborted' vs 'max-rounds', does not disambiguate the confusing 'caller' enum (listing model names with default 'operator'), and is silent on session_id state requirements and response_format. For a tool with low schema coverage, this is a significant gap that the description fails to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a specific verb ('mark'), a resource ('a durable session'), and the exact set of outcome values ('converged, aborted or max-rounds'), leaving no ambiguity about what the tool does. The 'Operator-only' scoping and title align tightly with the name. However, it doesn't explicitly differentiate itself from the 28 siblings (e.g., session_cancel_job, session_start_round), even though such differentiation would be valuable, keeping it at a 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives meaningful contextual constraints — 'Operator-only' and 'Requires the dedicated operator capability token from a separate human-console host' — which effectively tell the agent when it can and cannot call this tool. However, it provides no explicit routing to or exclusion from alternatives, which matters given the large sibling set. The usage guidance is implied through access prerequisites rather than stated as when-to-use vs. when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it notes that cancellation is a request (not immediate), requires specific tokens, and mentions AbortSignal support. Annotations already indicate idempotentHint=true and destructiveHint=false; the description does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences) and front-loads the purpose. It is not verbose, but the lack of parameter descriptions reduces structural clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no output schema, and 0% schema coverage, the description is incomplete. It explains purpose and some constraints but omits parameter details, return values, and error handling, leaving agents underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 only mentions reason's maxLength (300 chars). It does not explain session_id, job_id, caller, or response_format, leaving agents without crucial parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool cancels running background jobs in a durable session. It uses a specific verb-resource pair ('request cancellation' + 'background jobs in a durable session'). It distinguishes from siblings because many session_ tools exist, but only this one targets cancellation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies token requirements and restrictions (another peer cannot cancel), providing some usage context. However, it does not explicitly state when to use this tool versus alternatives like session_doctor or session_events, nor does it mention 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With all annotations false, the description carries the burden of disclosing behavior. It meaningfully explains that shadow mode never mutates state, active mode enforces unanimous verified-satisfied judgments with non-empty rationales and zero parser warnings, and self-judging causes fail-closed behavior. This goes well beyond the structured annotations, though it leaves the exact effects of 'promoting' somewhat vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and information-dense, consisting of two front-loaded sentences that establish purpose, prerequisites, mode differences, and key constraints. It has no filler, though the density of specialized terms like 'parser warnings' and 'promotes' could benefit from brief expansion.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 sparse annotations, the description is insufficient. It leaves critical operational details undefined, such as what 'draft' contains, how item_ids are selected, what review_focus does, and what the tool returns. An agent would struggle to construct a correct call with only this description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only clarifies judge_peers and shadow_mode. It does not explain the meaning or usage of session_id, draft, round, caller, item_ids, review_focus, or response_format, which are essential for correctly invoking this tool with 9 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as an operator-authorized multi-peer evidence judgment process, with specific operational constraints. It distinguishes itself from sibling tools like session_evidence_judge_pass through the explicit 'consensus' focus, though it does not directly name any sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides necessary prerequisites (operator token, two distinct judge peers) and differentiates active vs shadow modes, giving some contextual use guidance. However, it does not explicitly state when to choose this tool over alternatives such as ask_peers, run_until_unanimous, or session_evidence_judge_pass, nor does it mention exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal a non-read-only, non-idempotent mutation, and the description adds useful context: the operation runs in the background, returns immediately, persists evidence durably, and transports it automatically. This goes beyond the structured hints without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, with the action and return behavior in the first sentence. The second sentence reinforces evidence handling but partially duplicates the evidence parameter's own schema description, so it is not entirely additive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter tool with nested objects, no output schema, and only 30% schema coverage, the description is too sparse. It omits required parameter semantics, the meaning of `peers`/`caller` enums, response format selection, and how the returned session_id/job_id should be polled in practice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 30%, and the main description only elaborates on `evidence`. Required parameters like `task` and `draft`, plus `peers`, `caller`, `session_id`, `caller_status`, and `response_format`, receive no semantic explanation in either the description or the schema. The description does not compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Start a real peer-review round') and adds the key async behavior: launch in background, return session_id/job_id for polling. It does not explicitly differentiate from sibling session_start_unanimous beyond the vague word 'real', so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys an async usage pattern (start and poll) and the evidence parameter explicitly says 'Do not call session_attach_evidence for this routine path', giving one clear exclusion. However, it never states when to prefer this over run_until_unanimous, session_start_unanimous, or ask_peers, so the guidance is mostly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, fully covering the safety profile. The description adds that the result is 'stable' and includes a 'capability contract' and 'active tool list', which provides some behavioral context but does not go beyond what annotations already imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the key information: what is returned. There is no extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with no required parameters and good annotations, the description is largely adequate. However, it does not explain what the 'capability contract' or 'active tool list' contain, and omits parameter details. Slightly incomplete for a new agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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. However, it does not mention the two optional parameters (caller, response_format) or their meaning. The agent gets no additional insight beyond the schema's enum names and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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' and specific resource 'runtime capabilities contract' make the purpose distinct. It differentiates well from siblings like server_info or session tools, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, context, or when not to use it. Given the many sibling tools, usage guidelines would help the agent decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavior beyond annotations: evidence is durably persisted and auto-transported without operator attachment, and execution hits real provider APIs unless CROSS_REVIEW_STUB=1. These side effects align with readOnlyHint=false and openWorldHint=true and are exactly what an agent needs to know before invoking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences: the action is front-loaded, then key evidence behavior, then runtime mode. Every sentence adds operational information, and nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters, nested objects, no output schema, and a non-read-only side-effect profile, the description is too thin. It doesn't cover return format, async/poll behavior, failure modes, or how this relates to the surrounding session lifecycle tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 30%, so the description needed to explain the remaining parameters. It only elaborates on evidence persistence and vaguely references 'selected peers', while task, draft, response_format, caller_status, and the nested reasoning_effort_overrides remain unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 ('Run a real API review round against selected peers'), which clearly states the tool's core action. It does not explicitly distinguish itself from siblings like session_start_round or probe_peers, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives useful operational context: evidence is transported automatically and real provider APIs are the default, with stubs only under CROSS_REVIEW_STUB=1. However, it never says when to choose this tool over sibling session/round tools, leaving the choice to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
All annotation hints are false, so the description carries the burden of behavioral disclosure. It says the escalation is 'durable,' implying a persistent side effect, but it does not mention whether the escalation is reversible, notifies external parties, or what the response looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with the core purpose front-loaded and a relevant constraint right after. Every word earns its place and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is serviceable for a simple escalation record, but with no annotations, no output schema, and five parameters (three enums), it leaves severity meaning, response_format behavior, and post-call outcomes unexplained. An agent could call it correctly using defaults but would be guessing about semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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. The only parameter detail, 'the reason accepts at most 1,000 characters,' merely repeats the schema's maxLength. No semantics are added for session_id, severity, caller, or response_format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Record a durable operator escalation.' It also gives the condition ('sessions that require human judgment or external intervention') and is clearly distinct from the sibling session_* management tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for sessions that require human judgment or external intervention' provides a clear usage condition. However, it does not explicitly name alternative tools or state when not to use it, so it stops short of the top tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only, idempotent, open-world safety profile. The description adds value by revealing that the tool makes network calls to provider APIs, uses API keys, selects a model, and probes reachability—behavioral detail 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire definition is one dense, front-loaded sentence that begins with the primary verb and packs three related behaviors without filler. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for deciding to invoke the tool and understanding its general effect, but with no output schema it does not say what the tool returns or how providers/keys are identified in the output. A brief mention of the result shape or error behavior would complete the picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 the undocumented parameters, but it never explains caller or response_format. 'Current API keys' hints at credentials but does not map to the caller enum, and the JSON/markdown response switch is unmentioned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Query official provider APIs'), a resource ('available models for the current API keys'), and two follow-up outcomes (select highest-capability model, verify reachability). It is unambiguous about what the tool does, though it does not explicitly contrast itself with siblings such as ask_peers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to call it: when an agent needs to inventory models for the current API keys or confirm provider reachability. It does not state exclusions or explicitly name an alternative like ask_peers, so it misses the full when-vs-alternatives guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses the termination condition, durable evidence persistence, automatic transport, relator lottery behavior, server rejection of lead_peer===caller with the exact error code, and the workspace hard gate. This substantially enriches what the structured annotations alone convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core behavior, then adds evidence handling and versioned relator-lottery semantics. Every sentence carries unique behavioral information; the density is justified by the complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 14-parameter tool with no output schema, the description covers the core loop, evidence handling, and relator gate, which is strong. However it omits return/polling behavior, cost controls, mode/peer selection semantics, and terminal outcome representation, leaving gaps that an agent must resolve elsewhere.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 36% schema description coverage, the tool text correctly explains the most consequential parameters (caller, lead_peer, evidence) but leaves mode, peers, max_cost_usd, initial_draft, until_stopped, response_format, and other parameters to be inferred from enums/defaults. It compensates for key protocol params but not for the full parameter set.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource statement: 'Generate or revise a draft and continue real API peer-review rounds until unanimous READY or the configured max_rounds is reached.' This clearly identifies the purpose, but it never names or contrasts sibling tools such as session_start_unanimous, so the agent must infer the differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use or when-not-to-use guidance relative to the many session_* and ask_peers siblings. The nearest guidance is the conditional explanation of caller/lead_peer and the note that evidence needs no manual attachment, but that addresses parameter workflow rather than tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description's burden is reduced. It adds value by stating that no providers are called and that peer-submitted evidence requires no manual attachment. This provides useful behavioral context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, no redundancy, and no extraneous information. Every word contributes to the tool's core purpose and behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and no parameter descriptions, the description is inadequate. It does not explain what the tool returns, how to interpret results, or how to properly fill required fields like task and draft. The tool is simple but the description leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 only indirectly mentions 'evidence' in the context of peer-submitted inline/structured evidence, but does not explain the purpose or usage of other parameters like task, draft, caller, session_id, or response_format. This leaves the agent with insufficient guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs the same evidence and truthfulness gates as a real review round, without calling providers. This specifies the verb ('Run'), the resource ('gates'), and distinguishes it from a full review round. The title 'Check Submission Preflights' further reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use case (pre-checking evidence and truthfulness before a review round), but does not provide explicit guidance on when to use versus sibling tools like 'session_truthfulness_preflight_check'. No exclusion criteria or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true and destructiveHint=false. The description adds the context of marking sessions as recovered after restart, which aligns. However, it does not elaborate on what 'stale' means or if there are side effects, but given the annotations, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the function. It is front-loaded and efficient, though slightly dense. It earns its place without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and the simple nature of the tool, the description provides the core context. However, it lacks details on what 'stale in-flight rounds' means and what the response looks like. It is minimally complete but could be better.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 explain the 'caller' or 'response_format' parameters. While both have enums and defaults, the description should clarify their role to help the agent select correct values. This is a clear gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 recover interrupted sessions after a restart by marking unfinished ones as recovered. The verb 'recover' and resource 'interrupted sessions' are specific, and the context of restart distinguishes it from other session management tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage scenario (after a restart) and outcome (explicit resumption). It does not explicitly state when not to use or provide alternatives, but the purpose is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are thin (readOnly=false, idempotent=false, destructive=false), so the description carries real weight and delivers: background execution with concrete stop conditions, evidence that is 'persisted durably and transported automatically,' and version-pinned semantics referencing run_until_unanimous. It stops short of warning that 'real API' rounds incur real cost or telling the caller how results are later retrieved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with the purpose and stop conditions front-loaded in the first sentence. Sentence 2 partially duplicates the evidence schema description, and sentence 3 defers substance via 'see that tool for details' rather than explaining it, but there is no outright waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A 15-parameter background-job starter with no output schema needs to state what it returns and how to monitor or cancel the job; the description mentions neither, forcing the agent to infer session_poll and session_cancel_job from sibling names. It is adequate for initiating the job but incomplete for the full lifecycle.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 33% schema description coverage, the description should compensate for undocumented parameters, but it only addresses `evidence` (which the schema already describes in greater detail) and `caller` (deferred to run_until_unanimous). Ambiguous enums like mode ('ship' vs 'circular') and the roles of lead_peer, until_stopped, and max_cost_usd are left unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action — 'Start real API generation/revision rounds in the background' — and names the three termination conditions (unanimity, max_rounds, budget limit). The 'background' qualifier hints at the distinction from the synchronous run_until_unanimous, but it never names session_start_round as the single-round alternative, so sibling differentiation is incomplete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description positions this as the background variant and defers `caller` + relator-lottery semantics to run_until_unanimous, and the evidence parameter adds an explicit exclusion: 'Do not call session_attach_evidence for this routine path.' However, the tool never states when to prefer this over session_start_round or run_until_unanimous, leaving the when-to-use matrix partial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint=false (so it's a state-changing operation), idempotentHint=true (safe to retry), and destructiveHint=false. The description adds useful context by noting the prune_corrupt option removes entries from quarantine, which is a subtle destructive-ish behavior not covered by annotations. However, it doesn't detail what 'finalize' does to the underlying session state beyond that, or whether there are side effects on related data. It adds some value but the bar is lower because annotations carry the safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise — three sentences total, and the first sentence is front-loaded with the core purpose. The version note and prune_corrupt detail are placed at the end, which is good structure. Every sentence adds value; no fluff or repetition of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters and 0% parameter documentation, the description is notably incomplete. It covers the idle condition and the prune_corrupt feature, but doesn't explain the meaning of 'outcome', 'response_format', or 'corrupt_min_age_days' — these are critical for correct invocation. The lack of an output schema means the description must also hint at return values, which it doesn't. Overall, an agent could call it safely with defaults but can't make informed customizations without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% — the description provides NO parameter-level explanation. With 7 parameters and 0% coverage, the description should compensate, but it doesn't. It only mentions the reason max length and the prune_corrupt option, leaving idle_minutes, outcome, response_format, corrupt_min_age_days, and caller completely undocumented. An agent cannot know the meaning or effect of most parameters without opening the schema, and even then the schema only shows types/enums, not semantics like when to change defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Finalize'), a specific resource ('unfinished sessions'), and a precise triggering condition (idle ≥24 hours). It also mentions the terminal reason length limit and the optional prune_corrupt behavior, which adds specificity beyond just naming the action. This clarity distinguishes it from other session tools (which focus on other lifecycle steps like init, list, read).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool is for finalizing idle sessions — the idle condition (24 hours) and the mention of 'unfinished sessions' give the agent clear context on when to call it. It does not explicitly name sibling alternatives or exclusion conditions, but the context is strong enough that an agent can infer when this tool is appropriate versus session_init/session_read/session_finalize.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
All annotations are false, so the description carries the full burden of behavioral disclosure. It discloses the token requirement, the judge peer's role, the 'cannot judge its own ask' constraint, the promotion rule (satisfied=true and confidence='verified'), that everything else stays open, that terminal statuses are untouched, and that shadow_mode is non-mutating. These details go well beyond a generic tool statement and make side effects predictable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is about four sentences and packs a lot of information without being overly verbose. The opening sentence establishes the purpose, and subsequent sentences detail behavior. There is minor redundancy (e.g., 'Operator-authorized' and 'Requires the dedicated operator capability token' could be merged), but overall it is efficiently structured and front-loads the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters, no output schema, and zero param descriptions, the description covers the core process well (what items it operates on, promotion rules, exceptions) but omits parameter semantics for most fields and does not describe return structure. It gives enough for a basic invocation but not enough to use optional parameters like round, item_ids, review_focus, or response_format effectively. The complexity warrants more detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning only for 'draft' (the supplied text) and 'judge_peer' (the configured reader), with no explanation of the other 7 parameters (session_id, round, caller, item_ids, review_focus, response_format, shadow_mode). An agent would have to infer or guess the role of item_ids, review_focus, and response_format. This is a significant gap given the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('judge pass'), a specific resource ('Evidence Broker'), and what it does: runs an LLM satisfied-detection pass over open checklist items. It also names the sibling it is not (consensus pass) indirectly by calling itself a judge pass. The distinction from related tools is clear enough for an agent to route correctly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it requires an operator token, operates on currently-open items, and promotes only satisfied+verified items. However, it does not explicitly state when to prefer this tool over the consensus pass or other sibling tools, nor does it mention exclusions beyond 'terminal operator statuses and already-addressed items.' No alternative is named, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (destructiveHint=false, readOnlyHint=false). Description adds context: it's an optional operator promotion, no human operator action required for ordinary reviews, and runtime persists material durably. However, it does not fully explain side effects or permissions, but given the restricted use case, it's sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. Front-loaded with the warning and alternative instructions. Every part is necessary and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters and no output schema, the description covers purpose and usage but lacks parameter details. Given that the tool is essentially restricted to operators and AI agents should not call it, the information is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 explain any parameter meanings or usage. For example, it doesn't clarify what `label`, `content`, or `extension` represent. This leaves the agent without critical information for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states this is an operator-only tool for attaching evidence, explicitly distinguishing it from other tools by stating AI callers must not use it. Title 'Promote Operator Evidence (Optional)' reinforces purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states that AI callers must not use this tool and provides clear alternatives: pass evidence through the `evidence` field of other tools like `ask_peers`, `session_start_round`, etc. This gives unambiguous usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits beyond annotations: read-only by default with opt-in modification via repair=true, specifics of repair (only touches specific contradiction state), legacy artifact handling, and terminal findings enumeration. This adds valuable context not present in annotations (which only hint at idempotency and non-destructiveness).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose and dense with technical details (e.g., 'v3.6.0', 'pre-v3.2.0 corruption', '~38% rate'). While every sentence adds value, the length and jargon may hinder quick comprehension. Structuring with bullet points or shorter sentences would improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, multi-faceted audit), the description covers major behaviors: read-only default, repair mechanics, legacy enumeration, terminal findings. It lacks description of output format (beyond noting the 'repaired' array) but adequately addresses the core functionality. The absence of an output schema raises the burden, but the description meets most requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description bears full burden. It explains repair, include_legacy, and include_terminal_findings parameters with precise semantics. However, limit, caller, and response_format are not described, leaving gaps. The explanation for the explained parameters is clear and adds meaning beyond the schema enum/default values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs an 'operational audit' across durable sessions, enumerating specific categories like open/stale/blocked cases, legacy metadata, evidence asks, Grok errors, and token noise. This distinguishes it from sibling tools like session_list or session_read by being a comprehensive health check rather than a simple listing or retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for auditing session health and troubleshooting, but does not explicitly state when to use this tool versus alternatives. It lacks direct comparisons or exclusions, though the detailed behavior (read-only default, repair opt-in) provides contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a mutating, non-idempotent operation. The description adds valuable behavioral context beyond annotations: the session is durable, reviewer models are not invoked yet, and evidence submitted later is persisted automatically without human intervention or an attach step. This meaningfully clarifies side effects and workflow behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The core purpose is front-loaded, and the second sentence adds essential workflow context about evidence persistence and the absence of reviewer invocation. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the key workflow context: when to call it, what it does not do, and how evidence should be handled afterward. It does not name the specific 'subsequent review starter' tool or describe return values, but given the moderate complexity and the presence of sibling tools, this is a minor gap rather than a critical omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, and the description does not compensate for the undocumented caller and response_format parameters. It mentions the evidence field, but that is not a parameter of this tool. The description adds no meaning to task, caller, review_focus, or response_format beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 also distinguishes itself from siblings by noting it runs 'after probing provider availability and model selection' and explicitly says 'This does not call reviewer models yet', separating it from ask_peers and 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit sequencing guidance ('after probing provider availability and model selection'), clarifies what the tool does not do ('does not call reviewer models yet'), and tells callers to submit evidence via the subsequent review starter instead of using session_attach_evidence. This effectively provides when, when-not, and an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (all false), the description discloses the key behavioral trait: 'every transition is appended to evidence_status_history with the operator's optional note', which is consistent with idempotentHint=false since repeated calls create additional history entries. It also explains the runtime auto-promotion behavior that owns the 'addressed' status. This enriches context without contradicting the structured hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Each of four sentences earns its place moves forward: the role and version, the statuses with crisply scoped definitions, the 'addressed' exclusion, and the history side effect. Context is reasonably|null|. There is no filler or tautology — it reads as a spec, not boilerplate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, no parameter descriptions, and only negative annotations, the description covers the full decision surface: all four legal statuses, the forbidden status, and the side-effect of appending history entries. Remaining gaps are minor: what response_format returns and the exact provenance of item_id are not explained, but the operator workflow and status semantics are completely usable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Given 0% schema description coverage, this description carries the semantic weight for the most important parameter, 'status': it defines exactly what each enum value resolves when monitoring an operator action. It also clarifies that 'note' is the optional operator note appended to history. It does not explain session_id, item_id, caller, or response_format, but their schemas' patterns and enums already serve those adequately — the definition focuses its budget where ambiguity is highest.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Mark a checklist item') and enumerates all four legal statuses with their operational meanings: satisfied, deferred, rejected, open. It clearly signals that 'addressed' is not settable through this tool, which is an additional scope boundary. The operator-workflow framing and status semantics distinguish it from evidence-attachment and judging siblings without needing to name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use context: each status is mapped to the operator's workflow condition ('operator confirms the ask was answered', 'out of scope for this session', etc.). It also gives a crisp when-not-to-use rule: the 'addressed' status is réservé for runtime auto-promotion and cannot be set here. It does not name alternative sibling tools explicitly, but the exclusion and conditional semantics provide solid routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, it explains that rotation produces only fingerprints in the response and that the operator token must be isolated in a separate human-console MCP host. These details add real security behavior knowledge that is not present in annotations or the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the action, followed by the prerequisite, output constraint, and distribution rules. Every sentence earns its place; there is no fluff or redundant restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive security-sensitive operation, it names the prerequisite, describes the response limitation, and provides host-scope safety rules. Since the annotations already signal destructive behavior and there is no output schema, the description is complete enough for an agent to invoke the tool safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description should compensate. It maps the 'caller' concept to 'six peer identities plus a distinct operator', which helps interpret the enum, but it never explicitly clarifies the response_format parameter or its default. The enum values are self-explanatory enough to avoid a lower score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Rotate') and a specific resource ('the seven caller capability tokens'), and it clearly distinguishes this from the session and info tools listed among siblings. The noun phrasing could be tautological, but the enumeration of peer identities plus operator gives concrete scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides strong contextual guidance: the prerequisite (requires current dedicated operator token), the operational handling of peer tokens vs the operator token, and explicit hosts where the operator token must never be placed. It does not explicitly compare to an alternative tool, but no sibling is a competing token-regeneration tool, so this context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate not read-only, not destructive, not idempotent. The description goes far beyond: it details side effects (stamps a contestation record, initializes a new session, links via contests_session_id), auth requirements (capability token or operator token), and error conditions (cannot_contest_in_flight_session). This is thorough disclosure of behavioral traits, fully compensating for the sparse annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence adds critical information: purpose, constraints, auth, conditional logic, side effects, preconditions, and invariants. It is front-loaded with the core purpose and follows a logical flow, making it efficient without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 params, 3 required, no output schema, rich invariants), the description covers all essential aspects: prerequisites, side effects on the original and new sessions, chain-of-custody rules, and error cases. There is no mention of return value, but without an output schema and given the action-oriented nature, this is acceptable; the agent has enough to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the primary parameters—session_id (the contested session), reason (max 4000 chars, though this repeats schema), and new_task (implied as the task for the new session)—and mentions new_initial_draft implicitly by context. However, it does not explain new_caller, response_format, or caller, leaving those to inference from defaults and enums. Partial compensation, but gaps remain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'formally contest a final verdict and open a new deliberation cycle,' a specific verb and resource that clearly distinguishes it from siblings like session_finalize or session_init. It unambiguously states the tool's function and scope, making its purpose immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit conditions: 'Petitioner READY (acata) → notify the human operator ...; petitioner NOT_READY (contesta) → contest_verdict.' It also states preconditions ('original session must be in a final state') and exclusions ('once contested, a session cannot be contested again'), and instructs to 'contest the LATEST session in the chain.' This gives clear when-to-use and when-not-to-use guidance relative to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![cross-review MCP server](https://glama.ai/mcp/servers/LCV-Ideas-Software/cross-review/badges/card.svg)](https://glama.ai/mcp/servers/LCV-Ideas-Software/cross-review)

Score Badge

Copy to your README.md:

[![cross-review MCP server](https://glama.ai/mcp/servers/LCV-Ideas-Software/cross-review/badges/score.svg)](https://glama.ai/mcp/servers/LCV-Ideas-Software/cross-review)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/LCV-Ideas-Software/cross-review'

If you have feedback or need assistance with the MCP directory API, please join our Discord server