Server Quality Checklist

Tool Scores

• delete_ruleA
  3.6/5.0
  Behavior4/5

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

  With no annotations, the description discloses key behavioral traits: the run log persists with a snapshot of the rule name, and the operation is irreversible. This goes beyond the function name, though it could also mention effects on scheduled actions or related data.

  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 short sentences with no redundant content. The key points (deletion, log retention, irreversibility) are front-loaded and concise.

  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 delete tool with two parameters, the description provides essential behavior (log retention, irreversibility) but is missing usage context such as how to find rule_id or map_id, and does not cross-reference related tools like list_rules or delete_rule_template to aid selection.

  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 descriptions for map_id and rule_id (0% coverage), and the description does not explain what these parameters refer to or how to obtain them. The tool name implies rule_id is the rule identifier, but map_id is ambiguous without 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 clearly states the verb ('Delete') and the resource ('an automation rule'), and adds a specific detail about run log retention, making it distinct from sibling tools like delete_rule_template.

  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 explicit guidance on when to use this tool versus alternatives. It doesn't mention that list_rule_templates or delete_rule_template should be used for templates, and there are no exclusions or context cues beyond the action itself.

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

• get_org_structureA
  3.8/5.0
  Behavior4/5

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

  With no annotations, the description states 'Read-only' and explains that holders and deputies are appointed by admin. This discloses the non-mutating nature and external data source. However, it does not describe return format or pagination, though for a simple read this 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?

  Two concise sentences, front-loaded with purpose, then usage note. No fluff.

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

  Completeness5/5

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

  For a zero-parameter read tool with no output schema, the description covers purpose, read-only nature, and dynamic node id usage. It is reasonably 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?

  No parameters exist, so baseline is 4. The description adds meaning about node ids but no parameters to document.

  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?

  Description clearly states 'Read the organization structure (the org map): positions and functions with node ids, holders and deputies.' This is a specific verb and resource, but it does not explicitly distinguish from sibling tool get_map, despite the parenthetical '(the org map)' which could cause confusion.

  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 on when to use this tool over alternatives. It provides usage of node ids for rule targets but no comparison with get_map or other read tools. This is essentially no guidance.

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

• list_rule_runsA
  4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates a read operation ('Read'), defines output semantics (ok/failed/skipped), and explains the non-obvious 'skipped' status as a safety stop with a detail field. This goes beyond minimal transparency, though it does not mention potential edge cases like empty results or rate limits.

  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 action ('Read the run log'), and each phrase provides useful information: ordering, limit, output fields, and status explanation. No filler or 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?

  Given there is no output schema, the description adequately explains what the tool returns: recent run logs with node, status, action outcomes, and special handling of 'skipped'. It covers the essential behavior for a read-only log tool, though it could mention the response format (e.g., array) or pagination limits beyond 'max 100'. Overall, it is reasonably complete for the tool's 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?

  The input schema documents 'rule_id' as optional and its purpose ('only runs of this rule'), covering 50% of parameter semantics. The description adds contextual meaning by referring to 'a map's automation rules', helping to clarify that 'map_id' is the map identifier. However, it does not explicitly name the parameters or add detail beyond the schema for 'map_id', making it adequate but not exceptional.

  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 starts with 'Read the run log of a map's automation rules', which uses a specific verb ('Read') and resource ('run log'), making the tool's purpose unambiguous. It also specifies key details like ordering (newest first), limit (max 100), and output fields (node, ok/failed/skipped, actions), clearly distinguishing it from sibling tools like list_rules.

  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 it (when you need to inspect rule run history), but it does not explicitly state when not to use it or name alternatives. For example, it does not contrast with list_rules or explain that this is for execution history rather than rule definitions. The context is clear but lacks explicit exclusion guidance.

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

