Server Quality Checklist

Tool Scores

• create_graphA
  3.7/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. While it describes graph types and design guidelines, it does not disclose critical behavioral traits such as whether creation is idempotent, what permissions are required, how errors are handled, or what the response looks like. For a creation tool with zero annotation coverage, this is a significant gap in transparency.

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

  Conciseness3/5

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

  The description is appropriately front-loaded with the core purpose, but it becomes lengthy with detailed design guidelines for six graph types. Some sentences, like the repetitive 'Recommended to...' patterns, could be condensed. While informative, the structure could be more concise without losing essential context.

  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 complexity of creating knowledge graphs with multiple types, no annotations, and no output schema, the description is partially complete. It covers graph types and design guidelines well but lacks details on behavioral aspects, error handling, and response format. For a tool with 3 parameters and no structured safety hints, more comprehensive context would be beneficial.

  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 33% (only the 'type' parameter has a description). The description compensates by elaborating on the 'type' parameter with detailed guidelines for each graph type, adding substantial meaning beyond the schema's enum values. However, it does not provide semantics for 'name' or 'description' parameters, leaving them partially undocumented.

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

  Purpose5/5

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

  The description explicitly states the tool's purpose: 'Create a new knowledge graph.' It distinguishes this tool from siblings like add_node, add_edge, or list_graphs by focusing on initial graph creation rather than modification or querying. The description provides specific details about supported graph types, making the purpose clear and distinct.

  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 this tool by detailing six graph types and their recommended design guidelines. However, it does not explicitly state when not to use this tool or mention alternatives like update_resource or save_resource for modifying existing graphs. The guidelines are helpful but lack explicit exclusions or comparisons to sibling tools.

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

• get_creation_guidelinesA
  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 effectively describes the tool's role as a prerequisite for 'save_resource', indicating it's a read-only operation that fetches guidelines before creation actions. It mentions the return data structure and content, which helps the agent understand what to expect. However, it doesn't address potential limitations like rate limits, authentication needs, or error conditions.

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

  Conciseness3/5

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

  The description is structured with clear sections (Use cases, Usage recommendations, Return data), which aids readability. However, it includes some redundancy (e.g., repeating 'Get creation guidelines' in different forms) and could be more front-loaded; the core purpose is stated upfront, but the detailed sections add length without always adding proportional value. Some sentences like 'Recommended to save guidelines for team reference' are less critical.

  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 low complexity (1 parameter, no output schema, no annotations), the description is quite complete. It explains the purpose, usage context, return data structure, and ties it to sibling tools. The absence of an output schema is compensated by detailing the return format. However, it could briefly mention error handling or confirm it's a safe read operation, though the 'prerequisite' context implies non-destructive behavior.

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

  Parameters3/5

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

  The input schema has 100% description coverage, with the single parameter 'type' fully documented in the schema (including enum values and descriptions). The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline of 3. It does provide context about when to use specific types (e.g., 'all: Get all guidelines (recommended)'), but this is implied rather than explicit in the description text.

  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's purpose: 'Get creation guidelines and standards for SVG graphics and Markdown documents.' It specifies the resource (guidelines) and the target domains (SVG graphics, Markdown documents). However, it doesn't explicitly differentiate from sibling tools like 'get_node_details' or 'list_graphs' which might also provide informational content, though those appear to be graph-related rather than guidelines-focused.

  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: 'This tool is a prerequisite for the save_resource tool and must be called before creating and saving any resources.' It lists specific use cases (e.g., before creating SVG visualizations, before creating Markdown documents) and gives clear recommendations (e.g., 'Call this tool before starting any resource creation'). It also mentions an alternative/successor tool ('save_resource') for the next step.

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

