Server Quality Checklist

Tool Scores

• update_relationsC
  2.7/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 'Update multiple existing relations' which implies mutation, but doesn't cover critical aspects like required permissions, whether updates are atomic or batched, error handling, or what happens if relations don't exist. This is inadequate 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 that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, 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?

  Given the complexity of updating multiple relations in a knowledge graph, no annotations, no output schema, and poor parameter coverage, the description is insufficient. It lacks details on behavior, parameters, and outcomes, making it incomplete for safe and effective tool invocation by an agent.

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

  Parameters1/5

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

  The description adds no parameter semantics beyond what's implied by the tool name. With 0% schema description coverage and 1 parameter ('relations'), the schema provides structure but no descriptions for nested properties. The description fails to explain what 'relations' contains or how updates are applied, leaving parameters largely undocumented.

  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 ('Update') and resource ('multiple existing relations in the knowledge graph'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'create_relations' or 'delete_relations' beyond the 'update' verb, which is why it doesn't reach a perfect score.

  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., relations must exist), exclusions, or compare it to siblings like 'create_relations' or 'delete_relations', leaving the agent with minimal context for selection.

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

• update_entitiesC
  2.8/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 'update' which implies mutation, but fails to detail critical aspects such as required permissions, whether updates are atomic or batch, error handling for invalid entities, or impact on existing data. This leaves significant gaps in understanding the tool's 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 a single, efficient sentence with no wasted words, making it easy to parse. It front-loads the key action ('update') and resource, though it could benefit from more detail given the tool's complexity.

  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 tool's mutation nature, lack of annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't address return values, error cases, or behavioral nuances, making it inadequate for safe and effective use by an AI agent in this context.

  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 description coverage is 0%, so the description must compensate for undocumented parameters. It only mentions 'entities' broadly without explaining the structure (e.g., 'name', 'entityType', 'observations') or their roles in updates. This adds minimal value beyond the schema, failing to clarify parameter meanings effectively.

  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 ('update') and resource ('multiple existing entities in the knowledge graph'), making the purpose understandable. However, it doesn't distinguish this tool from its sibling 'update_relations' or specify what aspects of entities are updated (e.g., types, observations), leaving room for improvement in sibling differentiation.

  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 'create_entities' for new entities or 'update_relations' for different graph components. It lacks context on prerequisites (e.g., entities must exist) or exclusions, offering minimal usage direction.

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

• add_observationsC
  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 the tool adds observations to existing entities, implying a mutation operation, but doesn't address permissions, side effects, error handling, or response format. This leaves significant gaps for a tool that 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 a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part of the sentence contributes directly to understanding the tool's function.

  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 inadequate. It doesn't explain what 'observations' are in this context, how they're structured, or what happens after addition (e.g., success indicators, error cases).

  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 mention any parameters, and schema description coverage is 0%, so it adds no semantic value beyond what the schema provides. However, with only 1 parameter (an array of observation objects), the baseline is 3 as the schema alone might be minimally sufficient for understanding.

  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 new observations') and target ('to existing entities in the knowledge graph'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'create_entities' or 'update_entities' beyond the focus on observations.

  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 'create_entities' (for new entities) or 'update_entities' (which might also modify observations). It mentions 'existing entities' as a prerequisite but doesn't clarify exclusion criteria or compare with sibling tools.

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

• create_entitiesC
  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 the tool creates entities but doesn't mention permissions required, whether this is a write operation (implied but not explicit), potential side effects, error handling, or response format. This leaves significant gaps in understanding how the tool behaves beyond its 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.

  Conciseness5/5

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

  The description is a single, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It's front-loaded and appropriately sized for the complexity, 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?

  Given the tool's complexity (creating multiple entities in a knowledge graph), lack of annotations, no output schema, and 0% schema description coverage, the description is inadequate. It doesn't cover behavioral aspects, parameter meanings, or expected outcomes, leaving the agent with insufficient information to use the tool effectively beyond its basic intent.

  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 0%, so the description must compensate, but it adds no information about the 'entities' parameter beyond what the schema name implies. The schema itself defines the structure (array of objects with name, entityType, observations), but the description doesn't explain what 'entities' means in context or provide examples, resulting in minimal added value.

  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 ('create multiple new entities') and the target ('in the knowledge graph'), which is specific and unambiguous. However, it doesn't differentiate from sibling tools like 'create_relations' or 'update_entities', which would require more specific context about what entities are versus relations or updates.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives such as 'update_entities' for modifying existing entities or 'create_relations' for linking entities. It lacks any context about prerequisites, timing, or exclusions, leaving the agent to infer usage from the tool name alone.

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