• create_ruleA
  4.2/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden of disclosing behavior. It reveals important non-obvious traits: structural limits (50 rules per map, 10 actions, 20 conditions), the absence of a monthly run quota, forward-only applicability, and the node_id scoping requirement for schedule rules. This exceeds what one would expect from a typical description.

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

  Conciseness5/5

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

  The description is five sentences, each contributing unique value: the core purpose, cross-UI/API/agent behavior, limits/quota, forward-only semantics, and the crucial node_id requirement. It is front-loaded and free of fluff or 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?

  This is a complex, nested tool with no output schema, yet the description covers key constraints and behavioral rules (limits, quota, future events, node_id requirement) that an agent needs before invoking. It omits any mention of return values, which would be helpful given the absence of an output schema, but the overall context is sufficient for selection.

  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 covers 71% of parameters with detailed descriptions, so the description need not repeat them. The added clarification that node_id is 'required for schedule rules whose actions target a node' is genuinely useful, but the description does not compensate for the remaining 29% of parameters lacking schema descriptions (e.g., map_id, enabled).

  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 an automation rule on a map' and explains the WHEN/DO structure, making the tool's purpose unmistakable. It clearly differentiates from sibling tools like list_rules, update_rule, and delete_rule by focusing on creation.

  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 relevant context such as 'Rules run for changes made in the UI, via API and by agents alike' and 'applies only to future events, never retroactively,' which helps an agent understand when creating a rule is appropriate. However, it does not explicitly contrast with alternatives like update_rule or list_rule_templates, 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_rule_templateA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the disclosure burden. It openly states the permission prerequisite and that existing rules are unaffected (no cascade). It does not detail whether deletion is permanent, but the verb 'delete' implies destruction. This is appropriate for a simple delete 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 two concise sentences with no fluff. The verb and object are front-loaded, and the second sentence adds valuable clarification about side-effects.

  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 tool with one parameter, no output schema, and no annotations, the description covers the essential aspects: purpose, permission, and side-effect behavior. It could mention whether deletion is reversible, but for a delete operation this is generally understood.

  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 one parameter (template_id) with no description, and schema description coverage is 0%. The tool name and description make the purpose of template_id obvious, but the description does not explicitly define the parameter's format or source. It partially compensates but leaves some room for interpretation.

  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 a rule template from the library') with a specific resource and scope. It distinguishes itself from sibling tools like delete_rule (which deletes rules) and save_rule_template (which manages templates).

  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 usage context by noting the permission requirement ('author or admin only') and clarifies a key implication ('Rules already created from it are independent copies and stay untouched'). It does not explicitly mention alternatives, but the distinction from sibling tools is implicit.

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

• list_rulesA
  4.2/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 goes beyond a simple 'list' statement by explaining the meaning of last_error (misconfiguration and notification), which is useful context. It does not mention side effects or permissions, but the read-only nature of listing is inherent.

  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, dense sentence that efficiently lists the tool's purpose, the fields returned, and the special meaning of one field. There is no fluff, and every part adds value.

  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 listing tool with one parameter and no output schema, the description is largely complete: it specifies the resource scope, the fields returned, and the significance of last_error. It lacks details about pagination, sorting, or whether all rules (enabled/disabled) are included, but these are not critical for a basic listing operation.

  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 sole parameter map_id is required and has no schema description (0% coverage). The description mentions 'of a map', which contextually identifies map_id as the map identifier, but it does not explicitly define the parameter or its format. This provides minimal compensation for the missing 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 a specific verb ('List') and resource ('automation rules of a map'), clearly distinguishing it from sibling tools like list_rule_runs and list_rule_templates. It also lists the exact fields returned, making the purpose explicit.

  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 clear context by specifying the scope ('of a map') and listing the returned fields, which implies it is for inspecting rule configurations. However, it does not explicitly mention alternatives or when not to use it, though the purpose is distinct enough.

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