• update_edgeA
  4.1/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full burden and does well: it discloses that this is a mutation tool ('Modify edges'), specifies required companion tools, advises partial updates ('Only update fields that need to be modified'), and describes the return data structure. It doesn't mention permissions, rate limits, or error conditions, but covers core behavioral aspects.

  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 well-structured with clear sections (purpose, use cases, recommendations, return data). It's appropriately sized for a mutation tool with complex prerequisites. Some redundancy exists between 'use cases' and parameter descriptions, but overall it's efficient and front-loaded with essential 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?

  For a mutation tool with no annotations and no output schema, the description provides substantial context: clear purpose, detailed usage workflow, partial update guidance, and full return data specification. It doesn't cover error cases or side effects, but given the schema richness and workflow guidance, it's mostly complete.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description adds minimal parameter semantics beyond the schema - it lists use cases that map to parameters but doesn't provide additional syntax, format, or constraint details. Baseline 3 is appropriate when schema does the heavy lifting.

  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's purpose: 'Modify edges in the knowledge graph.' It specifies the resource (edges) and action (modify/update). However, it doesn't explicitly differentiate from sibling tools like 'update_node' or 'update_resource' beyond the edge focus.

  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 recommendations with numbered steps, including prerequisites ('First call list_graphs...'), companion tools ('get_node_details'), and post-update verification ('call get_node_details again to confirm'). It clearly guides when and how to use this tool.

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

• update_resourceA
  4.1/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full burden and does well by specifying the mutation nature ('update'), prerequisites (must use other tools first), and operational constraints ('maintain consistency'). It also describes return data format. However, it doesn't mention potential side effects, error conditions, or permission requirements that would be helpful for a mutation tool.

  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 well-structured with clear sections (purpose, use cases, usage recommendations, return data) and each sentence adds value. It's appropriately sized for a mutation tool with prerequisites. Some minor redundancy exists between 'use cases' and the purpose statement, but overall it's efficiently organized.

  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 mutation tool with no annotations and no output schema, the description does well by explaining prerequisites, usage patterns, and return format. It provides operational context missing from structured fields. The main gap is lack of error handling or side effect information, but given the comprehensive usage guidance and return data description, it's mostly complete.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema descriptions. It mentions what fields can be updated but doesn't provide additional semantic context about parameter usage or constraints.

  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's purpose as 'Update resource information in the knowledge graph' with specific mention of what can be modified (title, description, metadata, documentation). It distinguishes from siblings like 'update_node' and 'update_edge' by focusing specifically on resources. However, it doesn't explicitly contrast with 'save_resource' which might have overlapping functionality.

  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, step-by-step usage recommendations including prerequisites (must use list_graphs and get_node_details first), specific sequencing instructions, and guidance on what to update ('only update fields that need to be modified'). It also mentions maintaining consistency in naming, giving clear operational context.

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

• add_nodeA
  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 full burden. It clearly indicates this is a creation/mutation operation ('Add a node'), describes the return data structure, and provides context about different graph types. However, it doesn't mention permissions, error conditions, or idempotency behavior that would be helpful for a mutation tool.

  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 well-structured with clear sections (purpose, use cases, recommendations, return data) and each sentence adds value. It could be slightly more concise by integrating some of the use cases into the initial statement, but overall it's efficiently organized.

  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 6-parameter mutation tool with no annotations and no output schema, the description provides substantial context: clear purpose, usage guidelines, parameter guidance, and detailed return format. The main gap is lack of error handling or side effect information, but otherwise it's quite comprehensive given the constraints.

  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 17%, but the description compensates well. It explains the relationship between node types and graph types (mapping to the 'type' enum), provides context for 'filePath' ('Link related files when applicable'), and explains 'metadata' purpose. However, it doesn't explicitly mention 'graphId' or 'name' 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 ('Add a node') and resource ('to the knowledge graph'), with specific examples of different node types for various graph contexts. It distinguishes from siblings like 'create_graph' (which creates the graph itself) and 'update_node' (which modifies existing nodes).

  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 recommendations including prerequisites ('First create the graph using create_graph'), selection criteria ('Select the appropriate node type based on graph type'), and best practices. It also implicitly distinguishes from alternatives by focusing on node creation rather than modification or deletion.

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

