Server Quality Checklist

Tool Scores

• create_mapB
  3.4/5.0
  Behavior2/5

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

  With no annotations, the description carries full burden for behavioral disclosure. It mentions ownership and the need for an initial node tree, but does not discuss side effects, return values, error conditions, or authentication requirements beyond the token.

  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, consisting of two sentences that front-load the primary action with no extraneous words. Every sentence adds value.

  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 has three optional parameters and no output schema, the description is sufficient for understanding the basic function but lacks information about return values or what constitutes a successful creation.

  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 coverage is 100%, providing a baseline of 3. The description adds meaningful context for the 'data' parameter, explaining that it should contain an initial node tree so node primitives have a parent, which goes beyond the schema description.

  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 that the tool creates a map owned by the token's user, specifying the verb 'create' and the resource 'map'. However, it does not differentiate from sibling tools like 'create_node' or 'delete_map', leaving some ambiguity.

  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 implies when to use the tool (to create a map with an initial node tree) but does not explicitly state when not to use it or compare with alternatives like creating an empty map and adding nodes later.

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

• delete_mapB
  3.4/5.0
  Behavior3/5

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

  Without annotations, the description carries full burden. It discloses the destructive nature and that all nodes are also deleted, but lacks details on irreversibility, permission requirements, or any side effects beyond what is stated.

  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, efficient sentence with no wasted words. However, it could include a brief additional note (e.g., about irreversibility) without losing conciseness.

  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 destructive tool with one parameter, the description covers the basic action but lacks usage context, such as when deletion is appropriate or any constraints. Sibling tools are present, but no comparative guidance is given.

  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 100% for the single parameter 'mapId', and the description adds no additional meaning beyond the schema's description. Baseline score of 3 applies.

  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 ('Delete') and resource ('a map'), and distinguishes from the sibling tool 'delete_node' by explicitly stating it deletes 'all of its nodes' as well. This clearly communicates the tool's scope.

  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 provided on when to use this tool over alternatives, such as when to delete a map versus performing other actions. There are no prerequisites, caveats, or exclusion criteria mentioned.

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

• retry_nodeB
  3.4/5.0
  Behavior2/5

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

  With no annotations, the description carries full burden. It discloses that the tool clears error state and re-runs generation, and mentions the force parameter for expand nodes, but does not explain other behaviors like what happens if the node is not in error state or what output is expected.

  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 well-structured sentences with no unnecessary words. It is front-loaded with the core action first.

  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 absence of output schema and annotations, and 5 parameters with limited description, the description is too brief to fully guide an agent. It lacks details on parameter usage beyond force, return values, and error scenarios.

  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 60%, and the description adds value for the force parameter by clarifying its use for expand nodes with children. However, it does not address prompt or modelId parameters, and the schema already describes mapId and nodeId.

  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: 'Clear a node's error state and re-run its generation.' This is a specific verb-resource pair that distinguishes it from siblings like submit_node or interrupt_node.

  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?

  It provides some usage context by noting that retrying an expand node with children requires force=true, but it does not explicitly state when to use this tool versus alternatives 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.

• get_mapA
  3.6/5.0
  Behavior2/5

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

  With no annotations, the description only indicates a read operation. It lacks disclosure of potential performance implications for large maps, authentication requirements, or any side effects, leaving behavioral 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 a single, front-loaded sentence that efficiently conveys the tool's action and scope without any extraneous words.

  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 single-parameter tool with no output schema, the description adequately covers the core functionality. However, it could mention that this is the primary method to get all map data, but overall it's complete enough.

  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 100% with a clear description for mapId, but the tool description adds no additional meaning or context beyond the schema, so it meets baseline without enhancement.

  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 reads a full map including its complete node tree. It distinguishes itself from siblings like get_node (single node) and list_maps (listing only).

  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 implies usage for retrieving the entire map, but does not explicitly guide when to use this tool versus alternatives like get_node for a single node or get_subtree for a branch.

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

