Server Quality Checklist

Tool Scores

• statusC
  2.7/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 behavioral disclosure. It states what information is reported (phase and task progress) but does not clarify whether the operation is read-only, whether it has side effects, or what the output format looks like. This is a minimal disclosure, insufficient for a clear behavioral understanding.

  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 redundant words, front-loading the core purpose. It earns top marks for efficiency and structure.

  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, no annotations, and zero parameter documentation, the description must provide a complete mental model. It only mentions what is reported, not how to call it, what to expect in return, or any prerequisites. For a simple one-param tool it is minimal but not fully adequate, warranting a 2.

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

  Parameters1/5

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

  Schema description coverage is 0% and the description does not explain the project_id parameter beyond what the property name implies. The agent gets no guidance on the format, requirements, or how to obtain a valid project_id, so the description fails to compensate for the schema gap.

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

  Purpose4/5

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

  The description clearly states the verb 'report' and the resource 'a project's current phase and task progress', making the tool's purpose distinct from siblings like health or start_project. It does not confuse with other tools, so a 4 is appropriate rather than a 5 because it lacks an explicit comparison to siblings.

  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 guidance is given on when to use this tool versus alternatives such as list_projects or health. The context of when to invoke status vs. others is left entirely to the agent's inference, so this dimension scores low.

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

• review_spec_chunkA
  3.6/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the burden of behavioral disclosure and does reveal key behaviors: 'approve' advances the state, 'revise' redrafts with feedback. It does not state prerequisites, side effects on surrounding data, or error conditions, which are clear gaps. It also implies feedback is needed for revision, but the schema marks it optional, adding some 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 two sentences with no wasted words. It front-loads the core action and then clarifies the decision semantics. Every sentence earns its place.

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

  Completeness3/5

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

  The description is adequate for a simple tool with three parameters and no output schema, but it omits details about prerequisites, what constitutes the 'current spec chunk', and what happens after approval or revision. It also does not address potential errors or edge cases like submitting 'revise' without feedback. Given no annotations, this is a minimum-viable level of completeness.

  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 schema has 0% description coverage, so the description must add meaning. It interprets the 'decision' parameter by naming two specific values ('approve' and 'revise') and explains their effects. It also clarifies that feedback is used during revision. It does not elaborate on project_id, but that parameter is self-explanatory from its title.

  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 states a clear action ('Approve or revise') on a specific resource ('current spec chunk') and distinguishes the two modes with their effects. It does not explicitly contrast with sibling tools like next_spec_chunk or approve_plan, but the resource and action are specific enough to differentiate from most tools.

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

  Usage Guidelines3/5

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

  The description explains when to use the tool implicitly by describing the action and the effects of the decision parameter. It does not provide explicit exclusions or compare against sibling tools such as next_spec_chunk, which may also advance, leaving some ambiguity about which tool to pick. However, the two decision modes are clearly mapped to their outcomes.

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

• start_projectA
  3.6/5.0
  Behavior3/5

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

  With no annotations provided, the description must carry the burden of behavioral disclosure. It does disclose that the tool mutates state ('Creates state'), returns interview questions, and that code should not be written yet. However, it does not explain persistence, failure modes, idempotency, or what happens if the project already exists, so the transparency is only partial.

  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 short, front-loaded with the primary purpose, and every sentence adds value. It states what happens, what to do next, and what not to do, all in three concise sentences with no filler.

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

  Completeness3/5

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

  For a simple two-parameter tool with no output schema or annotations, the description covers the core workflow reasonably well. However, the absence of parameter explanations and the lack of guidance about when this tool should be called relative to siblings like submit_answers leaves notable gaps for an agent making a fully informed call.

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

  Parameters1/5

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

  The schema has 0% description coverage, and the tool description does not explain what 'brief' or 'repo_path' should contain. The parameter names are suggestive, but the description adds no meaning beyond the schema, leaving the agent to guess the required format and semantics.

  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 a specific action and resource: 'Begin a design-first project,' and it concretely says the tool 'creates state and returns the first interview questions.' This distinguishes it from siblings like make_plan, run, and approve_plan, which are later workflow steps.

  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 gives clear context: this is the first step of a design-first project and returns interview questions for the user. It also instructs the agent to ask the user these questions and explicitly says 'do NOT write code yet,' which helps with when-not behavior. It does not name alternatives like submit_answers, but the workflow context is clear.

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