• update_nodeA
  4.3/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 effectively describes the mutation nature ('Modify'), outlines a multi-step workflow with prerequisites, specifies that only certain fields should be changed, and details the return data structure. However, it lacks information on error conditions, permissions, 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.

  Conciseness4/5

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

  The description is well-structured with clear sections (purpose, use cases, usage recommendations, return data) and uses bullet points for readability. It is appropriately sized but includes some redundancy, such as listing return data fields that could be inferred from context, slightly reducing efficiency.

  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 complexity of a mutation tool with no annotations or output schema, the description provides substantial context: purpose, prerequisites, workflow, and return data. It covers key aspects but omits details like error handling or side effects, which would enhance completeness for a high-risk 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 input schema has 100% description coverage, so the baseline is 3. The description does not add significant parameter-specific information beyond what's in the schema, though it contextualizes parameters by mentioning use cases like 'Update basic node information' and 'Update file paths,' which loosely map to the optional fields.

  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 ('Modify nodes') and resource ('in the knowledge graph'), distinguishing it from sibling tools like add_node (creation) or delete_node (removal). It provides concrete use cases that illustrate the scope of modifications possible.

  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 names prerequisite tools (list_graphs and get_node_details) and provides a step-by-step workflow for proper usage. It includes specific recommendations like 'Only update fields that need to be modified' and 'After updating, call get_node_details again to confirm changes,' offering clear guidance on when and how to use this tool.

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

• get_node_detailsA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's dependency on list_graphs, outlines four specific use cases, and details the return data structure. However, it doesn't mention potential error conditions, rate limits, or authentication requirements.

  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 well-structured with clear sections (Use cases, Usage recommendations, Return data) and front-loads the core purpose. While comprehensive, some redundancy exists between the initial statement and later sections, preventing a perfect score.

  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 complexity (dependency on another tool, detailed return structure) and absence of both annotations and output schema, the description provides complete contextual coverage. It explains prerequisites, use cases, usage workflow, and detailed return format, compensating for the lack of structured metadata.

  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%, so the schema already documents both parameters thoroughly. The description reinforces that parameters 'must be obtained from list_graphs response' but doesn't add significant semantic value beyond what's in the schema descriptions. This meets the baseline expectation for high schema coverage.

  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 ('Get detailed information') and resource ('about a specific node in the graph'). It distinguishes this read operation from sibling tools like update_node, delete_node, and add_node by focusing on retrieval rather than modification.

  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 recommendations with step-by-step instructions, including when to use this tool ('First call list_graphs to get the node list') and how to obtain required parameters. It clearly positions this tool as dependent on list_graphs for parameter acquisition.

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

• publish_graphA
  4.5/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 effectively describes key behavioral traits: the tool changes graph status, published graphs can still be modified, and version management is recommended. However, it doesn't mention error conditions (e.g., what happens if graph is already published) or rate limits, leaving some gaps.

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

  Conciseness3/5

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

  The description is appropriately front-loaded with the core purpose, but it includes extensive sections (Prerequisites, Usage recommendations, Return data) that, while helpful, make it somewhat verbose. Some sentences in the usage recommendations could be condensed without losing value, affecting efficiency.

  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 complexity (status-changing operation), no annotations, and no output schema, the description does a good job covering purpose, prerequisites, usage, and return values. However, it lacks details on error handling or side effects (e.g., impact on related resources), which would enhance completeness for this type of tool.

  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?

  The input schema has 0% description coverage and only one parameter (graphId). The description doesn't explicitly mention parameters, but it strongly implies the graphId parameter through context (e.g., 'Graph must exist and be in draft status'). Given the low schema coverage and single parameter, the description compensates well by clarifying what the parameter represents.

  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 ('Publish a knowledge graph') and the effect ('changing its status from draft to published'), distinguishing it from sibling tools like create_graph (creation) or list_graphs (listing). It provides a precise verb+resource combination with explicit outcome.

  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 (when a graph exists in draft status) and includes detailed prerequisites (graph must be in draft, content should be complete) and usage recommendations (e.g., first use list_graphs to check status). It clearly distinguishes this from other tools by focusing on status transition.

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