• update_nodeA
  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 full burden. It usefully clarifies that no LLM call occurs and no metering is applied, but omits other behavioral aspects such as whether the update is instantly visible, any side effects on node trees, or error conditions (e.g., if node doesn't exist).

  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 immediately states the tool's purpose and key distinguishing features. No redundant information.

  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?

  For a mutation tool with 8 parameters, no output schema, and no annotations, the description is too sparse. It does not explain the return value, prerequisites (e.g., node must exist), or how this tool interacts with siblings like auto_expand or retry_node. Additional context about the operation's scope and expected behavior is missing.

  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 50%, meaning some parameters (note, modelId, isCollapsed, modelProvider) lack schema descriptions. The description adds partial value by listing the fields (content, note, type, collapsed flag, model), but does not explain each parameter's syntax, constraints, or how 'model' maps to modelId/modelProvider.

  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 the tool applies a structural update to a node, listing specific fields (content, note, type, collapsed flag, model). The addition of 'No LLM call, no metering' distinguishes it clearly from sibling tools like submit_node or retry_node that involve LLM processing.

  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 implies when to use (for manual structural updates without LLM) but lacks explicit guidance on when not to use or alternatives. It does not mention prerequisites or scenarios where other sibling tools like create_node or delete_node would be more appropriate.

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

• create_nodeA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries full burden. It discloses the behavior of optional nodeId and UUID generation, but omits other behavioral traits such as error handling (e.g., if parentId is invalid), permission requirements, or whether the operation is synchronous.

  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 conveys essential information upfront. No unnecessary words or 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?

  Given no output schema and 7 parameters, the description provides the core action but lacks details on return values, success/failure indicators, and potential side effects. It meets minimum viability but leaves gaps for an agent to infer behavior.

  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 100%, so baseline is 3. The description adds value by explaining the nodeId behavior ('so you can reference ids you choose'), but does not significantly enhance understanding of other parameters beyond what the schema already provides.

  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 ('Create a structural node under a parent'), specifying the resource (node) and relationship. It distinguishes this tool from sibling tools like delete_node or update_node by focusing on creation. The additional detail about nodeId optionality further clarifies 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?

  The description implies usage context (creating a child node under a parent) but provides no explicit guidance on when to use this tool versus alternatives like auto_expand or submit_node. No conditions or exclusions are mentioned.

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

• submit_nodeA
  3.7/5.0
  Behavior3/5

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

  Without annotations, the description carries the full burden of behavioral disclosure. It reveals that the tool blocks until ancestors finish and is metered (likely incurs cost or usage tracking). However, it does not disclose side effects on the node (e.g., state changes), error handling, cancellation behavior, or idempotency—important for a long-running blocking 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 exceptionally concise: two short sentences that front-load the primary action and immediately provide critical behavioral constraints (blocking, metered). Every word carries weight, no redundancy or fluff.

  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's complexity (blocking, LLM execution, metered) and lack of output schema, the description is incomplete. It omits details about return value format (what does 'completed node' contain?), error scenarios (ancestor failure, timeout), and concurrency limits. Siblings like retry_node and interrupt_node imply complementary features but are not cross-referenced.

  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 input schema already contains descriptive parameter comments (100% coverage), so the description adds minimal value for parameters. The only extra insight is the implicit context that 'nodeId' refers to nodes in a tree that can have ancestors, but this is not stated explicitly for parameters. Baseline 3 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 clearly states the tool's action: 'Run the LLM on a node and return the completed node.' It uniquely distinguishes from siblings like create_node (creation only), get_node (retrieval), retry_node (retry), and interrupt_node (interruption). The verb 'submit' combined with 'run' on a node makes the purpose 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 Guidelines3/5

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

  The description provides a key context: 'Blocks until ancestors finish; metered.' This hints at when to use (when you need to run a node after its dependencies) but does not explicitly state when not to use or mention alternative tools. No guidance on prerequisites or common pitfalls, leaving room for ambiguity.

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

• delete_nodeA
  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 full burden. It discloses the cascade behavior and the root node restriction, which are essential behavioral traits. However, it does not mention potential side effects (e.g., irreversibility, permission requirements, or idempotency). The description adds value beyond the schema but could be more complete.

  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: two sentences that directly convey the purpose and key constraint. No extraneous words, front-loaded with the core action. 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?

  Given the low complexity (2 required params, no enums, no nested objects) and no output schema, the description adequately covers the operation's purpose. However, it lacks information about return values or error conditions (e.g., what happens if node does not exist or if root deletion is attempted). It is minimally complete but has 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?

  The input schema already provides 100% description coverage for both parameters (mapId and nodeId). The tool description does not add any additional meaning or clarification beyond what is in the schema. Thus, it meets the baseline but adds no extra semantic value.

  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 (delete), the resource (a node), and the key behavior (cascade deletion of descendants). It also distinguishes from sibling tools like delete_map by specifying 'node'. The constraint about root node not being deletable adds clarity. No tautology or ambiguity.

  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 mentions a constraint (root node cannot be deleted) which provides some guidance, but it does not explicitly state when to use this tool vs. alternatives like delete_map or other node operations. No explicit 'when-to-use' or 'when-not-to-use' conditions are given, though the purpose distinguishes it implicitly from siblings.

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

• list_mapsA
  3.9/5.0
  Behavior2/5

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

  No annotations provided, so the description must fully convey behavior. 'Metadata only' gives some scope, but fails to disclose read-only nature, potential errors, or pagination. Minimal behavioral transparency.

  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?

  One concise sentence with no wasted words, front-loading the action and scope.

  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?

  Adequate for a simple read operation with no output schema. Lacks details on return format but covers scope and ordering. Minor gap given lack of annotations.

  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 has no parameters (100% coverage), and the description correctly implies no parameters needed. No additional param info required.

  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 verb 'List', resource 'maps', scope 'authenticated user's', and ordering 'newest first', distinguishing it from siblings like get_map or create_map.

  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 implies usage for listing all maps, but lacks explicit context on when to use this tool versus alternatives like get_subtree or get_map. No exclusions or prerequisites mentioned.

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

• get_subtreeA
  4/5.0
  Behavior3/5

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

  In absence of annotations, description covers depth behavior but misses error handling, performance, or authentication needs. Adequate 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?

  Two sentences, front-loaded with purpose, no redundant information. Highly efficient.

  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?

  Adequate for a read tool with 3 parameters and no output schema; covers core behavior and depth semantics. Could mention error cases or sibling distinctions more explicitly.

  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?

  Input schema has 100% coverage with descriptions; description adds meaningful context for depth parameter ('omit for full subtree, 0 returns just node'), enhancing understanding beyond 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?

  Description clearly states it reads a node and descendants as a nested tree, with depth behavior explained. This distinguishes it from siblings like get_node (single node) and list_maps (list of maps).

  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?

  Description implies use when a tree structure is needed, but lacks explicit when-not or alternative comparisons to siblings like get_node or list_maps.

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

• interrupt_nodeA
  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. It discloses key behavioral traits: the state change to interrupted, preservation of partial output, and idempotency. This adequately informs the agent about side effects and behavior beyond the basic action.

  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 with two sentences, front-loading the main action and essential details (state change, partial output, idempotency). Every word contributes meaning; there is no wasted text.

  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 tool's simplicity, full schema coverage, and no output schema, the description is nearly complete. It covers the core effect and behavior. However, it could briefly mention error conditions (e.g., if node is not in a generating/queued state) or prerequisites, but these are minor 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?

  Input schema coverage is 100%, so the baseline is 3. The description does not add extra meaning to the parameters beyond their schema descriptions ('mapId' and 'nodeId'), and the tool description already explains the action sufficiently without parameter-level enrichment.

  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 'Stop an in-flight generation', providing a specific verb and resource. It clearly explains the effect: 'a generating or queued node flips to interrupted with partial output preserved', which distinguishes it from sibling tools like 'retry_node' or 'submit_node'.

  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 implies when to use the tool (to interrupt a generating or queued node) but does not provide explicit guidance on when not to use it or compare it to alternatives. While the tool's name is self-explanatory, the description lacks direct usage context relative to siblings.

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

• auto_expandA
  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 full burden. It discloses that the tool generates child nodes, returns their IDs, operates only one level deep, and requires manual submission of each child. It does not mention authentication or error states, but covers key behavioral aspects adequately.

  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 long, highly concise, and front-loads the main action followed by a critical constraint. Every word serves a purpose with no 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?

  For a tool with 4 parameters, no output schema, and no annotations, the description provides a solid overview. It explains the core action, depth limit, and necessary follow-up actions. The 'direction' parameter could be elaborated, but overall it's adequately 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 input schema has 100% description coverage, so by guidelines baseline is 3. The tool description does not add any additional meaning beyond the schema; it leaves parameter explanations to 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?

  The description clearly states the tool generates follow-up prompts as queued child nodes and returns their IDs, using specific verbs and resources. It differentiates from siblings like 'create_node' or 'submit_node' by focusing on automated generation.

  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 notes 'One level only; submit each child yourself,' providing clear context on how to use the tool. It implies the agent should not expect recursion and must handle child nodes, but lacks explicit when-not-to-use or alternative tool references.

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

• get_nodeA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries full burden. It discloses the read-only nature and the fact that children field lists IDs. Adequate for a simple read operation, but no mention of side effects or auth.

  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, no wasted words. Front-loaded with the main action and key behavior.

  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 low complexity, full schema coverage, and no output schema, the description provides sufficient context. It explains what is returned (node without descendants, children field with IDs), making the tool complete.

  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 coverage is 100% (both parameters have descriptions). The description adds value by specifying nodeId is 'unprefixed, as returned in node trees', going beyond 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?

  Description clearly states 'Read a single node without its descendants', using specific verb and resource. It distinguishes from sibling tools like get_subtree by emphasizing the lack of descendants.

  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?

  Provides clear context for when to use (read single node without descendants), but lacks explicit exclusion or alternative naming. However, the contrast with get_subtree is implied, and the sibling list provides context.

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