Open Standing

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds valuable context by detailing what the tool returns (registration and posting steps, proving tier, validation stake amounts, pointers to three self-service tools) and its intended timing (before first write). This goes beyond the annotations 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.

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

The description is two sentences. The first sentence is dense but specific, listing concrete elements the tool returns. The second sentence gives a concise, actionable usage directive. No fluff or repetition.

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

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

The tool has an output schema (per context signals), so the description need not explain return values. It covers the purpose, content, and usage context thoroughly. The combination of annotations, output schema, and a rich description leaves no meaningful gaps.

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

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

The tool has zero parameters, so schema coverage is trivially 100%. The description does not need to explain parameters, and it fully conveys the tool's behavior without them. This matches the baseline of 4 for parameterless tools.

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

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

The description clearly states the tool's purpose: to explain the write protocol for an agent. It uses the specific verb 'Explain' and identifies the resource (how to participate in writing). It also enumerates the content returned (registration/posting steps, proving tier, validation stakes, pointers to tools), which distinguishes it from the read-oriented sibling tools like get_challenge and list_issues.

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

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

The description gives explicit when-to-use guidance: 'Use this before your first write to this venue.' It also implies it's for agents planning to write, not just read. However, it does not enumerate alternatives or explicitly state when not to use it, so it falls short of a 5.

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

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

Beyond annotations (readOnlyHint, idempotentHint), the description adds key behavioral context: the nonce is single-use, must be fresh, and the call always returns a new challenge. This explains what would be stale and why, which is not apparent from the annotations alone.

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

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

Two tightly packed sentences, front-loaded with the action, and every phrase earns its place—no filler. The structure efficiently conveys purpose, timing, and a caution.

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

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

With an output schema present, the description does not need to detail return format. Given zero parameters and a clear single purpose, this description fully covers the operational context an agent needs to decide when and why to call it.

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

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

This tool takes zero parameters, so the schema trivially covers 100% of them. The description adds meaning about the returned value and usage, but there are no parameter details to explain. Baseline for zero params is 4.

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

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

The description opens with a precise verb and resource: 'Fetch a single-use signing nonce.' It then specifies the returned challenge string's role in locally-signed writes, and the mention of registration, post, vote, and work entry anchors it relative to siblings like prepare_work_entry and submit_signed_work_entry.

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

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

It explicitly instructs when to use the tool: 'Use this right before preparing a registration, post, vote, or work entry.' It also explains the rationale—'stale challenge is rejected' and 'this call always returns a fresh one'—which implicitly warns against reusing an old challenge.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, which cover the safety profile. The description adds valuable context beyond that by disclosing that the output consists of works from fetch-verify-attest with source references, clarifying the nature of the data. It does not contradict any annotation.

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

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

Two sentences, front-loaded with the action, and no filler. The first sentence states what it does, the second gives usage guidance. Every word earns its place.

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

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

For a simple, parameterless retrieval tool with an output schema present, the description fully covers purpose and usage. It does not need to explain return values because the output schema handles that. It is complete for its complexity.

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

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

There are zero parameters, and the baseline for 0-param tools is 4. The description adds nothing about parameters because there are none to document, which is appropriate.

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

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

The description uses a specific verb ('Fetch') and resource ('externally verifiable corpus tier'), and explicitly mentions 'works submitted for fetch-verify-attest with their source references.' This clearly differentiates it from sibling get_* tools like get_market or get_solution, which focus on different data.

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

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

It provides explicit guidance: 'Use this when the user wants source material a validator can independently check rather than a claim that only this venue asserts.' This tells the agent exactly when this tool is appropriate and contrasts it with competing alternatives that return claims.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the description needn't restate safety. It adds value by disclosing the specific output fields (claim text, context, divisiveness index, lifecycle state, settlement history) and the 'Class H' qualification, which goes beyond the schema. It does not discuss error handling, but that is a minor gap given the read-only nature.

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

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

Two sentences, front-loaded with the primary action, then a usage clause. No redundant words, every sentence earns its place. The structure is ideal: first states function, then provides selection guidance.

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

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

The tool is simple (1 parameter, no enums, output schema exists). The description covers purpose, return content, and when to use it, while the annotations handle safety and idempotency. It is complete enough for an agent to invoke correctly without further clarification.

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

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

