Server Quality Checklist

Tool Scores

• add_nodeC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states the action is 'Add' (implying a write/mutation operation) but doesn't disclose permissions needed, side effects, error conditions, or what happens on success (e.g., returns node ID?). For a mutation tool with zero annotation coverage, this is inadequate.

  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, direct sentence with zero wasted words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse.

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

  Completeness2/5

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

  For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'Add' entails (e.g., does it return a node ID? update a graph state?), nor does it cover error handling or dependencies. Given the complexity implied by sibling tools like 'set_graph', more context is needed.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema fully documents all three parameters. The description adds no parameter-specific semantics beyond implying the tool operates on a 'canvas', which is already suggested by the schema's 'position' field. Baseline 3 is appropriate when the schema does all the work.

  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 ('Add') and resource ('a single node to the script editor canvas'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from siblings like 'set_graph' or 'remove_node', which would require a more specific scope statement.

  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 like 'set_graph' (which might add multiple nodes) or 'remove_node'. There's no mention of prerequisites, context, or exclusions, leaving the agent to infer usage from tool names alone.

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

• remove_edgeC
  2.9/5.0
  Behavior2/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. 'Remove' implies a destructive mutation, but it doesn't specify whether this is permanent, requires specific permissions, has side effects (e.g., affecting connected nodes), or what happens on success/failure. This is a significant gap for a mutation tool with zero annotation coverage.

  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, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly without unnecessary elaboration.

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

  Completeness2/5

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

  Given the complexity of a destructive operation with no annotations, no output schema, and minimal parameter details, the description is incomplete. It fails to address critical aspects like behavioral traits, error handling, or system impact, which are essential for safe tool invocation in this context.

  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 adds minimal meaning beyond the input schema, which has 0% description coverage. It clarifies that 'edgeId' identifies 'a specific edge', but doesn't explain the format, source, or constraints of the ID. With one parameter and low schema coverage, this provides some compensation but remains basic.

  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 ('Remove') and the target resource ('a specific edge by id'), which provides a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'remove_node' beyond mentioning 'edge' versus 'node', leaving some ambiguity about the broader context of what an 'edge' represents in this system.

  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. It doesn't mention prerequisites (e.g., needing an existing edge), exclusions, or comparisons to siblings like 'remove_node' or 'set_graph', leaving the agent to infer usage from the name alone.

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

• set_variablesC
  2.9/5.0
  Behavior2/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 states that existing variables are overwritten (destructive behavior), but doesn't mention permission requirements, whether the operation is reversible, rate limits, or what happens on success/failure. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

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

  Conciseness5/5

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

  The description is extremely concise with just two sentences that directly state the tool's function and key behavior. Every word earns its place with no redundancy or unnecessary elaboration, making it easy to parse quickly.

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

  Completeness2/5

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

  For a mutation tool with no annotations, no output schema, and 0% schema description coverage, the description is insufficient. It covers the basic purpose and destructive nature but lacks details about permissions, error conditions, return values, or how it fits with sibling tools. More context is needed for safe and effective use.

  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 doesn't explain the 'variables' parameter beyond what's implied by 'script variables list'. With 0% schema description coverage and 1 parameter, the schema provides all structural details (array of objects with name, type, value), but the description adds minimal semantic context. The baseline is 3 since there's only one parameter, but it doesn't compensate for the lack of schema descriptions.

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

  Purpose4/5

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

  The description clearly states the action ('Replace') and resource ('script variables list'), and specifies that existing variables are overwritten. However, it doesn't distinguish this tool from sibling tools like 'set_graph' or 'add_node' which might also manipulate data structures, so it doesn't fully differentiate from alternatives.

  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 like 'add_node' or 'set_graph'. It mentions that existing variables are overwritten, which implies a destructive operation, but doesn't specify prerequisites, timing, or when to choose other tools for variable management.

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

• add_edgeB
  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 carries the full burden of behavioral disclosure. It mentions a prerequisite ('use get_graph first') but fails to describe key traits like whether this is a mutation (implied by 'connect'), potential side effects, error conditions, or response format. This leaves significant gaps for a tool that likely modifies 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?

  The description is appropriately sized with two sentences that are front-loaded and waste-free. The first sentence states the core action, and the second provides essential guidance, earning its place without redundancy.

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

  Completeness2/5

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

  Given the complexity of a tool that likely modifies graph structures (implied by 'connect'), no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits, return values, error handling, and how it interacts with siblings, making it inadequate for safe and effective use.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all four parameters with descriptions like 'The id of the source node (from get_graph).' The description adds minimal value by referencing 'get_graph' for node ids, but doesn't provide additional syntax or format details beyond what the schema offers.

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

  Purpose4/5

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

  The description clearly states the verb ('connect') and resource ('two node ports with an edge'), making the purpose specific and understandable. It distinguishes from siblings like 'remove_edge' by indicating creation rather than deletion, though it doesn't explicitly contrast with all siblings like '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 Guidelines4/5

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

  The description provides clear context by advising to 'use get_graph first to know existing node ids,' which implicitly guides when to use this tool (after obtaining node information). However, it lacks explicit alternatives or exclusions, such as when not to use it versus 'set_graph' or other siblings.

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

• remove_nodeB
  3.4/5.0
  Behavior2/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 mentions the destructive effect ('Remove a node and all its connected edges'), which is helpful, but lacks critical details like whether this operation is reversible, what permissions are required, how it affects the overall graph structure, or what happens if the node doesn't exist. For a destructive operation with zero annotation coverage, this leaves significant gaps.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that immediately states the tool's purpose without any unnecessary words. It's appropriately sized for a single-parameter tool and front-loads the core action, making it easy for an agent to parse quickly.

  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 destructive tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after removal (e.g., whether the graph is automatically saved, what confirmation is provided, or how to verify success). Given the complexity of graph manipulation and the lack of structured safety hints, more behavioral context is needed for the agent to use this tool confidently.

  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 description coverage is 100% (the nodeId parameter is fully documented in the schema), so the baseline is 3. The description doesn't add any parameter-specific information beyond what's already in the schema, such as format examples, valid node ID patterns, or relationships to other graph elements.

  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 specific action ('Remove') and target resources ('a node and all its connected edges'), distinguishing it from sibling tools like remove_edge (which only removes edges) and add_node/add_edge (which create rather than delete). It precisely communicates the scope of the operation beyond just the node itself.

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

  Usage Guidelines3/5

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

  The description implies usage context (removing from 'the editor') but does not explicitly state when to use this tool versus alternatives like remove_edge or set_graph. No guidance is provided on prerequisites, error conditions, or specific scenarios where this tool is preferred over others in the graph manipulation toolkit.

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

• set_graphA
  4/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 behavioral disclosure. It clearly states this is a destructive replacement operation ('All existing nodes and edges are replaced'), which is crucial information. However, it doesn't mention potential side effects, error conditions, permission requirements, or what happens to related resources like variables.

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

  Conciseness5/5

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

  The description is extremely concise with just two sentences that each earn their place. The first sentence states the core action, the second provides crucial behavioral context. There's zero wasted language, and the most important information ('Replace the entire script graph') is front-loaded.

  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 destructive mutation tool with no annotations and no output schema, the description does the minimum by clearly stating this replaces everything. However, it doesn't address what the tool returns, error handling, or provide any guidance on parameter usage. Given the complexity implied by the schema (nested objects for nodes/edges), more context would be helpful.

  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 tool description provides no information about the three parameters (nodes, edges, variables). While the description mentions 'script graph' and 'nodes and edges', it doesn't explain what these parameters represent, their structure, or how they should be formatted. The description fails to compensate for the complete 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 clearly states the specific action ('Replace the entire script graph at once') and resource ('script graph'), distinguishing it from siblings like add_node, remove_edge, or set_variables. It explicitly mentions that all existing nodes and edges are replaced, which differentiates it from incremental modification tools.

  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 on when to use this tool ('Use this to build a complete script from scratch') and implicitly when not to use it (for partial modifications, where siblings like add_node or remove_edge would be more appropriate). It clearly positions this as a wholesale replacement operation.

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

• get_graphA
  4.1/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 discloses that the tool returns 'nodes, edges, and variables' and has a prerequisite ('editor tab must be open'), but does not cover other behavioral aspects like error handling, performance, or side effects. It adds some value but is not comprehensive.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the core purpose, and every sentence earns its place by specifying the return value and prerequisite condition. It is efficiently structured with zero waste.

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

  Completeness3/5

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

  Given the tool's moderate complexity (retrieving graph data with a prerequisite), no annotations, and no output schema, the description is adequate but has gaps. It explains what is returned but not the format or structure of 'nodes, edges, and variables', leaving room for improvement in completeness.

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

  Parameters4/5

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

  The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter details, which is appropriate. Baseline is 4 for zero parameters, as it avoids unnecessary information.

  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 specific action ('Get') and resource ('current script graph from the open editor tab'), and distinguishes from siblings like 'set_graph' (which modifies) and 'get_docs' (which retrieves documentation). It precisely identifies what this tool does.

  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 for when to use it ('The editor tab must be open'), but does not explicitly mention when not to use it or name alternatives. It implies usage in scenarios where the graph state is needed, but lacks explicit exclusions or sibling comparisons.

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

• get_docsA
  4.4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries full burden. It indicates this is a read operation ('Get') and suggests it's foundational ('first'), but doesn't disclose behavioral traits like rate limits, authentication requirements, response format, or whether it returns static or dynamic documentation.

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

  Conciseness5/5

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

  Two sentences with zero waste - the first states purpose with specific scope, the second provides crucial usage guidance. Every word earns its place, and the most important information (what it does and when to use it) is 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 0-parameter tool with no output schema and no annotations, the description provides good coverage of purpose and usage. However, it doesn't describe the return format or content structure, which would be helpful given the lack of output schema. The guidance about calling it first compensates somewhat for this gap.

  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 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, focusing instead on the tool's purpose and usage 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 specific verb 'Get' and the resource 'full documentation' with detailed scope including '247afk block editor, node types, connection rules, graph format, and examples'. It distinguishes from sibling tools like 'get_graph' by focusing on documentation rather than graph data.

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

  Usage Guidelines5/5

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

  The description provides explicit usage guidance with 'Call this first before building any script', establishing clear temporal sequencing and distinguishing it from all sibling tools that perform graph operations rather than preparatory documentation retrieval.

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