• delete_edgeA
  4.6/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 behavioral disclosure and does so comprehensively. It explicitly states the operation 'cannot be undone,' clarifies that 'deleting edges won't affect related nodes,' explains the need to call get_node_details again to view updated relationships, and describes the return data format including specific fields like id and deletedAt.

  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 well-structured with clear sections (Use cases, Usage recommendations, Important notes, Return data) and front-loads the core purpose. While comprehensive, some sentences could be more concise, such as the detailed 4-step usage recommendations that partially repeat schema information. Overall, it's appropriately sized for a destructive operation.

  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 destructive tool with no annotations and no output schema, the description provides exceptional completeness. It covers irreversible nature, safety measures (confirmDelete), prerequisites (list_graphs, get_node_details), effects on the system, return data format, and specific use cases. This fully compensates for the lack of structured metadata.

  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?

  With 100% schema description coverage, the baseline is 3. The description doesn't add significant parameter semantics beyond what's already in the schema descriptions, though it does reinforce the confirmDelete safety measure in the usage recommendations. The schema already documents that graphId must come from list_graphs and edgeId from get_node_details relationships.

  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 ('Delete edges') and resource ('from the knowledge graph'), distinguishing it from sibling tools like delete_node, delete_resource, and update_edge. It provides a precise verb+resource combination that leaves no ambiguity about the tool's function.

  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 versus alternatives, specifying it 'must be used in conjunction with list_graphs and get_node_details tools' and listing three specific use cases. It also includes detailed usage recommendations with a 4-step process, making it clear how this tool fits into the workflow compared to other graph manipulation tools.

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

• list_graphsA
  4.6/5.0
  Behavior4/5

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

  Since no annotations are provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior by explaining its role as the 'main tool for getting information about existing graphs' and detailing return data structure, including nested nodes. However, it lacks information on potential side effects, rate limits, or error handling, which are important for a tool with no annotations, preventing a perfect score.

  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 well-structured with clear sections (e.g., Use cases, Usage recommendations, Return data), making it easy to scan. It is appropriately sized for the tool's complexity, but some redundancy exists (e.g., repeating filtering concepts in multiple sections), which slightly reduces efficiency. Overall, it's front-loaded with key information and avoids unnecessary 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?

  Given the tool's complexity (listing with filtering), lack of annotations, and no output schema, the description provides comprehensive context. It covers purpose, usage guidelines, behavioral aspects, and detailed return data, compensating for the absence of structured output schema. This makes it complete enough for an AI agent to understand and invoke the tool correctly without gaps.

  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 100% description coverage, so the baseline is 3. The description adds value by explaining the purpose of filtering ('Filter graphs by status, such as viewing all drafts or published graphs') and linking parameters to use cases, which enhances understanding beyond the schema's enum descriptions. However, it doesn't provide additional syntax or format details, so it doesn't fully maximize the potential for 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 explicitly states the tool's purpose as 'List all knowledge graphs with support for filtering by status and type,' which is a specific verb+resource combination. It distinguishes itself from sibling tools like 'create_graph' or 'get_node_details' by focusing on listing existing graphs rather than creating new ones or querying specific nodes. The description clearly articulates what the tool does without being tautological.

  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 recommendations, including when to use this tool (e.g., 'First call this tool to get the graph list and node information') and how it integrates with sibling tools (e.g., 'Use these IDs to call other tools like add_edge, get_node_details'). It also offers context on when to use it, such as confirming a graph's status before operations, making it clear when this tool is appropriate versus alternatives.

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

