Server Quality Checklist

Tool Scores

• stop_nodeC
  2.1/5.0
  Behavior1/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 transparency. 'Stop a single node' adds no behavioral information beyond the tool's name; it does not disclose side effects, reversibility, or the meaning of the 'wait' parameter, making this a near-tautology.

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

  Conciseness2/5

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

  The description is a single sentence, but it is under-specified rather than appropriately concise. It provides no more information than the tool name itself, and its brevity comes at the cost of all substantive guidance. It is not a well-structured explanation of the tool's behavior or usage.

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

  Completeness1/5

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

  The tool is woefully incomplete given its complexity: it has 3 parameters, 2 required, no annotations, and a description that merely repeats the tool name. While an output schema exists, it does not explain when to use the tool, what the 'wait' parameter controls, or what consequences stopping a node has on the lab topology. An agent would have to guess or make assumptions.

  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 input schema has zero descriptions for parameters, and the tool description does not compensate. 'Stop a single node' gives no meaning to 'lab_id', 'node_id', or especially 'wait', which is non-obvious. An agent would not know whether 'wait' means waiting for the stop to complete or something else.

  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 action (stop) and the target (a single node), which is specific enough to distinguish from sibling tools like stop_lab (which stops an entire lab) and start_node (which starts instead of stops). However, it lacks any additional context about what 'stopping' entails, such as whether it is a graceful shutdown or an immediate termination.

  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. For example, the description does not explain that stop_node should be used for stopping individual nodes while stop_lab is for stopping entire labs, nor does it mention any preconditions like the lab needing to be running.

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

• start_nodeC
  2.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 of disclosing behavioral traits. It merely says 'start' without revealing idempotency, async behavior, side effects on an already-running node, or the meaning of the 'wait' parameter.

  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, focused sentence with no filler. It front-loads the verb and resource. While very short, it is free of redundancy and gets straight to the point.

  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 this is a mutation tool with no annotations, the description is too sparse. It omits behavior around the wait flag, idempotency, and what output to expect. Although an output schema exists, the description still lacks enough context for an agent to use the tool effectively.

  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%; the description adds zero explanation of lab_id, node_id, or wait. The 'wait' parameter in particular is ambiguous—wait for what? The description does not compensate for the schema's lack of field descriptions.

  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 tool starts a single node, with 'boot' as a synonym. The qualifier 'single' distinguishes it from starting a whole lab, though it doesn't explicitly name sibling alternatives. It is concise 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 Guidelines2/5

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

  No guidance is given about when to use this tool versus alternatives like start_lab or stop_node. It doesn't mention prerequisites, exclusions, or scenarios where a different tool 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.

• stop_labC
  2.6/5.0
  Behavior1/5

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

  With no annotations provided, the description carries the full responsibility for behavioral transparency. It only states the obvious action ('stop every node') and does not disclose side effects, reversibility, requirements, or the effect of the 'wait' parameter. For a mutating operation, this is a significant gap—users are left unaware of what happens to running processes, lab state, or whether the action is destructive.

  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, short sentence with no wasted words. It is front-loaded and efficient. However, it is so terse that it borders on under-specification, but for a simple 2-parameter tool, the brevity is acceptable from a conciseness standpoint.

  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 tool has moderate complexity (2 parameters, output schema), and the description is extremely incomplete. It fails to explain the 'wait' parameter, any behavioral nuances, or usage context. While the output schema exists and may cover return values, the description does not address operational semantics. The lack of annotations makes this gap more severe.

  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 mention either parameter ('lab_id' or 'wait'). It adds zero meaning beyond the raw schema definitions. The 'wait' boolean with a default is completely unexplained, and there is no guidance on how to specify the lab. The description fails to compensate for the lack of schema-level 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 'Stop every node in a lab' clearly specifies the action (stop) and the resource scope (all nodes in a lab). It distinguishes itself from sibling tools like 'stop_node' (stops a single node) and 'start_lab' (starts all nodes), leaving no ambiguity about its function.

  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 guidance on when to use this tool versus alternatives such as 'remove_node' or 'wipe_lab'. It does not mention prerequisites (e.g., lab must exist), nor does it note any situations where a different tool would be more appropriate. The only implied usage is 'stopping all nodes in a lab,' but there is no explicit comparison or context.

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