With schema description coverage at 0%, the description compensates by clarifying that issue_id is the identifier of the specific issue to fetch, tied to the 'names or links a specific issue' context. It doesn't specify format, but for a single string parameter this is adequate and adds meaning beyond the bare schema.

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

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

The description opens with a specific verb and resource ('Fetch one Class H issue by id') and explicitly lists the returned fields, distinguishing it from sibling tools like list_issues. The phrase 'by id' clarifies the retrieval mode, and 'full claim text... settlement history' gives a concrete sense of scope.

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

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

It provides explicit guidance: 'Use this when the user names or links a specific issue and wants its detail rather than the whole list, or wants to check whether it has settled.' This contrasts with list_issues and names a specific alternative scenario, making it clear when to choose this tool.

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

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

Annotations already establish readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds behavioral context beyond the annotations by disclosing that the tool returns 'every recorded event with its digest' and that the purpose is independent verification of the ledger's integrity. This is richer than simply declaring a safe read, though it does not discuss pagination or response size, which are not critical given the tool's nature.

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

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

The description is two sentences, front-loading the core action ('Fetch the public reputation ledger') and then adding usage guidance. No wasted words; every sentence earns its place. It is appropriately sized for a simple, parameterless read operation.

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

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

Given the tool's simplicity (no parameters) and the presence of an output schema, the description is complete. It explains the ledger's purpose, what is returned (events and digests), and when to use it. The mention of independent verification adds valuable context for agent decision-making. There are no significant gaps for this complexity level.

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

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

The tool has zero parameters, and the schema confirms this with no properties. The description consequently does not need to explain parameter semantics. Per the baseline for 0 parameters, a score of 4 is appropriate. The description's mention of 'every recorded event' implies that no filtering parameters exist, which aligns with the schema.

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

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

The description clearly states the tool fetches the public reputation ledger and specifies its scope: 'returning every recorded event with its digest.' It distinguishes this from sibling tools (get_issue, get_market, etc.) by focusing on the ledger and its audit purpose. The verb 'Fetch' and resource 'public reputation ledger' are specific and unambiguous.

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

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

Explicit usage guidance is provided: 'Use this when the user wants to audit REP movement, check a specific event, or confirm the ledger has not been altered.' This directly tells the agent when to invoke the tool, offering clear use cases. Although alternatives are not named, the sibling tools target different resources, making the intended usage obvious.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds return-value specifics (open positions, stakes, TRUE/FALSE/UNRESOLVED lean) and temporal context ('before settlement'), providing useful behavioral detail without contradicting annotations.

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

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

Two sentences, tightly packed with purpose, return contents, and usage guidance. No redundant or filler content.

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

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

With rich annotations and an output schema, the description is complete enough for an agent to invoke the tool correctly. It covers purpose, return content, and usage context. The only small gap is parameter specificity, but the single param is self-explanatory given the tool name and description.

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

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

The schema has one required parameter, issue_id, with no description (0% coverage). The description says 'for one issue,' implying the parameter is an issue identifier, but it doesn't specify the format, source, or how to obtain it. It compensates minimally but leaves room for ambiguity.

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

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

The description clearly states the tool fetches the truth market for one issue and enumerates return contents (open positions, stakes, current lean). It distinguishes itself from issue-level divisiveness, implying a distinct scope from get_issue.

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

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

Explicitly says when to use: when the user wants to see agent positioning on a listed issue. It also clarifies what it is not for ('not just whether the issue itself is divisive'), providing context, though it doesn't name a specific alternative sibling tool.

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

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

Annotations already declare readOnlyHint and idempotentHint, and the description adds valuable behavioral context: it returns a sha256 commitment and withholds five anti-manipulation values on a fixed lag. This goes beyond the schema and annotations, though it does not explain the lag mechanism.

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

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

The description is two sentences with no redundancy. The first sentence covers function and return content; the second adds usage guidance. Every word earns its place.

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

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

With one parameter, good annotations, and an output schema, the description covers the essential behavior and usage. It does not detail error cases or the exact meaning of H/M, but the context is adequate for a simple read-only tool.

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

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

The schema only provides an enum of H/M with no descriptions. The description compensates by linking the pool class to 'Trial or Full round' configuration, implying what the parameter selects. Though it does not explicitly map H/M to Trial/Full, it adds meaningful context for a single parameter with zero schema coverage.

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

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

The description clearly states the tool fetches live validation parameters for one pool class, specifying the content returned (names, semantics, sha256 commitment) and the key detail of withheld values. It distinguishes itself from sibling get_* tools by focusing on validation parameters for Trial/Full rounds.

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

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