• add_edgeA
  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 of behavioral disclosure. It effectively describes that this is a creation/mutation operation (implied by 'Add edges' and 'Newly created edge information'), specifies prerequisites that constrain usage, and provides context about relationship types and edge properties. However, it doesn't mention potential error conditions, rate limits, or authentication requirements that would be helpful for a mutation 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 well-structured with clear sections (purpose, prerequisites, usage recommendations, return data) and every sentence adds value. It's appropriately sized for a 6-parameter mutation tool with complex prerequisites, providing necessary information without redundancy. The front-loaded purpose statement immediately communicates the tool's function.

  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 mutation tool with 6 parameters, no annotations, and no output schema, the description provides substantial context including prerequisites, usage guidance, and detailed return format. It covers the essential information needed to use the tool correctly. The only minor gap is the lack of explicit error handling information, but overall it's quite complete given the complexity.

  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?

  With only 17% schema description coverage, the description compensates significantly by explaining parameter semantics. It clarifies that sourceId and targetId must refer to existing nodes, edge type must match graph type, labels should be meaningful, and weight represents relationship strength. The description adds substantial value beyond the minimal schema documentation, especially for the type parameter where it provides context about how edge types relate to different graph types.

  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: 'Add edges in the knowledge graph, connecting two nodes to build a relationship network.' It specifies the verb ('Add edges'), resource ('knowledge graph'), and distinguishes it from siblings like add_node (which adds nodes rather than edges) and update_edge (which modifies existing edges rather than creating new ones).

  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 recommendations including prerequisites ('Must first create a graph', 'Source and target nodes must already exist') and specific guidance on when to use ('First use list_graphs to get graph and node information', 'Confirm both source and target nodes exist'). It also distinguishes from alternatives by specifying edge type constraints and recommending meaningful labels and weight parameters.

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

• save_resourceA
  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 full burden and does well by explaining the tool's role in a workflow, mentioning batch saving capability, and detailing the return data structure. However, it doesn't explicitly state that this is a write/mutation operation (though implied by 'save'), nor does it mention error conditions or permissions required.

  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 well-structured with clear sections (purpose, use cases, usage recommendations, return data) and every sentence adds value. It's appropriately sized for a complex tool with workflow dependencies, with no redundant or unnecessary 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?

  For a mutation tool with no annotations and no output schema, the description provides excellent completeness. It explains the tool's purpose, workflow dependencies, use cases, and detailed return data structure, giving the agent sufficient context to use the tool correctly despite the lack of structured metadata.

  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 100% schema description coverage, the baseline is 3. The description adds value by explaining how parameters relate to other tools (graphId from list_graphs, title/content rules from get_creation_guidelines) and clarifying the optional nature of nodeId association. However, it doesn't provide additional semantic context beyond what's in the schema descriptions.

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

  Purpose5/5

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

  The description clearly states the tool's purpose with specific verbs ('save AI-generated SVG graphics or Markdown documents') and resources ('to the knowledge graph'). It distinguishes from siblings by focusing on saving resources rather than creating/deleting graphs/nodes/edges or updating existing resources.

  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 recommendations with a numbered workflow, naming specific sibling tools (get_creation_guidelines, list_graphs, get_node_details) for prerequisites and follow-up actions. It also lists three specific use cases, giving clear context for when to use this tool.

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

