Server Quality Checklist

Tool Scores

• list_jobsB
  3.2/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 full responsibility for behavioral disclosure. It adds 'recent' and 'durable' but does not explain what 'recent' means (e.g., time window, default limit) or whether the list is sorted. It also omits the limit default of 50 and the queue filter, which are visible in the schema but not elaborated in the description. This leaves significant behavioral ambiguity.

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

  Conciseness5/5

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

  The description is a single concise sentence with no wasted words. It front-loads the core purpose and includes the key filtering capability. This is appropriately sized for the tool's simple nature.

  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 has an output schema and only 4 optional, self-explanatory parameters, so the description need not detail return values. However, it fails to mention the queue filter and the limit parameter, and the phrase 'recent' is vague. Given the low complexity, this is a minimally adequate description with clear gaps but not seriously deficient.

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

  Parameters2/5

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

  Schema description coverage is 0% and the description mentions only two of four parameters (state and host) as filters. It does not mention 'queue' as a filter or explain 'limit' (number of results). While the parameter names are self-explanatory, the description adds minimal value and does not fully compensate for the lack of schema descriptions, especially for queue and limit.

  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 'List recent durable jobs, optionally filtered by state or host' clearly states the operation (list), the resource (durable jobs), and the filtering capability. This distinguishes it from sibling tools like get_job_status (single job) and get_job_logs, which serve different purposes.

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

  Usage Guidelines2/5

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

  The description provides no explicit guidance on when to use this tool versus alternatives like get_job_status or list_queues. It only states what the tool does, leaving the agent to infer appropriate usage from the tool name and siblings. Without exclusions or alternative recommendations, this is minimal guidance.

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

• cancel_jobA
  3.6/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. It discloses that the tool cancels durable jobs, but does not explain cancellation semantics, what happens to the job, the effect of grace_seconds, or potential side effects. This is a significant gap for a mutating operation.

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

  Conciseness5/5

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

  The description is a single sentence with no filler. It front-loads the action and resource, and every word adds substantive value.

  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?

  The description is too terse for a mutating tool with an undocumented parameter. It omits grace_seconds semantics and cancellation behavior, which are essential for correct use. The output schema exists but does not compensate for these gaps.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description must compensate. It clarifies that job_id identifies the durable job, but it completely ignores grace_seconds, leaving that parameter's purpose unexplained. Partial semantic 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 clearly states the action (Cancel) and the resource (a durable job), and adds the qualifier 'without relying on a client-side process handle' which distinguishes it from siblings like run_job or get_job_status. It is 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.

  Usage Guidelines4/5

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

  The phrase 'without relying on a client-side process handle' implies when to use this tool—when you need to cancel a durable job by ID rather than a process handle. However, it does not explicitly list alternatives or exclusions, so it falls short of full guidance.

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

• list_queuesA
  3.9/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It clearly implies a read-only operation via the verb 'list', but it does not explicitly state that it makes no modifications, nor does it mention any permissions, pagination, or real-time guarantees. It provides the basic function but lacks additional behavioral context beyond what the name itself implies.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that conveys the essential information without redundancy. Every word earns its place, making it highly concise and well-structured.

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

  Completeness5/5

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

  Given the tool's simplicity (no parameters) and the presence of an output schema (as indicated in context signals), the description sufficiently covers what the agent needs to know. It accurately describes the scope ('named queues') and the specific data returned (queued/active counts), making it complete for a basic list operation.

  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 zero parameters, and the schema coverage is 100% (vacuously). Per the rubric, 0 params gives a baseline of 4. The description adds no parameter-specific details, but none are needed since no inputs exist.

  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: 'List named queues and their current queued/active job counts.' This is a specific verb (list) + resource (named queues) + expected output (queued/active counts), which distinguishes it from sibling tools like list_jobs or create_queue.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives. It does not mention that this is for viewing queue-level status, nor does it suggest using list_jobs or get_job_status for job-level details. The description provides no context to help the agent decide between this and sibling tools.

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