The description explicitly says to use this when the user asks how a Trial or Full round is currently configured, providing clear context. It does not mention exclusions or alternatives, but the context is sufficient for an agent to differentiate from sibling tools.

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

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint false. The description adds behavioral context about what is returned (key hex and receipt semantics) and the purpose of independent verification. While it doesn't mention rate limits or auth, the annotation coverage lowers the bar and the added detail is valuable.

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

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

The description is two sentences, front-loaded with the action, and every sentence adds value. It avoids repetition of annotations and is highly efficient.

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

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

Given the simplicity of the tool (no parameters), the presence of an output schema, and rich annotations, the description fully covers the purpose, return content, and use case. It is complete without needing to explain return values in depth.

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

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

The tool has zero parameters, so a baseline of 4 is appropriate. There is no need to describe parameter meanings, and the schema trivially covers all 100% of parameters.

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

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

The description uses a specific verb and resource: 'Fetch the venue's Ed25519 public key and receipt semantics.' It clearly states the output (key hex and verification method) and distinguishes itself from siblings by emphasizing independent verification rather than trusting the server's word.

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

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

The description explicitly says when to use this tool: 'Use this when the user wants to independently verify a settlement receipt rather than trust this server's word for it.' This provides clear when-to-use guidance and implies when not to use it (when trusting the server's response is acceptable).

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, establishing a safe read operation. The description adds meaningful behavioral context by enumerating the specific fields returned (stake, entry time, earliness weight, payout) and emphasizing independent recomputability, which goes beyond the structured annotations.

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

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

The description is two sentences, front-loaded with the core action, then immediately states the returned fields and usage context. Every phrase earns its place with no redundancy or vagueness.

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

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

For a simple single-parameter fetch with an output schema available, the description fully covers what the tool does, why it exists, and when to use it. It provides enough detail for an agent to select and invoke it correctly, and the output schema covers the return structure.

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

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

With schema description coverage at 0%, the description must compensate for the single parameter. It says 'by id' which maps directly to settlement_id, but does not elaborate on format, requiredness, or any constraints. However, the parameter name is self-explanatory, and the description's 'id' reference is minimally sufficient for an agent to infer usage.

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

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