• delete_nodeA
  4.8/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 and does so comprehensively. It discloses critical behavioral traits: the operation is irreversible, it deletes related edges, it unlinks but doesn't delete associated resources, requires confirmation parameter, and has safety recommendations. This provides rich behavioral context beyond basic parameter documentation.

  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 well-structured with clear sections (Use cases, Usage recommendations, Important notes, Return data) and front-loads the core purpose. While comprehensive, some sentences could be more concise, and the return data section might be better placed elsewhere since there's no output schema.

  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 destructive mutation tool with no annotations and no output schema, the description provides exceptional completeness. It covers purpose, prerequisites, use cases, behavioral consequences, safety measures, parameter context, and even documents the return format. This gives the agent everything needed to use this tool correctly and safely.

  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 100% schema description coverage, the baseline is 3. The description adds meaningful context by explaining why graphId and nodeId must come from list_graphs, emphasizing confirmDelete as a safety measure, and providing the rationale for parameter usage in the usage recommendations section. This adds value beyond the schema's technical 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 ('Delete nodes') and resource ('from the knowledge graph'), distinguishing it from sibling tools like delete_edge, delete_resource, and unlink_resource. It provides a focused purpose that goes beyond just restating the tool name.

  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 (three specific use cases) and detailed prerequisites (must be used with list_graphs, get_node_details for checking). It also clearly distinguishes this from other deletion tools by specifying it deletes nodes specifically, not edges or resources.

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

• delete_resourceA
  4.8/5.0
  Behavior5/5

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

  With no annotations provided, the description carries full burden and excels at disclosing critical behavioral traits: irreversible nature ('cannot be undone', 'cannot be recovered'), destructive side effects ('will also delete the physical file', 'automatically unlink from all nodes'), safety mechanisms (confirmDelete requirement), and workflow dependencies. It provides comprehensive behavioral context beyond basic function.

  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 well-structured with clear sections (Use cases, Usage recommendations, Important notes, Return data) and front-loaded core functionality. While slightly verbose, every sentence earns its place by providing essential guidance for a destructive operation. The structure enhances readability without unnecessary repetition.

  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 destructive tool with no annotations and no output schema, the description provides exceptional completeness: it covers purpose, prerequisites, irreversible consequences, safety mechanisms, use cases, step-by-step workflow, side effects, and return format. It addresses all critical aspects needed for safe and correct tool invocation in this context.

  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 100% schema description coverage, the baseline is 3, but the description adds significant value by explaining parameter dependencies and semantics: graphId must come from list_graphs, resourceId must come from get_node_details resources array, and confirmDelete is a safety measure. It provides practical context beyond the schema's technical 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 specific action ('Delete resources') and target ('from the knowledge graph'), distinguishing it from sibling tools like delete_node, delete_edge, and unlink_resource which target different graph elements. It provides a precise verb+resource combination that leaves no ambiguity about the tool's function.

  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, step-by-step usage recommendations including prerequisite tools (list_graphs, get_node_details), confirmation requirements, and backup advice. It clearly distinguishes when to use this tool versus alternatives by specifying the target (resources) and workflow dependencies, with no misleading guidance.

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

• unlink_resourceA
  4.8/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 and excels. It discloses critical behavioral traits: the tool only removes associations without deleting resources, resources remain usable by other nodes, associations can be re-established, and it includes important safety recommendations about confirming impacts and recording changes.

  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 well-structured with clear sections (Use cases, Usage recommendations, Important notes, Return data) and every sentence adds value. It could be slightly more front-loaded by moving the core purpose statement earlier, but overall it's efficient and organized.

  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 mutation tool with no annotations and no output schema, the description provides excellent completeness. It covers purpose, workflow integration, behavioral implications, parameter context, and even documents the return data structure, compensating fully for the lack of structured metadata.

  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 description coverage is 100%, so the baseline is 3. The description adds value by explaining the parameter sources (e.g., 'must be obtained from list_graphs return data' is implied in the usage recommendations), but doesn't provide additional syntax or format details beyond what the schema already documents. It earns a 4 for contextual integration.

  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 ('unlink resource associations from nodes') and distinguishes it from sibling tools like 'delete_resource' by emphasizing it only removes associations, not the resource itself. The verb+resource combination 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 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, including a prerequisite workflow (use with 'list_graphs' and 'get_node_details'), specific use cases (adjust, remove incorrect, reorganize), and recommendations for confirmation and recording changes. It clearly distinguishes from deletion operations.

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