• save_rule_templateA
  4.2/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the transparency burden. It discloses key behaviors: templates have no map/node scope, create_subnodes restricted to parent=trigger_node, names must be unique, and update permissions. This is good context beyond the schema.

  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?

  Three sentences, all high-signal: action+scope, key constraints, and uniqueness. No fluff or repetition of schema details.

  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 rich schema and complexity (nested actions, triggers, conditions), the description provides the essential context: what templates are, permission model, uniqueness, and a critical behavioral constraint. It doesn't explain return values, but no output schema is present. Minor gap: no statement about validation or failure modes.

  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 description mentions template_id for updates and name uniqueness, but those are already in the schema. The schema itself provides detailed descriptions for trigger, actions, and conditions, so the description does not need to compensate heavily. 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 uses the specific verb 'Save' and clearly identifies the resource: 'rule shape into the instance-wide template library.' It explicitly distinguishes create from update and notes templates are not rules, differentiating from siblings like create_rule/update_rule.

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

  Usage Guidelines4/5

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

  It provides clear context: create or update with template_id, and that only the author or admin may update. It implies this is for reusable templates (no map, no node scope) rather than instance rules, but does not explicitly name alternatives like create_rule.

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

• update_nodeA
  4.2/5.0
  Behavior4/5

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

  The description reveals important side effects: 'Marking status done may unblock waiting nodes, notify their owners and trigger automations on them.' It also explains clearing behavior for several fields. However, it does not clarify whether omitted fields remain unchanged or are reset, which is a key behavioral gap given no annotations to fill 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?

  Two sentences, no redundancy. The first sentence efficiently lists the fields, the second explains the done-status side effects. Every phrase adds value.

  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 complexity and the absence of annotations and output schema, the description covers most critical aspects: updatable fields, their semantics, and side effects. The main missing element is explicit partial-update semantics and any required permissions.

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

  Parameters4/5

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

  With schema coverage at 46%, the description compensates by listing and explaining all 13 parameters, including enum values for status, deadline format (YYYY-MM-DD), owner email semantics, and clearing with empty strings. It adds meaning beyond the sparse schema for fields like wait_for_children and automation_wanted.

  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 'Update fields of one node' and enumerates all updatable fields, clearly distinguishing this from sibling tools like add_nodes and delete_node by specifying the update action.

  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 clear usage context: updating an existing node's fields. However, it does not explicitly state when to avoid this tool in favor of alternatives (e.g., add_nodes for creation, delete_node for removal), so the guidance is implied rather than explicit.

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

• list_rule_templatesA
  4.3/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 clarifies the template shape and the copy relationship with create_rule, but does not explicitly state read-only behavior, pagination, or return format. The verb 'List' implies read-only, but other behavioral details are missing.

  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, front-loaded sentences with no fluff. The first sentence states the purpose, the second explains usage, earning its place.

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

  Completeness5/5

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

  For a simple parameterless list tool, the description covers what the tool returns (rule templates without scope) and how to use the result (create_rule). No output schema exists, but the description explains the key fields (trigger/conditions/actions) and the copy semantics.

  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 schema coverage is 100% and there is no param info to add. The description enriches understanding by explaining what a template contains (trigger/conditions/actions), which aids interpretation of the output.

  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' with a clear resource 'instance-wide library of rule templates' and explicitly differentiates from siblings by noting templates are 'without a map or node scope'. This makes it distinguishable from list_rules and other related 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?

  It provides explicit usage flow: 'read it and call create_rule on the target map with its trigger/conditions/actions', indicating when to use this tool. However, it does not explicitly name alternative tools for when not to use it, so it falls short of full exclusions.

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

• add_nodesA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the burden of behavioral disclosure and does so well: it explicitly notes that the whole map layout is recomputed, caps calls at 200 nodes, returns the updated tree, and explains the node-vs-task model (owner/deadline makes a task). It does not cover failure modes or permissions, but the disclosed behaviors are valuable and non-obvious.

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

  Conciseness5/5

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

  The description is compact and front-loaded: the first sentence states the action and target, the second adds the crucial task-model semantics, and the third highlights warnings and return value. Every sentence earns its place with useful, non-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?

  Given the nested item structure and lack of an output schema, the description provides essential operational details: return value (updated tree), limits (max 200 nodes), side effects (layout recomputation), and task-model rules. It is sufficient for an agent to invoke the tool confidently, even if it doesn't enumerate all field behaviors or error scenarios.

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

  Parameters4/5

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

  Schema description coverage is only 33%, so the description must compensate. It does by explaining parent_id semantics (omit for apex) and characterizing items as a subtree of nodes. Combined with the schema's field-level descriptions, the parameters are reasonably understandable, though map_id and the items array itself could use slightly more 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 uses a specific verb-resource pair ('Add a subtree of nodes to an existing map') and clearly distinguishes this from siblings such as create_map (whole map) and update_node (existing node). It also clarifies placement under a parent_id or the apex, leaving no ambiguity about the tool's core function.

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

  Usage Guidelines4/5

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

  The description gives clear context for when to use it: adding nodes to an existing map under a specified parent or as apex nodes. It implicitly differentiates from update_node by focusing on adding a subtree. It does not explicitly list exclusions or alternatives, but the usage scenario is unambiguous enough.

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

