Server Quality Checklist

Tool Scores

• list_submissionsC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of disclosing behavioral traits. It does not explicitly state that this is a read-only operation, whether ownership is enforced, or what the response format will be. 'Track and present' is ambiguous and could imply stateful behavior, which is not clarified.

  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, compact and free of fluff. It communicates the core action and context efficiently. The phrase 'Track and present' is slightly redundant with 'list,' but it's not harmful. It is appropriately sized for a simple tool.

  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 no annotations, the description must supply context about the response and side effects. It does not describe the return structure, pagination, or any ownership authorization details. For a simple tool, it provides only the most basic purpose, lacking important behavioral context that an agent needs to use 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?

  The schema provides only a string taskId with no description, and schema description coverage is 0%. The description compensates by indicating the taskId refers to a task 'you posted' and that submissions are listed for it. However, it doesn't provide details on the format, source, or constraints beyond what the schema already states, leaving some ambiguity.

  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 indicates the tool lists submissions for a specific task ('Track and present submissions for a task you posted'). The verb 'list' in the title reinforces this. It adds context that the task must be one you posted, which distinguishes from general submission viewing, but it doesn't explicitly differentiate from sibling tools like search_tasks or get_task.

  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 explicit guidance on when to use this tool versus alternatives. The phrase 'for review before awarding' hints at a use case, but it doesn't state when not to use it or mention any prerequisites. Sibling tools like award_submissions or reject_submission are not referenced.

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

• get_requester_statsB
  3.3/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of explaining behavior. It only states the high-level metric (created vs. awarded) but does not disclose whether the operation is read-only, what the exact return format is, or any potential side effects or prerequisites. The absence of an output schema amplifies this gap.

  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 at two sentences. The first sentence states the core function, and the second adds valuable usage context. Every word earns its place, with no fluff or repetition.

  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 tool is simple (one parameter, no output schema), but the description leaves several gaps: it doesn't specify the return shape, whether the stats are for a given address, or any time scope. It provides enough to understand the purpose but not enough to fully anticipate the tool's behavior or output format.

  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?

  The schema has one parameter, 'address', with no description, and schema description coverage is 0%. The description never explicitly maps the address parameter to the requester, nor explains what values are valid. The tool name and context imply the address is the requester's, but the description fails to compensate for the lack of schema-level documentation.

  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 what the tool does: it reports the count of tasks created vs. actually awarded by a requester. This distinguishes it from sibling tools that handle task search, creation, or award actions. However, it does not explicitly use a verb like 'get' or name the specific resource (requester address) beyond the tool name, so it's not a perfect 5.

  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 clear, actionable usage guidance: use it before trusting a requester's task, and before using your own requester history as a signal. This implies when to use the tool but does not explicitly mention alternatives or exclusions, so it misses the top score.

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

• whoamiA
  3.6/5.0
  Behavior4/5

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

  The description explicitly states 'Read-only', which is a key behavioral trait. Since no annotations are provided, the description carries the burden of disclosing side effects; this is adequately handled for a simple whoami-style tool.

  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 extremely concise, with zero filler. However, it is phrased as a noun phrase ('Which wallet...') rather than a complete sentence, which slightly reduces readability but not comprehension.

  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 parameters and no output schema, the description sufficiently explains what it does and its read-only nature. The title covers the return value (the address), so the overall context is complete enough.

  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?

  The tool has no parameters, so the description cannot add parameter-specific meaning. The baseline for 0 parameters is 4, and the description appropriately focuses on the tool's purpose.

  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 showing which wallet will sign write actions, and the title explicitly says 'Show the signing wallet address'. This distinguishes it from siblings like get_wallet_balance (balance vs identity) and task-related tools.

  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 such as get_wallet_balance. It implies relevance to write actions but doesn't state when it should be preferred or what scenarios it excludes.

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