• approve_planA
  3.8/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. It reveals that this is not read-only (records approval and advances state), but it does not disclose side effects on the plan, reversibility, permissions required, or failure conditions. For a simple state transition, this is minimal but not comprehensive.

  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, compact sentence that front-loads the core action and outcome. It contains no redundant wording, filler, or unnecessary detail.

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

  Completeness3/5

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

  Given the tool is simple (1 param, no output schema, no annotations), the description provides the essential purpose and progression but omits parameter semantics and preconditions (e.g., that a plan must already exist). An agent might call it without full context, so it is only minimally complete.

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

  Parameters2/5

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

  The schema has 0% description coverage, and the description does not explain the project_id parameter at all. The name is self-explanatory, but the description gives no context about how project_id relates to the plan or the approval process. This forces the agent to rely on schema type alone, which is insufficient.

  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 action (record user's approval) and resource (generated plan), plus the outcome (advance to EXECUTE). It clearly distinguishes from siblings like make_plan (create plan) and run (execute), even without naming them, by specifying the transition trigger.

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

  Usage Guidelines4/5

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

  The description clearly implies when to use it: when the user approves the generated plan. The phrase 'advance to EXECUTE' signals it is the step before execution. However, it does not explicitly mention alternatives or exclusions, so the agent must infer the context from sibling names.

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

• list_projectsA
  3.8/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 of behavioral disclosure. It clearly implies a read-only listing operation, but does not mention any potential side effects, limitations, or response specifics such as pagination or return format. For a simple zero-parameter list, this is adequate, though not rich.

  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, clear sentence with no unnecessary words. It is front-loaded and concise, exactly meeting the standard for conciseness.

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

  Completeness4/5

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

  Given the zero-parameter complexity and lack of annotations or output schema, the description is almost complete. It clearly states the operation and the resource. However, it does not describe the return structure (e.g., fields of a project), which might be relevant for an agent to know how to parse the response. This is a minor gap given the simplicity.

  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 description coverage is effectively 100% (empty properties). According to the rubric, with 0 parameters the baseline is 4. The description adds no parameter-related information, but there are none to explain, so this baseline is appropriate.

  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 'List' and a clear resource 'all known Manifestation projects'. It is unambiguous and does not overlap with any sibling tool, which include actions like start_project, run, or health, none of which list projects. This fully clarifies 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 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. The description simply states what it does without any context about when it is appropriate or whether other tools might be better suited for certain scenarios. An agent is left to infer its usage solely from the name and description.

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

• submit_answersA
  3.9/5.0
  Behavior3/5

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

  With no annotations available, the description carries the full burden of behavioral disclosure. It does reveal that the tool can change project state (advance to SPEC) and explains the return behavior. However, it omits details such as whether answers are validated, how the order of answers maps to questions, and whether the action is idempotent.

  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, well-structured sentence that front-loads the action and includes the key outcome. It contains no filler or redundant phrasing, and every clause contributes to the agent's understanding.

  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 two-parameter tool, the description covers the core workflow adequately. However, the absence of an output schema and annotations means the agent is left without details on how the returned 'more questions' are structured or how answers should be formatted, which could require additional inference during invocation.

  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 adds meaning to 'answers' by clarifying they are the user's responses to current discovery questions, but it does not explain formatting, ordering, or required count. 'project_id' is left completely to the schema, relying on the parameter name alone.

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

  Purpose5/5

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

  The description uses a specific verb ('Submit') and a clear resource ('the user's answers to the current discovery questions'), and further clarifies the two possible outcomes: more questions or advancing to the SPEC phase. This distinguishes it from the listed sibling tools, which concern planning, approval, and project lifecycle actions.

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

  Usage Guidelines4/5

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

  The description clearly situates the tool in the discovery question flow: after questions are presented, this tool submits the user's answers. It does not explicitly name when not to use it or list alternatives, but the intended context is unambiguous enough for an agent to select it over siblings.

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

• reset_taskA
  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 disclosing behavior. It explicitly states that the tool changes task state to pending, applies to ANY task (not just BLOCKED ones), and exists to support run retries. This is honest and useful, though it omits details like reversibility or side effects on the run.

  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?

  It is a single, efficiently front-loaded sentence. Every phrase earns its place: the state transition, the scope, and the purpose. There is no redundant or filler content.

  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 mutation tool with no output schema, the description captures the core action and intent. It is incomplete only in that it does not explain how to source project_id or when it would be inappropriate to reset a task. The gaps are not severe, but they keep it from being fully self-sufficient.

  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 0% description coverage, so the description needed to compensate. It does not mention task_id or project_id at all, leaving the agent to infer their meaning solely from the property names and titles. This is minimal but not zero, since task_id is self-explanatory given 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 uses a specific verb ('Reset') with a clear resource ('task') and a precise state transition ('BLOCKED (or any) task back to pending'). It also states the intent ('so run can retry it'), making the tool's role clear and distinguishable from siblings like health, status, or run.

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

  Usage Guidelines4/5

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

  It provides clear context: use this tool to move a task to pending so the run can retry it. It does not explicitly list exclusions or alternatives, but no sibling appears to compete directly with this action, so the context is sufficient.

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

• healthA
  4.1/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 discloses the return value (server name and version), which is the main behavioral output, but it does not explicitly state that the operation is read-only, has no side effects, or requires no authentication. For a liveness check this is a minor gap, but still leaves the safety profile implicit.

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

  Conciseness5/5

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

  A single, front-loaded sentence that states the purpose and the return value with zero waste. Every word earns its place, and there is no superfluous 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 zero-parameter, no-output-schema tool, the description is completely sufficient. It tells the agent what the tool does, what it returns, and there are no missing elements required for correct invocation. The simplicity of the tool justifies the brevity.

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

  Parameters4/5

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

  With zero parameters, the schema adequately covers everything, and the baseline is 4. The description adds no parameter details, but none are needed. It correctly avoids content that would be redundant.

  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 a specific verb ('Liveness check') and resource (the server), and specifies the return value (server name and version). It is unambiguous and distinct from sibling tools like 'status', which implies overall state rather than a dedicated liveness probe.

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

  Usage Guidelines3/5

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

  The purpose implies usage—call it to verify the server is alive—but there is no explicit guidance on when to use it versus alternatives, nor exclusions. For a zero-parameter health check, the implied usage is sufficient, but it falls short of the explicitness seen in top-tier definitions.

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

• next_spec_chunkA
  4.1/5.0
  Behavior4/5

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

  No annotations are present, so the description carries the behavioral burden. It explicitly discloses a side effect: 'drafts the spec on first call', which alerts the agent that this is not a pure read operation. It does not fully describe all state changes or return behavior, but this is meaningful disclosure for a short description.

  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, tightly written sentence with the main action front-loaded and the side effect contained in a parenthetical. Every word earns its place, and there is no redundant 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?

  For a simple one-parameter tool, the description covers the action, the purpose, and an important first-call side effect. It could additionally clarify how chunks are delivered or what the agent should do after receiving them, but given the low complexity and the sibling workflow, it is mostly complete.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description does not explain how 'project_id' should be used or where it comes from. The parameter name is fairly self-explanatory, but the description adds no semantic value beyond the schema's 'Project Id' title, so it fails to compensate for the lack of schema descriptions.

  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 ('Get') and specific resource ('next spec chunk') and clearly states the purpose: 'to show the user for sign-off'. The parenthetical 'drafts the spec on first call' adds an important distinguishing behavioral detail, setting it apart from related tools like review_spec_chunk.

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

  Usage Guidelines4/5

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

  The description gives clear context for when to use the tool: when the next spec chunk needs to be presented to the user for sign-off. It does not provide explicit exclusions or name alternatives, but the 'next chunk' phrasing implies the workflow position without ambiguity.

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

• make_planA
  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 full burden. It discloses that the tool does not execute, returns full task bodies for review, and is repo-aware. It doesn't mention side effects like storage or persistence, but the lack of execution implies a read-only behavior. Overall, key behavioral traits are clearly stated.

  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 compact two-sentence structure that leads with the primary action and return value, then provides a critical behavioral note and a pointer to the follow-up tool. Every word earns its place, and there is no redundancy.

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

  Completeness3/5

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

  The description covers the core purpose, return type, and follow-up step, but lacks details on the exact format of the 'full task bodies' or any prerequisites like having started the project first. Given siblings like start_project and approve_plan, the tool's place in the workflow is partly implied but not fully specified. The agent could call it in the wrong order if the description mentioned prerequisites.

  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 zero description coverage, so the description must compensate. While the sole parameter 'project_id' is named clearly, the description does not explicitly link it to the plan generation or the repo context. The parenthetical 'repo-aware' hints at the connection but does not clarify the role of the ID. The agent must infer that project_id selects the project, which could lead to confusion.

  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 generates a bite-sized red/green TDD plan and is repo-aware. It explicitly mentions returning full task bodies for review, and the verb 'Generate' is specific. It distinguishes itself from sibling approve_plan by stating it does not start execution.

  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 tells the agent not to start execution and instructs to call approve_plan after user sign-off. This clearly identifies when to use this tool versus its main sibling, leaving no ambiguity about the workflow.

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

• runA
  4.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 behavioral disclosure, and it delivers: it flags the plan prerequisite, that the call is long-running, that it streams progress, and that it checkpoints per step. It does not contradict any structured data. Minor gaps remain around failure modes and post-run return behavior, but for a mutation/execution tool with zero annotation coverage this is strong disclosure.

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

  Conciseness5/5

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

  Two sentences with zero wasted words. The first is front-loaded with the core purpose and pipeline, and the second efficiently packs the parameter semantics plus the three key behavioral notes. Every clause earns its place.

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

  Completeness4/5

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

  Complete for an execution-loop tool: purpose, all cap parameters, the plan prerequisite, and runtime behaviors (long-running, streaming, checkpoints) are all covered. Missing only a note on what the agent receives on completion or on failure/rollback behavior, which matter given there is no output schema to fall back on. Minor gap, not a blocking one.

  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 compensate, and it does for 3 of 4 parameters: it explains that 'until' stops after N tasks and that 'max_agent_calls' and 'max_budget_usd' cap spend. Only project_id is left implicit, which is reasonable given the plan prerequisite. This adds genuine meaning beyond the bare type names in the schema.

  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?

  States a specific verb ('Run') and a concrete resource: the subagent-driven execution loop, spelled out as 'implementer -> server-verified TDD gate -> reviewer, per task'. This pipeline description cleanly differentiates the tool from siblings like make_plan, approve_plan, status, and health, so an agent can select it correctly without opening the schema.

  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?

  Gives clear context on prerequisite state: 'Requires an approved plan', which implicitly routes the agent to call this only after approve_plan. It also explains the purpose of the cap parameters. However, it does not explicitly name alternatives or list when-not-to-use conditions, so the guidance is contextual rather than exclusionary.

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