• create_mapA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description itself discloses key behavioral traits: layout is computed automatically, max 200 nodes per call, and the tool returns the created tree with node ids. This goes beyond a bare 'create' statement. It does not cover permission requirements or side effects like notifications, but for a creation tool the disclosed behaviors are meaningful and helpful.

  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 three sentences, each earning its place: the first states the core purpose, the second explains the mapping of inputs to structure, and the third states constraints and return value. It is front-loaded with the action verb and completely free of filler.

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

  Completeness4/5

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

  The description covers the essential operational context: input transformation, automatic layout, node limit, and the returned tree with ids. With no output schema present, this return value information is valuable. It does not elaborate on the many optional outline node fields, but those are fully documented in the input schema, so the description does not need to repeat them.

  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 top-level parameter schema has 100% description coverage, so the baseline is 3. The description adds value by explaining how parameters relate to the output: title/apex_text become the apex, and outline items become nested nodes. It also introduces the 200-node limit and the return shape, which are not in the schema definitions.

  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+resource construction ('Create a new goal map from an outline') and clearly distinguishes from siblings by focusing on creation as opposed to listing, retrieval, or modification. It also specifies the key transformation (outline to nested nodes) and the automatic layout behavior.

  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 implies usage context by stating this creates a goal map from an outline, which strongly suggests the appropriate time to use it. It also gives a hard constraint (max 200 nodes per call) that helps decide feasibility. However, it does not explicitly mention alternatives like add_nodes for adding to an existing map, so the guidance is implied rather than explicit.

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

• delete_nodeA
  4.4/5.0
  Behavior5/5

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

  No annotations are provided, so the description carries the full burden. It discloses the most critical behaviors: recursive deletion of the whole subtree, irreversibility, and API limitations (cannot delete apex or whole maps). This goes beyond the bare 'delete' semantics and gives the agent essential warnings.

  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?

  Three short sentences, each carrying distinct value: action/scope, restrictions, and irreversibility warning. No filler or repetition, with the most important information front-loaded.

  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 two-parameter delete tool, the description covers the deletion scope, exclusions, and safety advice. It does not mention permissions or side effects on related entities like rules, but given the lack of an output schema and the tool's simplicity, it is reasonably complete. A score of 5 would require covering those potential side effects.

  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. While the parameter names 'map_id' and 'node_id' are self-explanatory, the description does not explicitly map them to their roles or add constraints like format/required prerequisites. The advice to 'double-check the node id' subtly indicates importance but adds no concrete parameter semantics.

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

  Purpose5/5

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

  The description clearly states the action ('Delete a node') and specifies the scope ('INCLUDING its whole subtree'), distinguishing it from node update/add operations. It also clarifies constraints (apex and whole maps cannot be deleted), which reinforces the tool's purpose.

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

  Usage Guidelines4/5

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

  The description provides clear context by stating irreversible nature and advising to 'read the map first', implying the use of a read tool. It also gives explicit exclusions (apex, whole maps), but does not name alternative tools like update_node for replacement or get_map as the read step, so it falls short of explicit alternatives.

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