• preview_reject_submissionA
  3.8/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden, and it does disclose a key behavioral trait: 'No network write.' This clearly indicates the tool is non-mutating and safe. However, it doesn't explain what the confirmation token is used for, whether it is returned, or whether any validation occurs, leaving some ambiguity. The description adds useful context beyond the tautological title.

  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 exceptionally concise: two sentences, each earning its place. It front-loads the core action in the first sentence and adds the critical safety nuance in the second. There is zero waste, making it easy to parse quickly.

  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 simple preview tool with no output schema, the description covers the essential no-write guarantee, but it omits what the confirmation token is or what the tool returns. It also doesn't specify any conditions or errors. Given the absence of annotations and output schema, the description is adequate but not fully complete for an agent to know what to expect after invocation.

  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 33% (only 'reason' is described). The description does not mention any parameters to compensate for the undocumented 'taskId' and 'worker'. While parameter names are self-explanatory, the low schema coverage means the description should provide additional context, but it remains silent, leaving the agent to infer their meanings from the tool name and siblings.

  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 action: 'Mints a confirmation token for reject_submission.' This specific verb (mints) and resource (confirmation token) directly distinguish it from the sibling reject_submission, which actually performs the rejection. The title reinforces the purpose as a preview with no spend.

  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?

  Usage is implied through 'No network write' and the title's '(no spend)', suggesting a dry-run before using reject_submission. However, there is no explicit statement like 'Use this to preview before rejecting' or mention of when not to use it. The presence of sibling tools like preview_create_task suggests a family of previews, but the description doesn't explicitly guide the agent to prefer this for validation.

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

• get_wallet_balanceA
  3.9/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It explicitly discloses 'Read-only' (a key safety trait) and applies to 'any' address, implying no auth restrictions. However, it does not discuss error behavior, rate limits, or return details beyond the balance itself.

  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 short, front-loaded sentences deliver the essential purpose and a usage hint without any redundant words. Excellent structure.

  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 one parameter, the description covers purpose, safety, and usage context. Lacks output format and error details, but these are relatively predictable from the tool name. The explicit 'read-only' compensates for missing annotations.

  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?

  The schema has only 'address' with minLength 1 and 0% description coverage. The description adds 'Base wallet address' but does not specify the expected format (e.g., 0x prefix, network specifics). More detail is needed to fully compensate for the missing schema description.

  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 'Read-only USDC balance for any Base wallet address', which clearly describes the action (get balance), the resource (USDC), and the scope (Base wallet). This distinguishes it from sibling task-related 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 instruction 'Check this before quoting a spend' provides clear contextual guidance on when to use the tool. It does not explicitly mention alternatives or exclusions, but the context is sufficient for a distinct read-only tool.

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

• search_tasksA
  3.9/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the burden of disclosing behavioral traits. It says 'Read-only, no wallet needed, cannot spend anything,' which covers the key safety aspect. However, it does not describe pagination, rate limits, or return format, leaving some behavioral details undisclosed.

  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 two sentences with no filler. The first sentence states the core function, and the second adds relevant usage context. Every phrase earns its place.

  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's complexity (10 parameters, no output schema, no annotations), the description is too sparse. It covers purpose and safety but omits filtering guidance, pagination behavior, and return value information, leaving significant gaps for effective usage.

  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 10% (minReward), and the tool description provides no parameter details. With 10 parameters, including filters like mode, status, tags, and sort, the description fails to help users understand how to construct a valid query, so it doesn't compensate for 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 uses a specific verb ('browse') and names the resource ('TaskMarket work'), clearly distinguishing it from the sibling create_task. It also states that the tool is read-only and non-spending, which further clarifies its role.

  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 explicitly advises using this tool before create_task to evaluate whether delegating to a human/agent worker market is a better fit, giving a concrete usage scenario. It also includes prerequisites like 'no wallet needed' and 'cannot spend anything,' but does not mention alternative search tools 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.