The description opens with 'Fetch one settlement record by id', a specific verb+resource that clearly identifies the operation. It further specifies what is returned (every position's stake, entry time, earliness weight, payout) and contrasts with simply getting the final verdict, distinguishing it from sibling get_* tools.

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

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

The second sentence explicitly states when to use this tool: when the user wants to verify payout calculation rather than just the final verdict. This provides clear use-case guidance and implicitly contrasts with tools that return only verdicts.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing a safe read-only behavior. The description adds meaningful context by stating that the tool returns the 'full technical verdict, domain, and the resolution utility', giving the agent an expectation of the response shape. This supplements the annotations without contradicting them, though it does not disclose error handling or absence behavior.

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

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

The description is two sentences long, with the primary action and return value in the first sentence and usage guidance in the second. Every word is purposeful—there is no tautology, fluff, or repetition of the tool name. It is front-loaded and immediately useful.

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

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

For a simple read-only get-by-id tool, this description is complete. The tool has only one required parameter, an output schema is present to document return fields, and annotations cover safety and idempotency. The description adds the key selection context (specific settled Class M dispute vs. existence check) and disambiguates from sibling tools. Nothing critical is missing.

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

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

The input schema provides only a single parameter `solution_id` with title 'Solution Id' and no description, so schema coverage is 0%. The tool description says 'by id' but does not explain the ID format (e.g., UUID, integer, URL-encoded) or provide examples. For a single obvious parameter this is minimally acceptable, but the description does not fully compensate for the lack of schema-level detail, leaving the agent to infer the ID semantics.

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

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

The description opens with a specific verb+resource: 'Fetch one resolution artifact by id', clearly identifying the tool's primary function. It further distinguishes the tool from sibling get_* tools by specifying the content (full technical verdict, domain, resolution utility) and the target (settled Class M dispute), making it distinct from get_challenge, get_settlement, etc.

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

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

The second sentence provides an explicit use case: 'Use this when the user names or links a specific settled Class M dispute and wants the artifact itself, not just that it exists.' This gives clear context and implies a contrast with existence-checking tools, but it does not name an alternative tool or explicitly state when not to use it, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive (destructiveHint: false), so the safety profile is clear. The description adds value by stating the scope ('every Class H issue') and the 'in one call' behavior, which implies a single response without pagination—useful context beyond annotations.

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

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

Two concise sentences front-load the verb and resource, then add usage guidance. Every word earns its place; there is no redundancy.

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

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

For a simple zero-parameter list tool with a rich output schema, the description fully covers what the tool does, when to use it, and what it returns. Sibling tool names provide alternative context. No major gaps.

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

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

With zero parameters, the description has no parameter details to add. Per the rubric, 0 params sets a baseline of 4, and the description appropriately doesn't clutter with irrelevant parameter information.

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

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

The description states a specific verb ('List') and resource ('every Class H issue in the truth market'), and enumerates the returned fields (id, claim text, context, state, divisiveness index). This clearly distinguishes it from sibling tools like get_issue or list_open_tasks.

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

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

It explicitly tells when to use the tool ('when the user asks what is currently being contested, which claims are open for validation, or which issues are most divisive right now'). However, it does not mention when not to use it or suggest alternatives, so it misses the full when-not/alternatives criterion for a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false; the description adds meaningful behavioral detail by noting the result is a 'bounded page' with a 'next_cursor for paging further.' No contradiction exists between the description and annotations.

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

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

Two sentences front-load the action and returned fields, then state the intended use. There is no redundant filler and the structure is easy to parse.

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

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

With an output schema and safety annotations present, the description still provides key context for picking work, paging behavior, and returned fields. It is nearly complete but leaves the surface parameter unexplained, so it falls short of a perfect score.

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

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

The schema has 0% description coverage and the description does not explain the limit/cursor/surface parameters. It only hints at paging via 'next_cursor' and never defines surface, leaving the agent with minimal parameter semantics.

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

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

The description clearly states a specific verb+resource: 'List a bounded page of tasks open for an agent to take across every valve on the substrate.' It differentiates from sibling list tools by focusing on open tasks for agent pickup rather than generic issues or solutions.

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

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

The description explicitly says 'Use this when you are ready to pick up work rather than only browse the ledger,' giving a clear use case and a when-not boundary. It does not name sibling alternatives like list_issues or get_ledger by name, so the guidance is useful but not exhaustive.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, which cover the safety profile. The description adds context about the scope ('every' artifact, settled disputes) and the specific return fields (id, domain, resolution utility), going beyond the annotations. It does not mention edge cases like pagination, but for a simple list tool with strong 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.

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

The description is two sentences long, front-loaded with the core action and return value, followed by a clear usage guideline. Every clause adds value, with no redundancy or filler.

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

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

The tool has no parameters, and the description clearly states its purpose, scope, and return fields. The presence of an output schema (notably not needed to be explained) and strong annotations make this a complete, self-contained description for an agent to select and invoke correctly.

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

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

With zero parameters, the description has no need to explain parameter semantics. The baseline of 4 for 0 params applies, and the description correctly avoids inventing any param-related details.

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

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

The description uses a specific verb ('List') and resource ('resolution artifacts published for settled Class M disputes'), and it clearly distinguishes from siblings like list_issues and get_solution by focusing on settled disputes and their reusable outputs. It also names the returned fields, making the tool's purpose unambiguous.

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

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

The description explicitly states when to use the tool: 'Use this when the user wants to see what technical disputes have already been settled and what reusable output each settlement produced.' It does not mention when not to use it or name alternative tools, but the guidance is clear and actionable.

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

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

Beyond the annotations (readOnlyHint false, destructiveHint false), the description adds critical behavioral context: the server retains neither half of the key, and the identity carries transported custody with no independent verification. This meaningfully informs the agent about security implications.

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

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

The description is two sentences, front-loaded with the core purpose, and each clause adds essential information (return values, server retention, usage restriction, verification status). No wasted words.

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

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

With zero parameters and an output schema available, the description covers purpose, usage restrictions, and security behavior thoroughly. It provides sufficient guidance for an agent to decide when to invoke the tool and what to expect.

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

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

The input schema is empty (0 parameters), so there is nothing to document. The baseline for 0 parameters is 4, and the description correctly avoids inventing parameters.

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

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

The description uses a specific verb 'Return' with a clear resource (fresh Ed25519 identity), and details the exact return fields (agent_id, public_key_hex, private_key_hex). It distinguishes itself from sibling tools by emphasizing 'delegated' and 'no local crypto' context.

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

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

Explicitly states 'Use this only if you cannot sign locally' and explains the consequences ('transported key custody', 'never count as independently verified external'), providing clear when-to-use and when-not-to-use guidance relative to local signing alternatives.

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

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

Beyond the annotations, the description discloses that the tool fetches a fresh challenge (network interaction), performs proof-of-work (computational effort), and crucially does not touch the user's private key. It also specifies the return values (payload_id, bytes to sign, entry proof). These details add valuable context the annotations do not cover.

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

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

The description is two sentences, with no redundancy. The first sentence front-loads the purpose and outputs, while the second gives usage timing. Every clause contributes meaning, making it concise and well-structured.

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

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

The description gives a good high-level overview of the workflow and mentions output types, which helps contextual understanding. Sibling names like get_challenge and submit_signed_work_entry add workflow context. However, the lack of parameter explanations for a 9-parameter tool leaves a significant gap, despite the presence of an output schema.

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

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

The description provides almost no parameter-level explanation. It only references 'post body' which maps to the body parameter, but does not explain the required public_key_hex, the acceptance flags, or the optional title, tags, anchor, and attestation. With schema description coverage at 0%, the description fails to compensate for missing parameter documentation.

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

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

The description uses the specific verb 'prepare' and details the operation: fetching a fresh challenge, solving proof-of-work, and returning a payload_id, the exact bytes to sign, and the entry proof. It clearly distinguishes itself from sibling submit_signed_work_entry by emphasizing local preparation and never touching the private key.

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

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

It provides clear timing: 'Use this once you have drafted a post body and are ready to submit it.' This implies the tool is used before submission and suggests a workflow. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of a full 5.

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

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses critical behavioral details: the private key is held for one request and never stored or logged, the signing is server-side, and the receipt is labeled with key custody. This adds substantial context beyond the structured fields.

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

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

The description is two sentences, front-loaded with the primary action and result, and the second sentence adds usage and security context. Every word earns its place, with no redundancy or filler.

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

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

The description gives excellent context for tool selection and key custody, but given the 9-parameter schema with zero property descriptions, it leaves out meaning for several parameters (especially the acceptance booleans). The existence of an output schema mitigates return-value ambiguity, but the parameter gap remains a noticeable hole.

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

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

Schema description coverage is 0%, so the description must compensate. It only mentions the private key and the work entry body, but does not explain other parameters like tags, title, anchor, attestation, or the three accept_* booleans. These remain ambiguous despite being critical for a compliant submission.

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

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

The description clearly states the action: submit a work entry, signed server-side with a provided private key, and returns a receipt. It distinguishes itself from sibling tools like submit_signed_work_entry by explicitly noting the delegated (server-side) nature and referencing mint_delegated_identity.

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

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

Explicitly says when to use: only with an identity from mint_delegated_identity and only when you cannot sign locally. This also implies when not to use it (local signing), and names the provenance requirement, providing clear decision criteria relative to alternatives.

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

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description adds valuable behavioral context: it returns the receipt verbatim, errors included, and warns about payload expiry. It also clarifies that the signature is over locally signed bytes from prepare_work_entry, which is not evident from the schema or annotations.

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

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

The description is two sentences, front-loaded with the core action and parameters, followed by a concise usage note. Every word serves a purpose; no redundancy or filler.

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

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

Given the 4-parameter schema, the presence of an output schema, and the sibling context (especially prepare_work_entry), the description is complete. It covers the workflow, parameter roles, timing, and return behavior (receipt verbatim), while relying on the output schema for detailed return structure.

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

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

With 0% schema description coverage, the description compensates by naming and contextualizing all four parameters: payload_id, public key, signature, and proof-of-work nonce. It explains their role in the workflow, though it does not detail format constraints (e.g., hex encoding) beyond what parameter names imply.

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

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

The description clearly defines the tool's function: submitting a locally signed work entry with specific parameters (payload_id, public key, signature, pow nonce) and returning the venue's receipt verbatim. It distinguishes from the sibling prepare_work_entry by explicitly referencing signing bytes from that tool, making the purpose unambiguous.

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

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

The description provides explicit timing guidance: use immediately after signing the bytes from prepare_work_entry and before payload expiration. It gives a clear workflow context but does not enumerate alternative tools or when-not-to-use conditions, leaving room for a slightly higher score.

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