• update_ruleA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the transparency burden. It discloses important behavioral traits: partial field edits are not merged, edits apply to future events only, and the rule's error state is cleared. This goes beyond the minimum but doesn't cover every edge case (e.g., not found behavior, permissions), so it earns a 4 rather than 5.

  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 three sentences long, front-loaded with the tool's core purpose. Every sentence adds value: the first defines the action, the second explains the two usage modes and the non-merging rule, and the third notes the temporal scope and side effect. No filler or 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?

  Given the tool's complexity (8 parameters, nested objects) and lack of output schema or annotations, the description provides a solid high-level context: update modes, required fields, and side effects. It doesn't explicitly mention how to obtain the rule_id or what the response is, but these are relatively self-evident given the schema and sibling tools. The description is complete enough for correct usage.

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

  Parameters4/5

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

  The schema's top-level properties have no descriptions (0% coverage), so the description must compensate. It adds meaning by explaining that `enabled` can be used alone as a toggle, while a full update requires `name`, `trigger`, `actions`, and optionally `conditions`/`node_id`. This clarifies the parameter relationships and the non-merge semantics, which the schema alone doesn't convey.

  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 with a specific verb ('Update') and resource ('automation rule'). It distinguishes itself from sibling tools by emphasizing the update action and the unique toggle behavior. The phrase 'automation rule' is precise and unambiguous.

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

  Usage Guidelines4/5

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

  The description gives explicit usage guidance by separating the toggle mode ('pass only `enabled`') from the full-replacement mode ('otherwise pass the FULL new shape'). It also warns that partial edits are not merged. While it doesn't explicitly name alternatives like create_rule, the update vs create distinction is implicit and the mode selection is clear.

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

• get_mapA
  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 the burden of behavioral disclosure. It clearly indicates this is a read operation, describes the output content, and implies safety precondition (read before modify). It does not detail edge cases or permissions, but for a straightforward read tool the description 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 two sentences: the first states the purpose and output format, the second gives a usage directive. Every word earns its place, and it is entirely front-loaded with no filler.

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

  Completeness5/5

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

  Given the tool's simplicity (one parameter, no output schema), the description fully covers the essentials: what the tool does, what it returns, and when to invoke it. The safety instruction also adds important operational context, making the description complete for this tool.

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

  Parameters4/5

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

  The schema has 0% description coverage, so the description must compensate for map_id. The phrase 'Read one map' clarifies that map_id identifies the specific map to read. This gives enough semantic context for a single parameter, though it does not provide format or example values.

  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 'Read' and resource 'one map', and clearly details the output as an indented tree with node ids, statuses, deadlines, and owners. This differentiates it from sibling tools like list_maps (which lists maps) and get_org_structure (which reads organization structure).

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

  Usage Guidelines4/5

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

  The description explicitly states when to use the tool: 'Always call this before modifying a map you have not read yet.' This provides a clear context for usage, though it does not explicitly name alternatives or exclusions like using list_maps for a high-level map list.

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

• list_mapsA
  4.5/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It discloses the scope (killBottleneck account), the returned fields, and the behavior of the archived flag (default vs archived). It doesn't explicitly state read-only, but 'List' inherently conveys non-mutating behavior, and the details about fields and filtering add meaningful context.

  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 main purpose, and includes the only parameter guidance without any fluff. Every word adds value.

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

  Completeness5/5

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

  For a simple list tool with one optional parameter and no output schema, the description covers all essential aspects: what is listed, account scope, returned fields, and filtering option. No pagination or rate limit details are necessary for this level of complexity.

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

  Parameters4/5

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

  The schema only defines 'archived' as a boolean with no description (0% coverage). The description compensates by explaining what archived=true does ('list archived maps instead'), implicitly clarifying that false (or omitted) lists non-archived maps. This is sufficient for the single 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: 'List goal maps in the killBottleneck account' with specific details on returned fields (id, title, node count, last update). It distinguishes from siblings like get_map (singular fetch) and create_map (creation).

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

  Usage Guidelines4/5

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

  It provides clear context for when to use the tool (listing maps in the named account) and gives explicit guidance for the archived parameter ('Use archived=true to list archived maps instead'). It does not explicitly name alternative tools for other use cases, but the 'instead' implies default behavior, which is adequate.

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