Server Quality Checklist

Tool Scores

• reasonix_inspectA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare the tool as read-only and idempotent, and the description adds useful behavioral context: 'bounded' suggests output limits, 'Events are opt-in' indicates default behavior, and the note about the default happy path avoiding inspect polling clarifies the expected call pattern. 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.

  Conciseness5/5

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

  The description is two concise, front-loaded sentences that pack maximum information without wasted words. Every phrase contributes meaning, from 'recovery-only' to 'no inspect polling'.

  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?

  Despite having an output schema, the tool is complex (6 parameters, 11 include enums, wait_until). The description gives a strong high-level overview but omits many include options and polling semantics (e.g., how wait_until interacts with wait_ms). It feels too terse to be fully self-sufficient for such a feature-rich tool.

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

  Parameters3/5

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

  With 0% schema description coverage, the description carries the full burden, and it does provide semantic hints (e.g., 'optional paginated diff or event output' maps to include/cursor, 'bounded' relates to max_bytes, 'Events are opt-in' relates to include). However, it does not explain task_id, wait_ms, or wait_until, leaving a significant gap for a 6-parameter tool.

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

  Purpose5/5

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

  The description clearly identifies the tool as an inspection utility for Reasonix tasks, listing specific outputs (status, evidence, interactions, diff/events) and scoping it as 'recovery-only'. This distinguishes it from the sibling tools (delegate, control) which handle execution and management.

  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 states 'Recovery-only' and 'The default two-call happy path uses no inspect polling', providing clear context for when to use this tool (recovery scenarios) and implying it is not part of the normal flow. It doesn't name alternatives directly but the context is sufficient to differentiate from siblings.

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

• reasonix_controlA
  4.7/5.0
  Behavior5/5

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

  The description adds rich behavioral detail beyond the annotations: finalize 'waits for a committed terminal result', automated ids are 'ignored for approval but every review-evidence criterion must be approved', and the returned commit is 'isolated and must be cherry-picked explicitly; this tool never merges or pushes'. These details are not present in the structured annotations and materially inform the agent.

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

  Conciseness5/5

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

  The description is six sentences but every sentence carries operational value: the happy path, finalize parameter copying, failure recovery, and commit isolation warning. It is front-loaded with the most used action (finalize) and avoids redundant filler.

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

  Completeness5/5

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

  Given the tool's complexity (5 actions, 13 parameters) and the existing output schema, the description is remarkably complete. It covers the default path, failure handling with explicit retry guidance, criteria approval semantics, and the tool's non-merging behavior. It leaves no critical operational gap.

  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 85%, and the schema already documents parameters like approved_review_criteria and expected_review_revision with similar wording. The description adds workflow-level context (e.g., 'copy review_revision to expected_review_revision'), but this largely mirrors the schema's own parameter descriptions. Hence, it meets the baseline without significantly enhancing parameter understanding.

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

  Purpose5/5

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

  The description opens with 'Control a task created by reasonix_delegate', clearly scoping the tool to lifecycle management of delegated tasks. It lists the five actions (steer, respond, cancel, finalize, close) and describes the primary happy path, distinguishing it from siblings reasonix_inspect and reasonix_delegate.

  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 usage context: the happy path is 'call finalize once after reviewing the returned bundle'. It references reasonix_delegate as the task origin and reasonix_inspect for repair ('inspect or repair it there'). It states when to use the other actions: 'Use respond, cancel, close, or steer only for explicit recovery or interaction handling.'

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

• reasonix_delegateA
  4.9/5.0
  Behavior5/5

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

  The description goes well beyond annotations by disclosing key behaviors: write_scope is an exclusive allowlist, forbidden_scope is only for sensitive carve-outs, commands are exact static argv with no shell/pipes/redirection, wait_timeout is recoverable and does not cancel the worker, and omitted resumes preserve stored settings. It also notes the requirement for 'explicit user approval,' which is critical context. No contradiction with annotations.

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

  Conciseness4/5

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

  The description is dense and front-loaded with the core purpose, followed by practical operational rules. It is longer than ideal and runs as a single block of text, but every sentence adds substantive guidance—defaults, constraints, and security invariants—so the length is justified.

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

  Completeness5/5

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

  Given the tool's complexity (12 parameters, nested contract object, multiple enums, output schema, annotations), the description covers the most decision-relevant aspects: task scoping, worker behavior, timeouts, resume semantics, and command execution security. It gives enough context for an agent to select and invoke the tool correctly without requiring external documentation.

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

  Parameters5/5

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

  Schema description coverage is only 33%, but the description compensates richly. It explains the semantics of write_scope and forbidden_scope, defaults for wait_mode, worker_lane, reasoning_effort (low is lowest), execution_timeout_seconds defaults (fast 600, deep 3600, max 14400), and advises file_assertions for byte-exact content. This adds meaning far beyond raw schema names.

  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 specific action: 'delegate one immutable TaskContractV1 to an isolated Reasonix edit worker' after explicit user approval. This clearly distinguishes the tool from siblings (inspect, control) by naming the delegated contract workflow and the worker isolation.

  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 strong situational guidance: for trivial edits with verified local context, do one focused preflight and delegate directly; avoid browsing docs/memory solely to construct the contract. It also differentiates worker_lane=fast versus deep, explains background mode, and specifies when deep is needed ('explicitly long-horizon delivery/goal work').

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