• delete_labC
  2.9/5.0
  Behavior3/5

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

  The description discloses that the operation is permanent and destructive, which is key behavioral context. Since no annotations are provided, this is valuable, but it omits permission requirements or any side effects beyond 'everything in it'.

  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 sentences, concise and front-loaded with the key action and consequence.

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

  Completeness3/5

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

  The tool is simple, but the description leaves unclear the distinction from 'wipe_lab' and whether any precautions are needed. The output schema exists, so return values are not the issue.

  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 only lab_id with no description, and the tool description does not mention the parameter at all. With 0% schema coverage, the description completely fails to explain how to specify the lab being deleted.

  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 tool deletes a lab permanently, using a specific verb and resource. However, it does not differentiate from the sibling tool 'wipe_lab', so it doesn't fully meet the 5 criterion.

  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 versus alternatives such as stop_lab or wipe_lab. The irreversibility warning is not a usage guideline.

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

• remove_linkC
  2.9/5.0
  Behavior2/5

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

  There are no annotations, so the description bears full responsibility for behavioral disclosure. It only states the action and does not mention side effects, irreversibility, error conditions, or required states (e.g., link must 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 sentence of eight words, efficiently conveying the core action. It is front-loaded with the verb and contains no filler.

  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?

  Although the tool is simple, the description lacks contextual information such as the lab scope (implied by lab_id), expected effects on the topology, and any error behavior. With an output schema present but not described, the agent has no guidance on response semantics either.

  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 input schema has two required parameters with no descriptions (0% coverage). The description does not mention lab_id or link_id, nor does it explain their roles. The phrase 'between two nodes' could confuse an agent about why no node IDs are parameters, and the description fails to compensate for the lack of schema documentation.

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

  Purpose5/5

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

  The description uses the specific verb 'Remove' and identifies the resource as 'a link between two nodes,' which clearly distinguishes this tool from siblings like add_link and remove_node. It is unambiguous about the action performed.

  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 guidance on when to use this tool, how it relates to alternatives, or any prerequisites. It simply states the action without context, so an agent has no information about when this is appropriate.

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

• start_labB
  3.1/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 only states the action without disclosing side effects, the impact of the 'wait' parameter, error behaviors, or whether the operation is safe/reversible. This is a significant gap.

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

  Conciseness5/5

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

  A single, concise sentence that front-loads the core purpose with no fluff. Every word earns its place, though it may be under-specified, that is evaluated elsewhere.

  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 tool with two parameters, an output schema, and sibling tools like start_node, the description is incomplete. It omits details about the wait parameter, return behavior, and when to choose this over alternatives, leaving an agent to guess or infer critical operational context.

  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%, so the description must compensate by explaining the parameters. It does not mention lab_id or wait at all, leaving their meaning and usage entirely to the schema, which also lacks descriptions. No semantic value is added.

  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 ('Start (boot)') and resource ('every node in a lab'), clearly distinguishing it from sibling tools like start_node, which starts a single node. The scope is 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 implies the use case (boot all nodes in a lab) but provides no explicit guidance on when to use this tool versus start_node or stop_lab, nor any prerequisites or exclusions. It's a basic implied usage.

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

• get_node_console_logB
  3.3/5.0
  Behavior2/5

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

  With no annotations, the description must bear the full burden of behavioral disclosure. It notes the default console_id and the optional line limit, but does not state that the operation is read-only, what happens if the node is missing, or any preconditions. The term 'captured' hints at stored output, but this is insufficient 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?

  The description is a single concise sentence with an informative parenthetical. It is front-loaded with the main action and resource, and contains no unnecessary verbiage.

  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 lack of annotations and 0% schema coverage, the description covers the core purpose and the non-obvious parameters, but omits usage context, exclusions, and preconditions. The output schema may define return values, but the description alone is minimally sufficient for an agent to invoke the tool correctly.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description partially compensates by explaining console_id (main console on most platforms) and lines (limit to last N lines). It does not explain lab_id or node_id, though these are relatively self-explanatory from their names. The description adds some semantics but misses the remaining 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 clearly states the action ('Get') and the resource ('console output captured for a node'), and it adds a clarifying detail about console_id 0 being the main console. This distinguishes it from sibling tools like get_node_config, which retrieves configuration, not console logs.

  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. It does not mention prerequisites, exclusions, or when to prefer other tools. The implied usage is limited to the verb 'Get', but no when-to-use context is given.

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

• create_labB
  3.4/5.0
  Behavior2/5

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

  No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states the lab is 'empty' but does not mention prerequisites, duplicate-title behavior, persistence, permissions, or any side effects. For a mutation tool, this is a significant gap.

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

  Conciseness5/5

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

  The description is exactly two sentences: the first states the primary function, the second gives immediate follow-up actions. Every word adds value, with no filler or repetition.

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

  Completeness3/5

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

  The tool is simple (2 string parameters) and there is an output schema, so return value documentation isn't needed. The description covers the purpose and how to populate the lab. However, it omits important edge-case behavior like duplicate titles or failure modes, making it minimally adequate but not complete.

  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 only 2 parameters with 0% description coverage, and the description provides no parameter information whatsoever. It does not explain that 'title' is required, what 'description' is for, or the default behavior. The description entirely fails to compensate for the schema's lack of semantic explanation.

  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 and resource ('Create a new, empty lab') and clearly distinguishes this tool from siblings like 'delete_lab', 'start_lab', and 'list_labs'. It also states the result is an empty lab, which sets it apart from topology modifications.

  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 recommends using 'add_node/add_link or build_topology' to populate the lab, giving clear next-step guidance. It doesn't explicitly state when not to use this tool, but there are no reasonable alternatives for creating a lab, so the guidance is sufficient.

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

• get_node_configA
  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 transparency burden. It conveys that this is a read operation ('Get') and specifies the data is 'stored' and 'day-0 startup configuration text', which implies safety. However, it does not disclose any potential side effects, error conditions, or access requirements, though for a simple read with an output schema, the lack of extra detail is acceptable.

  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 with no filler or redundant information. Every word contributes to the meaning, making it highly efficient.

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

  Completeness3/5

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

  The tool is simple with only two parameters and an output schema, so the description is mostly adequate for basic use. However, it lacks guidance on when to use this vs. sibling configuration tools and provides no parameter explanations, leaving some context gaps for an agent unfamiliar with the domain.

  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 provides no parameter descriptions (0% coverage), so the description must compensate. It references 'a node' which hints at node_id, but it does not explain lab_id or the relationship between the two parameters. The description adds minimal semantic value beyond the schema's bare field 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 clearly states the action ('Get'), the resource ('stored day-0 startup configuration text'), and the target ('a node'). It distinguishes itself from sibling tools like set_node_config (write) and extract_node_config (likely different extraction context) by specifying 'stored' and 'day-0 startup'.

  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 a node's saved initial configuration, but it does not explicitly state when to prefer this over similar tools such as extract_node_config or get_node_console_log. No clear alternatives or exclusions are mentioned, leaving the usage context inferred rather than explicit.

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

• remove_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 does disclose a key behavioral trait: the node and its attached links/interfaces are removed. However, it does not mention whether the action is irreversible, requires stopping the lab, or any other side effects.

  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 a clear verb-first structure. It is concise and front-loaded with the action, containing no unnecessary information.

  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 but lacks details about safety, irreversibility, or preconditions. Since the tool is destructive and has no annotations, more context would be expected. The presence of an output schema reduces the need to explain return values, but the behavioral and usage context remains incomplete.

  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 'lab_id' or 'node_id' beyond the general context of 'lab' and 'node'. It does not state which parameter identifies which resource, so the description adds little meaning over the schema's 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 uses a specific verb ('Remove') and identifies the resource ('node') and scope ('any links/interfaces attached to it'). It clearly distinguishes this tool from the sibling 'remove_link' by noting the cascading removal of attached links and interfaces.

  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 (when removing a node from a lab) but does not explicitly state exclusions or reference alternatives like 'remove_link' for link-only removal. The context of the siblings suggests that 'remove_link' is for links only, but this is not spelled out.

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

• deploy_example_topologyA
  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 the burden of behavioral disclosure. It does convey that the tool creates a new lab without modifying an existing one ('as a new lab, unmodified'), which is a key behavioral trait. However, it does not elaborate on permissions, side effects, start behavior (despite a 'start' parameter), or what the response contains. This is partial but not comprehensive 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?

  The description is two sentences, front-loaded with the primary action, and every clause serves a purpose. It efficiently conveys the tool's core behavior and directs to alternatives without unnecessary filler.

  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 tool has three parameters with zero schema description coverage and no annotations, yet the description fails to explain the parameters or the tool's full behavior (e.g., whether the lab starts automatically). Although an output schema exists, the description is incomplete for a tool with this level of parameter complexity, lacking essential context for correct usage.

  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 description coverage is 0%, and the description provides no explanation for any of the three parameters (name, start, lab_title). The description only mentions the tool's overall function, leaving the user to infer what the parameters do from names alone. This is insufficient compensation for the schema's lack of 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 clearly states the tool's function: building an unmodified built-in example topology as a new lab. It uses a specific verb ('Build') and resource ('example topologies'), and distinguishes itself from the customization path by explicitly naming get_example_topology + build_topology as alternatives.

  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 guidance: use this tool for unmodified example topologies, and for customization use get_example_topology + build_topology instead. It also directs the user to list_example_topologies to see available options, 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.

• extract_node_configA
  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 discloses the prerequisite (node started/booted/converged) but does not explicitly state whether the operation is read-only or what happens if the node is not in the required state. It adds some behavioral context but omits non-mutating confirmation and side effects.

  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 action and a key requirement without any filler. It is fully efficient and 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?

  For a simple retrieval tool with an output schema, the description covers the core action and a prerequisite. However, it omits a clear comparison to the sibling get_node_config and does not explicitly confirm non-destructiveness, leaving some ambiguity in a context with similar tools.

  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% and the description does not explain lab_id or node_id. The parameter names and titles are self-explanatory, but the description adds no additional meaning, leaving the agent to rely solely on naming conventions without further elaboration.

  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: 'Pull the current running configuration off a booted, converged node and return it'. It identifies the resource (configuration) and the state prerequisite (booted, converged), and distinguishes from sibling get_node_config by emphasizing the 'running' configuration.

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

  Usage Guidelines4/5

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

  The description provides a clear prerequisite ('Requires the node to be started'), giving guidance on when to use it. It does not explicitly name alternatives or when to avoid it, so it falls short of a 5, but the condition offers practical usage context.

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

• get_lab_topologyA
  3.8/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 of disclosing behavioral traits. It indicates a read operation via 'Get' and specifies the returned content (nodes, links, state). However, it does not explicitly state that the tool is non-destructive, or describe any rate limits or permissions. This is acceptable for a simple retrieval, but not fully disclosed.

  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 core purpose and the contents returned. Every word is necessary, with no redundant information.

  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 a simple signature (1 parameter) and an output schema, reducing the need to describe return values. The description covers the key aspects: full topology, nodes, links, state. However, it lacks explicit statements about read-only behavior, error handling (e.g., if lab doesn't exist), or any postconditions. Despite that, it is complete enough for a straightforward retrieval 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?

  The schema has only one parameter (lab_id, string) with 0% description coverage. The description does not add syntax or format details for lab_id, but the tool name and description make it clear that lab_id identifies the lab. This implicitly provides enough meaning for a single obvious 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 clearly states the tool's function: 'Get full topology detail for a lab: its nodes, links, and their state.' It uses the specific verb 'Get' and names the resource (lab topology) with the exact elements returned (nodes, links, state), distinguishing it from sibling tools that manipulate topology (e.g., build_topology, add_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 provides no explicit guidance on when to use this tool versus alternatives. It only implies retrieval of topology details. There is no mention of prerequisites, such as needing a lab to exist, or when to prefer this over list_labs or get_node_config. The usage context is implicit from the name and read-only nature.

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

• add_nodeA
  3.9/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 for behavioral disclosure. It adds useful context by explaining that configuration is day-0 startup config applied on first boot, but it does not mention side effects such as whether the lab must exist, whether the node is powered on initially, or what happens on failure. This is moderate transparency for a mutating tool.

  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 appropriately sized and front-loaded with the core action. It then uses a clean, readable format to explain the two most important parameters with concrete examples. Every sentence earns its place, and there is no unnecessary verbosity.

  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 9 parameters, no schema descriptions, and no annotations, so a complete description would need to cover more than just the purpose and two parameters. While the core required parameters (lab_id, label, node_definition) are either self-explanatory or explained, optional parameters like image_definition and the behavior of coordinates/resources are left undocumented. The output schema helps, but the description is only partially complete for this complexity.

  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 does add meaning for two key parameters: node_definition (platform id from list_node_definitions with examples) and configuration (day-0 startup config text). However, other parameters like image_definition, ram, cpus, x, and y are not explained, leaving gaps for less obvious 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 'Add a node to an existing lab', using a specific verb and resource that clearly distinguishes this from sibling tools like remove_node and start_node. The resource is unambiguous, and the action is immediately understandable.

  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: adding a node to an existing lab, and it references list_node_definitions() as a prerequisite for choosing node_definition. It does not explicitly name alternatives or exclusion criteria, but the usage context is clear enough for an agent to select it over unrelated sibling tools.

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

• add_linkA
  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 burden of behavioral disclosure. It discloses a key behavior: if interface labels are omitted, the next free interface on each node is used (creating one if needed). This is valuable context beyond the schema, though it does not cover other potential behaviors like error handling or duplicate link prevention.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the core action, and includes a concrete example ('GigabitEthernet0/1'). Every word adds value, with no redundancy or padding.

  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 moderate complexity and the presence of an output schema (which likely documents return values), the description sufficiently explains the main behavior and parameter semantics. It lacks details about prerequisites or edge cases, but it is adequate for confident 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 explains the meaning and optionality of iface_a and iface_b (interface labels, auto-selection when omitted). However, lab_id, node_a_id, and node_b_id are not explicitly described, though their names are fairly self-explanatory in context.

  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 ('Connect') and clearly identifies the resource ('two nodes with a link'). It distinguishes itself from sibling tools like remove_link and add_node by specifying the exact action and object.

  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 clearly implies its use case (establishing a link between nodes) but does not explicitly state when to use it over alternatives or mention exclusions. Sibling tools like remove_link provide implicit contrast, but no direct guidance is given.

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

• get_example_topologyA
  4.1/5.0
  Behavior3/5

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

  No annotations are provided; description indicates the output is a mutable spec and that the tool is for inspection, but does not explicitly state it is read-only or describe error behavior, so some burden remains.

  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?

  Single sentence with examples, front-loads the main action; efficient but includes illustrative use cases that add value without excessive length.

  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 single-param getter with an output schema, the description provides workflow context and parameter sourcing; minor gaps in error handling are acceptable 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 only parameter 'name' is explained as the name of an example topology from list_example_topologies, giving the agent a source of valid values; schema itself has no 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?

  Clearly states it retrieves the 'full node/link spec' for a named example topology, referencing list_example_topologies as source and build_topology as subsequent step, which distinguishes it from sibling tools.

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

  Usage Guidelines4/5

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

  Explains the tool is for inspecting/editing an example topology before building, mentions passing to build_topology; implies alternatives like deploy_example_topology for direct deployment, though not explicitly excluded.

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

• wipe_labA
  4.1/5.0
  Behavior4/5

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

  Discloses key behavioral traits: startup configuration via set_node_config is preserved, runtime/learned state is discarded, and the lab must be stopped. The destructive nature is implicit in 'wipe' but explicitly scoped. Does not address the wait parameter's role in execution timing.

  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: the first states the core action concisely, the second adds essential preservation and prerequisite details. No redundant or filler language.

  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?

  Covers the main functional aspects of a destructive reset: scope (every node), what is preserved, what is discarded, and the prerequisite. Missing explanation of the wait parameter and potential async behavior, but output schema exists and overall guidance is strong.

  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 compensate, but it does not explain the purpose of the 'wait' parameter. 'lab_id' is self-evident, but 'wait' remains ambiguous. The description adds minimal parameter-level meaning 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?

  The description uses a specific action ('wipe') and resource ('every node's disks'), clearly indicating a lab-level reset operation. It distinguishes itself from sibling tools by focusing on disk wipe rather than configuration changes or node operations.

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

  Usage Guidelines4/5

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

  Explicitly states a prerequisite: 'The lab must be stopped first', giving clear context for when to use. However, it does not mention alternatives or situations where one should not use this tool, so it stops short of full guidelines.

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

• set_node_configA
  4.3/5.0
  Behavior4/5

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

  The description notes that the config 'takes effect the next time the node is (wiped and) started,' disclosing a non-immediate effect. Since no annotations are provided, this behavioral context is valuable. It does not mention whether the operation overwrites existing config or require permissions, but the timing detail is beyond what annotations would likely convey.

  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 sentences. The first front-loads the action and object; the second adds timing and a pointer to an alternative. Every sentence serves a purpose without redundancy.

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

  Completeness4/5

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

  With an output schema present and only three simple parameters, the description covers the core purpose, timing, and alternative tool. It lacks elaboration on edge cases or permissions, but the provided information is sufficient for basic invocation given the sibling tool context and required parameters.

  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%, so the description must compensate. It only refers to 'configuration text' without explaining lab_id, node_id, or the expected format/type of the configuration. The description does not add meaningful semantics beyond the schema's type strings.

  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: 'Set a node's day-0 startup configuration text.' This is a specific verb and resource, and it distinguishes from the sibling tool extract_node_config by explicitly noting the alternative for capturing running config.

  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 guidance: 'To capture a running node's current config instead, use extract_node_config.' It also clarifies when the setting takes effect ('next time the node is wiped and started'), telling the agent the timing of the operation.

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

• list_example_topologiesA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description must convey safety and behavior. The word 'List' clearly indicates a read-only operation, and the description specifies the content scope (built-in example architectures). It doesn't disclose additional side effects, but for a simple listing tool this is sufficient.

  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 redundancy, front-loaded with the action and resource, and enriches the description with examples and downstream tool references.

  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, zero parameters, and existence of an output schema, the description provides all necessary context, including how the examples relate to other tools.

  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, so parameter semantics are not a concern. Baseline score of 4 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 the verb 'List' with a specific resource 'built-in example network architectures' and provides concrete examples (OSPF/BGP routing labs, campus, leaf-spine, DMZ). This clearly distinguishes it from sibling tools like list_labs and list_node_definitions.

  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 states that the listed topologies can be deployed directly via deploy_example_topology, fetched via get_example_topology, or customized before calling build_topology. This gives clear context for when to use this tool, though it doesn't explicitly state when not to use alternatives.

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

• list_labsA
  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 must disclose behavior. It states the default filtered view and the permission requirement for show_all, which is critical. It does not explicitly say it is read-only, but 'List' implies no mutation, and the output schema likely covers return shape.

  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 convey the action, default scope, parameter option, and permission requirement with zero filler. The most important information is front-loaded.

  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?

  This is a simple one-parameter list operation with an output schema. The description covers the key context (default scope, admin permission for show_all) and is sufficient for an agent to select and invoke the tool correctly. No significant gaps remain.

  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 coverage is 0%, so the description must explain the parameter. It does: show_all is described as returning every lab on the controller and needing admin rights, while the default false is explained by 'By default only labs owned by the authenticated user.' This adds complete meaning beyond the bare boolean type.

  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 ('List') and resource ('CML labs') and clearly distinguishes the default scope (user-owned) from the admin-only show_all scope. This differentiates it from sibling tools like create_lab, delete_lab, and list_example_topologies.

  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 usage context: by default it lists only the authenticated user's labs, and show_all=True for all labs requires admin rights. It does not explicitly mention alternatives, but no other sibling tool is a direct substitute for listing labs.

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

• list_node_definitionsA
  4.7/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 a non-obvious behavioral trait: availability depends on which reference platform images have been imported. The verb 'List' implies a read-only operation, and the examples add useful domain context. However, it could go further by explicitly stating side effects (e.g., no changes to state) or any pagination/limits, but these are less critical for a list 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 two sentences, each earning its place. The first sentence states the purpose and gives examples; the second provides actionable usage guidance and a necessary caveat. There is no word waste or redundancy.

  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 has no parameters and an output schema exists, the description provides sufficient context for an agent to select and invoke it correctly. It covers what the tool does, how to use the results, and what external factors influence the output. Sibling tools are all about node management, and this description clearly positions list_node_definitions as a prerequisite for add_node.

  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?

  This tool takes no parameters, so there is nothing to document beyond the schema. The description adds value by explaining how to use the returned 'id' in subsequent calls, which indirectly clarifies the semantics of the (zero) input parameters. The baseline for zero parameters is 4, and no additional parameter documentation is needed.

  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 with a specific verb ('List') and resource ('platform/node types'), and includes concrete examples (e.g., iosv, iosvl2) that distinguish it from sibling tools that manage actual nodes rather than definitions. It leaves no ambiguity about what is being listed.

  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 explains when to use this tool and how to consume its output: 'Use the returned id as node_definition when adding nodes.' It also provides a crucial prerequisite context (availability depends on imported images) that helps the agent decide whether to call this tool.

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

• build_topologyA
  5/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 disclosure burden. It reveals that node ids are caller-chosen local keys not sent to CML, that omitted interfaces auto-select the next free interface, and that 'start: True' triggers immediate startup. It also explains the return mapping to real CML node ids, which is critical for subsequent operations.

  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 moderately long but every section earns its place: purpose, usage guidance, node format, link format, start behavior, and return value. It is well-structured and front-loaded with the most important decision-relevant information.

  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?

  This is a complex tool with 5 parameters and no annotations. The description covers the core purpose, when to use it, parameter semantics in detail, and return behavior. Even though an output schema exists, the description adds extra value by explaining the local-to-real node id mapping, making it fully complete for an agent.

  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 0%, but the description fully compensates with inline definitions for nodes, links, and start. It explains the local id role, the structure of node and link objects, and the meaning of start. Even though lab_title and lab_description are not explicitly described, their names and defaults make them self-evident.

  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 'Create a whole lab - nodes, links, and configs - in one call', clearly naming the action and resource. It distinguishes itself from repeated create_lab/add_node/add_link calls by emphasizing the batch nature.

  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?

  Explicitly states when to use: 'when you already have a topology design in mind' rather than calling create_lab/add_node/add_link repeatedly. It also references list_example_topologies as a source of designs, giving clear context and alternatives.

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