Server Quality Checklist

Tool Scores

• open_nodesB
  3.1/5.0
  Behavior3/5

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

  With no annotations, the description carries the full transparency burden. It does disclose that the operation returns full entity details including observations and timestamps, but it does not explicitly state that it is read-only, describe behavior for missing nodes, or mention any limitations.

  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 only two sentences, with the action stated first and the return value second. It is concise, scannable, and contains no filler or redundant information.

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

  Completeness3/5

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

  Given the tool's simplicity and the presence of an output schema, the description covers the basic action and return content. However, it lacks positioning among sibling read/search tools and, without annotations, omits explicit read-only or no-side-effect statements, leaving meaningful gaps.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It only repeats that names identify the nodes to open, without adding details like exact-match behavior, case sensitivity, or handling of invalid names. The parameter remains minimally documented.

  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 opens specific nodes in the knowledge graph by name and returns full entity details. It is specific and understandable, but it does not explicitly differentiate itself from sibling tools like search_nodes or read_graph.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use open_nodes versus alternatives such as search_nodes or read_graph. It merely states what the tool does without indicating when it is preferred or when it should not be used.

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

• delete_entitiesB
  3.4/5.0
  Behavior3/5

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

  With no annotations, the description must carry the burden. It does disclose the important side effect of deleting associated relations, which is beyond the schema. However, it does not mention reversibility, what happens to observations, or how 'associated relations' is scoped (inbound/outbound).

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

  Conciseness5/5

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

  The description is a single sentence that immediately conveys the action and target, with no unnecessary words or repetition.

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

  Completeness3/5

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

  For a destructive operation, the description is somewhat thin. It does not address whether deletion is atomic, what happens if an entity does not exist, or whether observations linked to the entity are also removed. The presence of an output schema reduces some burden, but gaps remain.

  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 description only says 'multiple entities', which maps to the entityNames parameter but adds no additional meaning about naming conventions, format, or error behavior. Since schema coverage is 0%, the description fails to compensate fully.

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

  Purpose5/5

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

  The description uses the specific verb 'Delete' and clearly identifies the resource as 'entities' from a knowledge graph, while also noting the associated relations. This distinguishes it from sibling tools like delete_relations and delete_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?

  No guidance is provided on when to use this tool versus alternatives (e.g., delete_relations), nor are any prerequisites or exclusions mentioned. The description only states what it does, not when to choose it.

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

• create_relationsA
  3.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 only states the core action and required fields, but does not mention behavior on duplicate relations, error conditions, or whether existing entities are validated. This is insufficient 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 two short, front-loaded sentences with no fluff. It states the purpose and required parameters efficiently, earning its place.

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

  Completeness4/5

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

  The description covers the essential purpose and parameter requirements, and an output schema exists so return details are not needed. However, it could be more complete by mentioning prerequisites like entity existence or duplicate policy, but this is a minor gap for a simple create operation.

  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 is minimal (0% coverage), but the description compensates by explicitly specifying that each relation must have 'from', 'to', and 'relationType' with string types. This adds critical meaning beyond the empty schema objects.

  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 action ('Create') and resource ('multiple new relations between entities in the knowledge graph'), distinguishing it from siblings like create_entities and add_observations. It is specific and unambiguous.

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

  Usage Guidelines2/5

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

  The description provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites (e.g., whether entities must already exist). Usage is only implied by the tool's name and purpose.

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