• runA
  4/5.0
  Behavior5/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 discloses key behaviors: every command is a durable Job from launch, inline-timeout commands return a bound result, longer or queued work returns a detached job handle without cancellation, and the queue defaults to an operator-configured value. These details go beyond what the schema or annotations provide and are genuinely valuable.

  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 front-loaded with a crisp purpose sentence, followed by a compact paragraph on execution behavior and a clear list of alternative-tool guidance. Every sentence adds value, and no unnecessary fluff is present. Slightly long given the 15 parameters remain undocumented, but the text itself is efficient.

  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?

  The description fully addresses the execution model, job lifecycle, and selection logic. However, with a high parameter count and zero schema description coverage, it leaves the user under-specified for most configuration options (e.g., env, host, backend, slurm_options, capture_logs). Completing all required and optional parameters would require external knowledge not provided here.

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

  Parameters1/5

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

  Schema description coverage is 0% across all 15 parameters, and the description compensates for only two of them (inline_timeout_seconds and queue). Parameters like cwd, env, host, backend, capture_logs, slurm_options, timeout_seconds, and stall_timeout_seconds remain entirely unexplained. The description fails to provide anywhere near enough guidance for a tool with this many settings.

  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 verb+resource: 'starting one non-interactive command of uncertain duration.' It distinguishes itself from siblings by explicitly describing when this tool is the default, and contrasts it with submit_job and run_job. This is a specific, non-tautological purpose statement.

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

  Usage Guidelines5/5

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

  The description explicitly says when to use (one non-interactive command, uncertain duration) and when not to use: fire-and-forget/batch fan-out (use submit_job), MCP Tasks handle required (use run_job), resume existing job (wait_for/inspect). It even gives guidance for what to do with a detached handle: keep job_id and call wait_for_job once. This leaves little ambiguity about tool selection.

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

• run_jobA
  4/5.0
  Behavior4/5

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

  With no annotations, the description must disclose behavior. It explains that clients declaring the tasks protocol receive a Task handle immediately, while older clients block and get the ordinary result, and that client_request_id is stable for retries. This adds nontrivial behavioral context, though it does not cover potential side effects like permissions or lifecycle details.

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

  Conciseness4/5

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

  The description is concise and well-structured, with a clear introduction and practical guidance. It is front-loaded with the purpose and then gives usage constraints. No wasted words, but it could be slightly more structured (e.g., bullet points) for readability, though that is minor.

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

  Completeness2/5

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

  Despite having an output schema, the tool is complex with 14 parameters and zero schema descriptions. The description focuses on compatibility details and retry semantics but leaves out essential context about how the task is created, what the command array represents, how to configure environment, resources, etc. It is incomplete for an agent to confidently invoke the tool with correct arguments.

  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 0%, so the description must explain parameters. It only mentions client_request_id (explaining its role in retries) and implicitly references command, but provides no semantics for the other 12 parameters (cwd, env, host, queue, etc.). For a 14-parameter tool, this is inadequate — agents will not know what most parameters mean or how to set them.

  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 explicitly states it is a 'MCP Tasks compatibility entry point for explicitly creating a Task handle', which clearly identifies the verb and resource. It also distinguishes itself from siblings by saying 'Do not choose this for ordinary command execution: use run' and 'Do not choose it for generic asynchronous submission or fan-out: use submit_job', making its purpose clear and unique.

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

  Usage Guidelines5/5

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

  The description provides explicit when-to-use and when-not-to-use guidance: it should be used for Task handle creation, not for ordinary execution (use run) or async submission (use submit_job). It also gives specific guidance on retrying with the same client_request_id and identical arguments, which is actionable for the agent.

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

• create_queueA
  4.1/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 does disclose critical behavioral traits such as immutability (queue cannot be modified after creation), FIFO ordering, and fixed concurrency limit. These are important lifecycle details. However, it omits error handling such as behavior on duplicate names or permission requirements, so not a perfect score.

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

  Conciseness5/5

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

  The description is a single sentence that is front-loaded with the verb and resource. Every word earns its place, with no wasted or redundant elements.

  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 creation tool with an output schema and two parameters, the description covers the main purpose but leaves gaps. It does not mention potential failure scenarios (e.g., duplicate name handling) or usage context relative to sibling tools. The lack of annotations increases the need for these details, making it minimally viable but incomplete.

  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?

  Since schema description coverage is 0%, the description compensates by mapping 'named' to the name parameter and 'fixed concurrency limit' to the concurrency parameter, giving meaning to the integer. It doesn't provide constraints like positive integer, but it clarifies the role of each parameter.

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

  Purpose5/5

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

  The description states a specific verb ('Create') and resource ('queue'), and clearly distinguishes it from sibling job tools by highlighting key properties: immutable, named, FIFO, and fixed concurrency limit. This leaves no ambiguity about the tool's purpose.

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

  Usage Guidelines3/5

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

  Usage is implied by the tool name and context, but the description does not explicitly state when to use this tool versus alternatives or provide any exclusions. For example, it doesn't mention that a queue must be created before submitting jobs, nor does it explain 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.