• preview_award_submissionsA
  4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of explaining side effects. It clearly states that no network write occurs, no funds move, and that it validates the sum constraint before minting a token. However, it does not describe failure behavior (e.g., what happens if the sum is incorrect) or the exact nature/use of the confirmation token, leaving some gaps.

  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 concise, two sentences, with the most critical information (validation rule and no-spend behavior) front-loaded. Every sentence adds value, and there is no fluff or repetition of schema details.

  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 preview tool with no annotations or output schema, the description covers the core function and side effects, but it omits important contextual details: how the minted token is used with award_submissions, whether this tool must be called before the actual award, and what happens on validation failure. The flow between preview_award_submissions and award_submissions is not fully explained.

  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 coverage is only 50% (winners has a description, taskId does not). The description restates the winners sum constraint already present in the schema but adds no new information about either parameter. In particular, taskId's meaning is left unexplained, and the description does not 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?

  The description clearly states the tool's function: validating the winner list (shares sum to 10000) and minting a confirmation token for award_submissions. It also distinguishes itself from the actual award_submissions tool by explicitly noting 'No network write, no funds move.' This is a specific verb+resource combination with clear sibling differentiation.

  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 title 'Preview awarding submissions' and the description's 'for award_submissions' strongly imply this tool is used as a safe precursor to the actual award_submissions. However, it does not explicitly state when to use it versus award_submissions or mention any exclusions, so it falls short of a perfect score.

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

• reject_submissionA
  4/5.0
  Behavior4/5

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

  With no annotations, the description discloses key behaviors: a small relay fee is incurred, no reward is paid, and a prior preview call is required. This is informative but omits permissions, reversibility, and error scenarios.

  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 concise sentences with no filler. The action, outcome, and prerequisite are front-loaded and clearly highlighted.

  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?

  Covers the core effect and prerequisite, but with no output schema or annotations, it does not describe return values, error conditions, or reversibility. Given the mutation type and four parameters, some gaps remain.

  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 just 25% (only 'reason' has a description). The tool description adds meaning for confirmationToken by explaining its origin, but leaves taskId and worker undocumented, failing to compensate for the low 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?

  Description clearly states 'Marks one worker's submission rejected (small relay fee, no reward paid).' This identifies the exact action and resource, and distinguishes it from the sibling preview_reject_submission by noting the actual rejection and its consequences.

  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?

  Explicitly requires a confirmationToken from a prior preview_reject_submission call, which directs the agent to use preview first. It also specifies 'one worker's submission,' limiting scope, though it does not explicitly mention alternatives like award tools.

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

• award_submissionsA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden of disclosing behavioral traits. It discloses the financial nature ('Pays out escrowed reward'), the prerequisite confirmationToken, and the requirement for user review. It does not explicitly state that the action is irreversible or that funds are permanently transferred, but the language strongly implies finality.

  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 two sentences, front-loaded with the core action, followed by a critical safety prerequisite. Every sentence earns its place; no fluff or redundant details.

  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 tool is a financial payout operation with 3 required parameters and no output schema. The description covers the key workflow (preview → user review → confirm) but does not explicitly address irreversibility or failure modes (e.g., token mismatch, partial winner allocations). Overall, it is sufficient for an agent to invoke correctly but could be more explicit about the finality of the action.

  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 only 33% (only the winners array has a description). The tool description adds crucial meaning for confirmationToken (from a prior preview call) and explains that winners receive the reward. However, it does not explain the semantics of shareBps beyond the sum-to-10000 constraint already in the schema, leaving a gap for agents to infer.

  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 primary action ('Pays out escrowed reward to the named winners') with a specific verb and resource. It distinguishes itself from the sibling preview_award_submissions by emphasizing the required confirmation token from the prior preview call.

  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 usage context: it must only be called after a prior preview_award_submissions and after the user has reviewed list_submissions. However, it does not explicitly name the alternative (preview_award_submissions) as the 'preview' step, though the token requirement implies it.

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