• search_nodesA
  3.7/5.0
  Behavior3/5

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

  With no annotations provided, the description must carry the full burden of behavioral disclosure. It does disclose key behaviors: case-insensitive token matching across specific fields, and that it returns matching entities with their observations. However, it does not explicitly state that the operation is read-only or side-effect free, nor does it mention pagination, rate limits, or error behavior, 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.

  Conciseness5/5

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

  The description is three short, focused sentences. It front-loads the primary purpose, then adds matching behavior and return content. Every sentence adds useful information, with no fluff or redundancy.

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

  Completeness4/5

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

  For a tool with a single parameter and a provided output schema, the description is quite complete. It covers what is searched, the matching semantics, and what is returned. It does not mention output limits or pagination, but the existence of an output schema helps fill in return structure. Overall, an agent has enough context to invoke the tool 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 schema provides no description for `query` (0% coverage), so the description must compensate. The description explains that the query is matched case-insensitively via token match across entity names, types, and observation content, giving meaningful semantic context beyond the bare schema. It lacks examples or syntax details, but for a single simple string parameter, this is sufficient.

  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 function: 'Search for nodes in the knowledge graph.' It specifies the resource (nodes) and the action (search), and adds detail about matching across entity names, types, and observation content. However, it does not explicitly distinguish this from sibling tools like `search_similar` or `read_graph`, so it falls short of a 5.

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

  Usage Guidelines3/5

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

  Usage context is implied: users would employ this tool when they need to find nodes in the knowledge graph based on text tokens. The description gives no explicit 'when to use' vs 'when not to use' guidance and mentions no alternatives, so it relies on the agent to infer applicability from the tool's name and text.

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

• add_observationsA
  3.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. It discloses the required input fields but does not explain what happens if an entity doesn't exist, whether the operation is atomic, or any side effects beyond adding observations. For a mutation tool, this is a significant gap.

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

  Conciseness5/5

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

  Two sentences: the first states the purpose, the second provides the required item structure. There is no redundant or filler content, and the key information is front-loaded.

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

  Completeness3/5

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

  The description is minimally viable for a simple add operation with one parameter, and it clarifies the input structure well. However, it does not address error handling, prerequisites (entity existence), or success confirmation, which an agent would likely need. Since an output schema exists, return values are not necessary, but the absence of behavioral edge cases keeps it at a 3.

  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 schema only defines an 'observations' array with generic objects (additionalProperties true), so without the description, the required fields are unknown. The description fully compensates by specifying 'Each item must have: entityName (str), contents (list[str])', giving essential type and structure information.

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

  Purpose5/5

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

  The description uses a specific verb ('Add') and identifies the resource ('new observations to existing entities'), which clearly distinguishes it from sibling tools like delete_observations and create_entities. It is unambiguous about what the tool does.

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

  Usage Guidelines3/5

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

  The description implies usage by stating 'Add new observations to existing entities' but does not explicitly mention when to use it instead of alternatives. It provides context (existing entities) but no explicit when-not-to-use or prerequisites beyond that, so it falls short of a strong recommendation.

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