• create_relationsC
  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 for behavioral disclosure. It states this is a creation operation (implying mutation) but doesn't address permissions, side effects, error handling, or response format. The 'active voice' note is trivial and doesn't add meaningful behavioral context for an AI agent.

  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 brief and front-loaded with the core purpose. The second sentence about 'active voice' is arguably unnecessary for tool selection but doesn't significantly detract from conciseness. Overall efficient with minimal waste.

  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 inadequate. It doesn't explain what 'create' entails operationally, how relations are validated, what happens on conflicts, or what the tool returns. Given the complexity and lack of structured support, more contextual information 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 0%, so the description must compensate. It mentions 'relations between entities' which aligns with the 'relations' parameter, but doesn't explain the structure, constraints, or semantics beyond what's implied. The description adds minimal value over the bare schema, meeting baseline expectations but not compensating fully for the coverage gap.

  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 ('Create multiple new relations') and resource ('between entities in the knowledge graph'), which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'update_relations' or 'delete_relations', which would require more precise scope definition.

  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 'update_relations' or 'create_entities'. The mention of 'active voice' is a stylistic requirement rather than functional usage guidance. No prerequisites, exclusions, or comparative context with sibling tools are provided.

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

• delete_entitiesC
  2.9/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 states the action ('Delete') and scope ('multiple entities and their associated relations'), implying a destructive operation, but lacks details on permissions, reversibility, side effects, or error handling. For a deletion 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.

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the key action and resource. There is no wasted language, making it appropriately sized and 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?

  Given the complexity of a deletion operation with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like safety, permissions, or return values, which are critical for such a tool. This leaves significant gaps for an agent to understand the full 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 input schema has 100% description coverage, with 'entityNames' clearly documented as 'An array of entity names to delete'. The description adds no additional meaning beyond this, such as format examples or constraints. With high schema coverage, the baseline score is 3, as the 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 verb ('Delete') and resource ('multiple entities and their associated relations from the knowledge graph'), making the purpose specific and understandable. It distinguishes from siblings like 'delete_observations' or 'delete_relations' by specifying entities and their relations. However, it doesn't explicitly contrast with all siblings, such as 'update_entities' or 'create_entities', which slightly limits differentiation.

  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, exclusions, or comparisons with siblings like 'delete_observations' or 'update_entities'. Without such context, an agent might misuse it, such as deleting when updating is needed.

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