• create_taskA
  4.2/5.0
  Behavior4/5

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

  Discloses real money movement, refusal on parameter mismatch before any spend, and daily spending caps. Given no annotations, this is strong behavioral context, though it doesn't mention response format or permission requirements.

  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 sentences, all informative: core action, critical prerequisite, and safety cap. No redundancy or filler.

  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?

  Captures the essential safety and workflow context for a financial transaction tool. Missing a note on return value and an explicit 'call preview_create_task first' instruction, but the implication is strong enough for most use cases.

  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 describes only 2/7 parameters; the description adds meaning to confirmationToken and rewardUsdc but leaves mode, tags, durationHours, and description without explanation. With low schema coverage, more param guidance would be expected.

  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?

  Clearly states the tool's function: escrows rewardUsdc USDC and posts a new task. The mention of confirmationToken explicitly distinguishes it from preview_create_task, which prepares the preview.

  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 that a confirmationToken from a prior identical preview_create_task call is required, implying you must call preview_create_task first. This effectively tells the agent when to use this tool vs the preview sibling, though it doesn't elaborate on other alternative tools.

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

• get_taskA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden. It discloses that the record is 'live' and 'authoritative,' implying read-only behavior and contrasting with stale board scans. It doesn't mention error handling or whether the task is returned in full, but for a simple fetch tool, 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.

  Conciseness5/5

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

  The description is two sentences, with the first stating purpose and the second providing a critical usage guideline. No filler words; every sentence serves a function.

  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 provides the essential information for a simple single-parameter fetch tool: what it fetches, when to use it, and why it's needed (staleness). It doesn't specify return format or error responses, but given the lack of output schema and the tool's simplicity, this is reasonably complete.

  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 description mentions 'by id,' which ties the taskId parameter to its purpose, but adds little beyond the schema's existing type and minLength constraints. With 0% schema description coverage, the description only minimally compensates, though the parameter name is self-explanatory.

  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 the specific verb 'Fetch' and identifies the resource as 'the live, authoritative record for one task by id.' It clearly distinguishes from sibling tools like search_tasks by focusing on a single task by ID.

  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 explicitly instructs to 'Always re-fetch this immediately before acting on a task' and explains why: 'a board scan can be stale.' However, it doesn't explicitly name alternatives like search_tasks or state when not to use this tool, 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.

• preview_create_taskA
  4.3/5.0
  Behavior5/5

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

  With no annotations provided, the description fully carries the behavioral transparency burden. It explicitly discloses the tool's non-mutating nature: 'Calls no network write and moves no funds.' It also reveals the return values (costUsdc, expiresAt) and the token's short-lived nature, giving the agent a clear behavioral profile beyond 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 three sentences, each earning its place: purpose, behavioral safety, and usage guidance. It is front-loaded with the primary action and maintains high information density without redundancy.

  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 essential context for a preview tool: side-effect-freeness, return values, and the follow-up step (calling create_task). It is slightly incomplete in not mentioning error cases, authentication, or prerequisites, but given the tool's simplicity and the explicit behavioral details, it is sufficiently complete for an agent to invoke correctly.

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

  Parameters2/5

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

  Schema description coverage is only 33% (2 of 6 params documented). The description does not explain any of the input parameters, merely referring to 'the same parameters' as create_task. It does not compensate for the low coverage, leaving the agent to infer parameter meanings from sibling tool context or prior knowledge.

  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: 'Compute the cost and mint a short-lived confirmation token for create_task.' This specific verb+resource combination distinguishes it from sibling tools like create_task, preview_award_submissions, etc. It also clarifies the tool's input/output relationship to create_task.

  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 explicitly instructs when to use the tool: 'Show the returned costUsdc and expiresAt to the user before calling create_task with the same parameters plus the returned confirmationToken.' This gives a clear usage flow and context. It does not explicitly exclude alternatives, but the guidance is strong enough to direct the agent appropriately.

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