• delete_observationsA
  3.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 fails to disclose that deletion is permanent, irreversible, or the effect of partial matches (e.g., if some observations don't exist). It only states the action and matching requirement, leaving destructive side effects unaddressed.

  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 brief and front-loaded, with two sentences that immediately state the purpose and then give the required input structure. No superfluous detail, making it easy to parse.

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

  Completeness3/5

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

  For a delete operation with a nested input, the description covers the input contract but omits behavioral specifics like idempotency, error handling, and whether the operation is atomic. Since an output schema exists, return values are not needed, but the destructive nature and edge cases are underexplained.

  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 is minimal (one array of objects with no defined properties), so schema coverage is 0%. The description compensates by specifying the exact required fields (entityName as string, observations as list of strings with exact content match), adding essential meaning beyond the schema.

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

  Purpose5/5

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

  The description clearly states the tool deletes specific observations from entities in a knowledge graph, with a specific verb ('Delete') and resource ('observations'). It distinguishes itself from sibling tools like delete_entities and delete_relations by targeting observations only.

  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 on what is needed: each deletion item must have entityName and observations with exact content match. It doesn't explicitly mention alternatives or when not to use, but the targeted phrasing implies it is for observations, not entities or relations, providing adequate usage context.

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

• traverseA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It adds the max depth constraint (3) and clarifies that entities are returned within N hops. However, it does not disclose whether the graph is directed, whether the start node itself is included, or any read-only safety profile. These are material behavioral traits for a traversal tool.

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

  Conciseness5/5

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

  The description is two sentences plus a compact Args list. It is front-loaded with the main purpose, and every sentence contributes useful information. There is no redundancy or fluff.

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

  Completeness4/5

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

  For a simple traversal tool, the description covers the essential parameters and the traversal scope. Since an output schema is present (per context signals), return values are not required in the description. Minor missing details like directionality or start node inclusion are not critical for basic invocation.

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

  Parameters4/5

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

  The schema has no descriptions for its parameters (0% schema coverage), so the description must compensate. Start_node is explained as 'Entity name to start from', and depth is explained as 'Number of hops to traverse' with a default of 1 and an added max of 3, which is not present in the schema. This adds meaningful value beyond the structured definition.

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

  Purpose5/5

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

  The description clearly states a specific action: 'Traverse the graph from a starting node, returning all entities within N hops.' This is a specific verb+resource (traverse graph) and distinguishes from sibling tools like read_graph (likely reads the whole graph) or search_nodes (queries nodes). The resource is unambiguous and the action is concrete.

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

  Usage Guidelines3/5

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

  No explicit when-to-use or alternatives are mentioned. Sibling tools are visible in context but the description does not guide selection. Usage is implied by the traversal semantics, but no exclusions or comparisons exist.

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

• create_entitiesA
  4.1/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden for behavioral disclosure. It only states required fields and the creation action, but does not mention potential side effects, partial success, conflicts with existing entities, permissions, or validation behavior. This leaves significant gaps about what actually happens when the tool runs.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the tool's purpose, and then lists the required structure. No superfluous words or repetition of schema properties. It is efficiently organized and easy to parse.

  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 creation tool, the description covers its main purpose and the required input structure. An output schema exists, so return values are not the description's responsibility. However, it does not mention error handling, atomicity, or constraints on values, which could be relevant for a multi-entity operation. Still, the core information is present.

  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 only defines 'entities' as an array of objects with additionalProperties true, providing zero structure. The description fills this gap by explicitly specifying each entity must have name (str), entityType (str), and observations (list[str]). This is essential, unique information not present in the schema.

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

  Purpose5/5

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

  The description states 'Create multiple new entities in the knowledge graph' with a specific verb ('create') and resource ('entities in the knowledge graph'). This clearly distinguishes it from sibling tools like create_relations or add_observations, which target different graph elements.

  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 clearly implies the use case: you invoke this when you want to add new entities. It does not explicitly name alternatives or list when not to use, but the context is unambiguous for a creation action. This meets the 'clear context, no exclusions' standard.

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

• recentA
  4.1/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of disclosing behavioral traits. It accurately describes the time-window behavior and the hours parameter (default/max), but does not mention potential side effects, ordering, pagination, or whether deletions or other non-included changes are considered. The core behavior is transparent, but more detail could be added.

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

  Conciseness5/5

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

  The description is two sentences, with the primary purpose stated first and the argument detail immediately after. It is front-loaded, concise, and every sentence adds value without redundancy.

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

  Completeness5/5

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

  Given the tool's simplicity (one optional parameter, no nested objects, and an output schema available), the description is sufficiently complete for an agent to select and invoke the tool. It specifies the result type, the time window semantics, and the parameter's constraints, leaving no critical 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?

  Schema coverage is 0%, so the description must compensate. It adds semantic value beyond the schema by explaining 'hours' as a 'look-back window' and specifying a max of 720, which is not present in the input schema. This provides meaningful guidance for the single parameter.

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

  Purpose5/5

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

  The description clearly states the tool returns entities, relations, and observations created or updated in the last N hours, using a specific verb ('Return') and explicit resource types. This distinguishes it from sibling tools like search_nodes or read_graph, which focus on querying or reading the graph without a time-based recency filter.

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

  Usage Guidelines3/5

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

  The description implies usage for retrieving recent changes but does not explicitly state when to use this tool over alternatives, nor does it mention exclusions (e.g., 'use search_nodes for fuzzy or cross-type searches'). The context is clear but not comparative, so guidance is only implied.

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

• delete_relationsA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It explicitly warns that omitting relationType deletes all relations between from and to, which is a critical destructive edge case. It does not mention reversibility or failure modes, but the main behavioral risk is well communicated.

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

  Conciseness5/5

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

  The description is two short sentences; the first states the primary purpose, the second provides the essential input contract and edge-case behavior. No filler or repetition of schema content.

  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 deletion tool with one parameter and an output schema, the description covers the core operation, required fields, and the dangerous omission behavior. It is sufficient for invocation, though it does not address non-existing relations or provide sibling-based selection context (which is more of a usage-guideline gap).

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

  Parameters4/5

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

  The schema only defines a generic 'relations' array with additionalProperties allowed, so parameter information in the description is essential. The description specifies the required per-item keys (from, to, relationType) with types, and explains the effect of omitting relationType. This substantially compensates for the empty schema, though examples or constraints on values are absent.

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

  Purpose5/5

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

  The description opens with a clear action 'Delete multiple relations from the knowledge graph', naming the verb and resource. The relation deletion is distinct from sibling tools like delete_entities and delete_observations, so the purpose is unambiguous.

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

  Usage Guidelines3/5

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

  There is no explicit guidance about when to choose this tool over delete_entities or delete_observations. The description implies usage by describing the deletion operation, but it lacks any when-to-use/when-not-to-use or alternative references.

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

• search_similarA
  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. It discloses the fuzzy matching algorithm and the meaning of the threshold parameter. Although it doesn't explicitly state read-only behavior or edge cases, the 'fuzzy search' wording implies a non-destructive operation, and the threshold semantics add valuable context beyond the schema.

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

  Conciseness5/5

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

  The description is concise and front-loaded, with the core functionality in the first line and parameter details neatly listed. Every sentence adds value, with no wasted words or repetition of schema content.

  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?

  The tool is a simple search with two parameters and an output schema exists, so return value details are not needed. The description covers the search method, parameter semantics, and default threshold, making it complete for the tool's complexity.

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

  Parameters5/5

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

  The input schema has no descriptions (0% coverage), but the description provides clear explanations for both parameters: 'name' is the fuzzy-matched search term and 'threshold' is the minimum similarity score with a default and range. This fully compensates for the schema's lack of descriptions.

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

  Purpose5/5

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

  The description clearly states the tool performs a fuzzy search for entity names using trigram similarity, specifying the verb (search), resource (entity names), and method (trigram similarity). This distinguishes it from sibling tools like search_nodes, which likely performs exact search.

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

  Usage Guidelines3/5

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

  The description implies usage for fuzzy name matching but does not explicitly state when to use this tool versus alternatives or provide exclusions. No when-not or named alternatives are given, so the guidance is implied rather than explicit.

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

• read_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 burden of behavioral disclosure. It reveals that the tool 'loads the full graph into memory — may be large,' which is a critical operational detail. It also explicitly states what will be returned.

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

  Conciseness5/5

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

  Three short sentences: the first states purpose, the second describes the return value, and the third provides a practical warning. No wasted words, and the most important information is front-loaded.

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

  Completeness5/5

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

  For a no-parameter read tool with an output schema available, this description is complete. It covers what the tool does, what it returns, and a key caveat about memory usage. Nothing critical is missing.

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

  Parameters4/5

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

  The tool has zero parameters, so there is no parameter information to add. The baseline of 4 applies here.

  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: 'Read the entire knowledge graph.' It specifies that it returns all entities with observations and all relations, distinguishing it from targeted sibling tools like search_nodes or traverse.

  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 clearly implies this is for full-graph reads, and the warning about memory helps set expectations for when it should be used. It does not explicitly mention alternatives, but the context is clear enough that an agent can infer it should be used when the entire graph is needed.

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