• get_job_statusA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It states the tool is non-waiting and 'never starts or retries work,' which are important behavioral traits beyond what the schema conveys. It could add more about error handling or response format, but output schema covers the latter.

  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 (three sentences), front-loaded with the core purpose, and every sentence adds value: purpose, usage guidance, and behavioral caveat. No redundant or filler content.

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

  Completeness5/5

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

  For a simple one-parameter status-check tool, the description covers purpose, usage guidance, and behavioral limitations. An output schema exists, so return values need no explanation. The context is complete and effective.

  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 has 0% description coverage, so the description must compensate. It only refers to 'known job_id' without adding format, type, or example context. The schema's 'Job Id' title is minimal, and the description doesn't meaningfully enrich parameter meaning, leaving the agent to infer from the tool name.

  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 function: 'Get one immediate, non-waiting state snapshot for a known job_id.' It uses a specific verb ('Get') and resource ('job_id') and distinguishes from siblings like wait_for_job by explicitly framing this as a non-waiting snapshot.

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

  Usage Guidelines5/5

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

  Provides explicit when-to-use and when-not-to-use guidance: 'Use only when the caller needs current status now. Do not use this to wait for completion or build a polling loop; use wait_for_job for one Job or wait_for_completions for several.' This clearly names alternatives and exclusions.

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

• get_job_logsA
  4.6/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the burden. It discloses that the logs are bounded ('bounded stdout and stderr tails'), intended for failed/stalled jobs, and not for progress monitoring. It does not specify what happens if the job is healthy or if logs are empty, but the core behavioral constraints are clear. A score of 4 reflects strong disclosure without full detail.

  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 short paragraphs, each sentence adds value. The first sentence defines purpose, the second gives clear usage guidelines and exclusions. No fluff or repetition.

  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 has an output schema (which likely describes the log structure), and the description explains when to use it. It covers the main use case and boundary conditions. It lacks details on parameter semantics (like tail units or max_bytes limits) and edge cases (e.g., job not found), but for a read-only diagnostic tool with an output schema, this is sufficient. A 4 is warranted given the strong usage guidance offsets minor gaps.

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

  Parameters4/5

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

  Schema description coverage is 0% and there are three parameters. The description does not detail parameters, but it introduces the concept of 'bounded' tails and 'stdout/stderr' which hints at the meaning of tail and max_bytes. It does not explicitly map parameters, but the context gives enough for a reasonable inference. Given zero coverage, the description partially compensates, hence a 4.

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

  Purpose5/5

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

  The description states a specific verb+resource ('Inspect bounded stdout and stderr tails') and narrows the scope to 'a known failed or stalled job', clearly distinguishing it from sibling tools like get_job_status or wait_for_job. It precisely defines what the tool does and does not do.

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

  Usage Guidelines5/5

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

  The description explicitly states when to use the tool ('after a terminal wait reports failure, timeout, stall, or loss'), what it should not be used for ('do not use as a progress stream, do not repeatedly tail a running healthy Job'), and names the alternative (wait_for_job) for learning completion. This is exemplary usage guidance.

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