• delete_observationsC
  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 for behavioral disclosure. It states this is a deletion operation but doesn't mention whether deletions are permanent, require specific permissions, have side effects on related data, or provide confirmation feedback. For a destructive tool with zero annotation coverage, this leaves critical behavioral traits unspecified.

  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 wasted words. It's front-loaded with the core action and target, making it immediately understandable 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?

  For a destructive tool with no annotations, no output schema, and 0% schema description coverage, the description is inadequate. It doesn't address critical context like deletion consequences, error conditions, or what happens to the knowledge graph structure after observations are removed. The description should provide more operational guidance given 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 description mentions 'specific observations' and 'entities in the knowledge graph', which aligns with the 'deletions' parameter structure in the schema. However, with 0% schema description coverage, the description doesn't compensate by explaining parameter formats, constraints, or examples. It provides basic semantic context but insufficient detail for proper usage.

  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 ('Delete') and target ('specific observations from entities in the knowledge graph'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'delete_entities' or 'delete_relations', which would require more specificity about scope.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like 'delete_entities' or 'update_entities'. It lacks context about prerequisites, constraints, or typical scenarios for deleting observations rather than other graph elements.

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

• delete_relationsC
  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 the tool deletes relations, implying a destructive mutation, but fails to mention critical details like permissions needed, whether deletions are permanent or reversible, error handling for invalid inputs, or any rate limits. This leaves significant gaps 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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the key action and resource, making it highly concise and well-structured for quick understanding.

  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 mutation tool with no annotations and no output schema, the description is insufficiently complete. It lacks details on behavioral traits (e.g., side effects, error responses), usage context relative to siblings, and output expectations, leaving the agent with significant uncertainty about how to invoke it correctly.

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

  Parameters3/5

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

  Schema description coverage is 100%, with the schema fully documenting the 'relations' array parameter and its nested properties (from, to, relationType). The description adds no additional semantic context beyond implying bulk deletion, so it meets the baseline score of 3 where the schema handles parameter documentation effectively.

  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 ('Delete') and target resource ('multiple relations from the knowledge graph'), which distinguishes it from sibling tools like delete_entities or delete_observations. However, it doesn't specify what constitutes a 'relation' beyond what's implied by the sibling tools, making it slightly less specific than a perfect score.

  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 delete_entities or update_relations. It lacks context about prerequisites, such as whether relations must exist or be deletable, and offers no explicit exclusions or recommendations for sibling tools.

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

• open_nodesC
  2.9/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 full burden. 'Open' suggests some kind of retrieval or access operation, but it doesn't clarify what 'opening' entails - whether it's read-only, if it modifies state, what permissions are required, or what happens when nodes don't exist. The description is too vague about the actual behavior.

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

  Conciseness4/5

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

  The description is a single, efficient sentence that gets straight to the point. There's no wasted verbiage, though it could potentially benefit from slightly more specificity given the lack of annotations and sibling tools that might overlap in functionality.

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

  Completeness2/5

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

  For a tool with no annotations, no output schema, and multiple sibling tools that might overlap in functionality, the description is inadequate. It doesn't explain what 'opening' nodes means, what the expected output looks like, or how this differs from similar tools like 'read_graph' or 'search_nodes'.

  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 the 'names' parameter as 'An array of entity names to retrieve.' The description adds minimal value by mentioning 'by their names' but doesn't provide additional context about naming conventions, format requirements, or what constitutes a valid entity name.

  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 ('Open') and resource ('specific nodes in the knowledge graph'), making the purpose understandable. However, it doesn't distinguish this tool from siblings like 'read_graph' or 'search_nodes' - it's unclear what 'open' means versus 'read' or 'search' in this context.

  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. With siblings like 'read_graph' and 'search_nodes' that might serve similar purposes, there's no indication of when 'open_nodes' is the appropriate choice versus these other tools.

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

• read_graphC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden. It states 'read' which implies a non-destructive operation, but doesn't disclose behavioral traits such as permissions needed, rate limits, what 'entire' entails (e.g., all nodes/relations), or the return format. This is inadequate for a tool with no 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 no wasted words. It's front-loaded with the core action and resource, making it highly concise and well-structured for quick understanding.

  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 knowledge graph tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'read' returns (e.g., nodes, relations, structure) or how 'entire' is defined, leaving significant gaps for an agent to use it correctly.

  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, and schema description coverage is 100%, so there's no need for parameter details in the description. The baseline for 0 parameters is 4, as the description doesn't need to compensate for any gaps, and it appropriately doesn't mention parameters.

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

  Purpose3/5

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

  The description 'Read the entire knowledge graph' clearly states the action (read) and resource (knowledge graph), but it's vague about what 'entire' means and doesn't differentiate from sibling tools like 'search_nodes' or 'open_nodes'. It's not tautological but lacks specificity about scope or format.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives like 'search_nodes' or 'open_nodes'. The description implies a broad read operation but doesn't specify prerequisites, exclusions, or comparative use cases with sibling tools.

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

• search_nodesC
  2.9/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 states the tool searches based on a query but doesn't describe key behaviors: what the search returns (e.g., list of nodes, metadata), how results are formatted, whether it's paginated or limited, or any performance constraints. For a search tool with zero annotation coverage, this is a significant gap.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the core purpose ('search for nodes in the knowledge graph') and adds necessary detail ('based on a query'). There is no wasted language or redundancy, making it highly concise and well-structured.

  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 tool's complexity (search operation with no output schema) and lack of annotations, the description is incomplete. It doesn't explain what the search returns, how results are structured, or any behavioral traits like rate limits. For a search tool, this leaves critical gaps for an AI agent to understand the tool's full 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 input schema has 100% description coverage, with the 'query' parameter fully documented in the schema. The description adds minimal value beyond the schema, only reiterating that the search is 'based on a query.' It doesn't provide additional context like query syntax examples or search scope details. Baseline 3 is appropriate when the 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 action ('search') and target resource ('nodes in the knowledge graph'), with a specific scope ('based on a query'). It distinguishes from siblings like 'read_graph' (which likely reads the entire graph) or 'open_nodes' (which might open specific nodes). However, it doesn't explicitly differentiate from potential sibling search tools (none listed), so it's not a perfect 5.

  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 existing nodes), exclusions (e.g., not for creating or updating nodes), or comparisons to siblings like 'read_graph' (which might retrieve all nodes without filtering). Usage is implied by the verb 'search,' but no explicit context is given.

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