• submit_jobA
  4.7/5.0
  Behavior5/5

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

  With no annotations, the description carries full responsibility. It discloses key behaviors: no waiting, defaults for omitted backend/host, client_request_id retry behavior (identical retry returns original, conflicting rejected), FIFO queue semantics, and allowed Slurm options. It also addresses an edge case (lost creation response). No contradictions with annotations (none provided).

  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 moderately long but each sentence adds value. It is front-loaded with purpose, then details defaults, retry, queue, Slurm, and usage warnings. No redundancy; structure is logical. Slightly verbose but well-organized.

  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 14 parameters and no annotations, the description covers important behavioral and usage aspects, including exclusions and retry pitfalls. It does not detail every parameter or the return value, but an output schema exists. Overall, it provides substantial context for a complex tool, though not exhaustive.

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

  Parameters4/5

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

  Schema lacks property descriptions (coverage 0%). The description compensates by explaining backend/host defaults, client_request_id semantics, Slurm options allowed keys, and queue behavior. However, many parameters (cwd, env, artifacts, resources, capture_logs, timeouts) are not explained, leaving gaps. Still, it adds meaningful context for several key parameters.

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

  Purpose5/5

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

  The description opens with a clear, specific statement: 'Explicitly submit one asynchronous or fan-out job without waiting.' This distinguishes it from sibling tools like run (synchronous) and run_job (MCP Tasks). Purpose is directly stated and unambiguous.

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

  Usage Guidelines5/5

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

  Explicit guidance is provided: 'Do not use this as the default for a single command with uncertain duration; use run. Do not use it for MCP Tasks creation; use run_job.' It also warns against resubmitting on disconnection/timeout and explains retry semantics, giving clear when-to-use and when-not-to-use context.

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

• wait_for_completionsA
  4.9/5.0
  Behavior5/5

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

  There are no annotations, so the description carries the full burden of behavioral disclosure. It goes beyond a simple 'wait for completions' by revealing durability, immediate return of existing completions, cursor replay/consume semantics, at-least-once delivery with deduplication by completion_id, timeout non-cancellation, and disconnect-related resubmission guidance.

  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 compact and well-structured in three dense paragraphs: purpose/behavior, cursor semantics, and usage guardrails. Every sentence adds meaningful information, and the first sentence immediately establishes the tool's role.

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

  Completeness5/5

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

  With no annotations and moderate cursor/wait complexity, the description is complete enough for an agent to use it safely: it covers delivery guarantees, cursor lifecycle, timeout behavior, and coordination expectations. Since an output schema exists, the lack of return-field elaboration is not a gap.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description must add parameter meaning. It substantially explains after_cursor (replay vs. advancing to next_cursor) and timeout_seconds (excluding cancellation), while surface-level job_ids and limit are mostly left to their self-explanatory names and schema defaults. This is strong compensation, though not exhaustive for limit.

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

  Purpose5/5

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

  The description states a specific verb+resource+scope: 'Collect durable terminal results across multiple known jobs after a cursor.' It also clearly distinguishes itself from siblings by explicitly saying 'Do not use this for one job' and naming get_job_status as a different polling approach, so there is strong 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 Guidelines5/5

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

  The description gives explicit when/when-not guidance: submit independent jobs before calling, do not use for a single job, do not poll get_job_status between continuation calls, and never resubmit active jobs after a waiter disconnects. It also names an alternative tool (get_job_status) in the exclusion, making usage boundaries clear.

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

• wait_for_jobA
  4.9/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full transparency burden, and it excels. It discloses durability semantics (client-side timeout does not cancel the job), describes return content (state, exit code, bounded logs, Artifacts), and implies idempotent re-invocation, providing rich behavioral context beyond what any annotation would offer.

  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?

  Four sentences, 67 words, each earning its place: purpose, return values, failure semantics, and usage guidance are all covered without a single wasted word. The description is front-loaded with the core action and follows with critical behavioral details.

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

  Completeness5/5

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

  The description is complete for an agent to decide when and how to invoke this tool, given the 2-parameter schema and presence of an output schema. It covers return values, timeout behavior, retry semantics, and clearly differentiates from the most likely sibling alternative (wait_for_completions), fully addressing the tool's complexity.

  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?

  Despite 0% schema description coverage, the description adds meaning to both parameters: job_id is implied to be a known, reusable identifier, and timeout_seconds is contextualized as client-side ('A client-side timeout or disconnect does not cancel the Job'). However, it doesn't specify timeout_seconds value ranges or defaults, and parameter-specific details are inferred rather than explicit, keeping it from a 5.

  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 opening sentence 'Wait once for a known job_id and consume its durable terminal result' provides a specific verb+resource with scope. It distinguishes from the sibling wait_for_completions by emphasizing single-job collection, making the purpose immediately unambiguous.

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

  Usage Guidelines5/5

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

  The description gives explicit when-not guidance ('Do not use it to start work, do not poll it repeatedly'), names a direct alternative ('use wait_for_completions instead when collecting several independent Jobs'), and clarifies retry behavior on timeout ('call this tool again later with the same job_id'). This is textbook-grade usage guidance.

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