Server Quality Checklist

Tool Scores

• create_connectionC
  2.8/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. It mentions 'Create' implying a write operation but doesn't disclose behavioral traits like permissions needed, whether connections are reversible, error conditions, or rate limits. The phrase 'its good to have connected memories' adds minimal context without practical details.

  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 brief with one sentence, but 'its good to have connected memories' is redundant and doesn't add operational value. It could be more front-loaded with essential usage information, though it avoids excessive verbosity.

  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 no annotations and no output schema, the description is incomplete for a mutation tool. It lacks details on what happens upon creation, error handling, or return values, leaving significant gaps for an AI agent to understand the tool's behavior fully.

  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 parameters are well-documented in the schema. The description adds no additional meaning beyond the schema, such as explaining relationship types or property usage. Baseline 3 is appropriate 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 'Create' and resource 'connection between two memories', making the purpose understandable. However, it doesn't distinguish this from sibling tools like 'update_connection' or specify what makes a connection 'good' versus just possible.

  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 minimal guidance with 'its good to have connected memories', which is vague and doesn't specify when to use this tool versus alternatives like 'update_connection' or prerequisites. No explicit when/when-not or alternative tool references are included.

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

• search_memoriesC
  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 mentions 'search and retrieve' which implies a read-only operation, but doesn't specify permissions needed, rate limits, pagination behavior, error conditions, or what 'retrieve' entails (e.g., full memory details vs summaries). For a search tool with 6 parameters and no annotations, this leaves significant behavioral gaps.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the core purpose ('Search and retrieve memories from the knowledge graph') with zero wasted words. It's appropriately sized for a tool with a clear primary function, 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 6 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'retrieve' returns (e.g., memory objects, IDs, or summaries), how results are structured, or any behavioral aspects like error handling. For a search tool with moderate complexity, this leaves too much unspecified for reliable agent use.

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

  Parameters3/5

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

  Schema description coverage is 100%, with each parameter well-documented in the schema (e.g., query searches for ANY word, depth defaults to 1, limit max 200). The description adds no additional parameter information beyond the schema, so it doesn't enhance understanding. Baseline 3 is appropriate when the schema does all the work.

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

  Purpose4/5

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

  The description clearly states the action ('Search and retrieve') and resource ('memories from the knowledge graph'), making the purpose immediately understandable. However, it doesn't distinguish this tool from potential sibling search operations (none listed in siblings, but 'list_memory_labels' is a related read operation). The description is specific but lacks 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. With siblings like 'list_memory_labels' (which might list all labels without search) and other CRUD operations, there's no indication of when search is preferred over listing or when this tool should be avoided. No context or exclusions are mentioned.

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

• update_connectionC
  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 an update operation (implying mutation) but doesn't address permissions needed, whether changes are reversible, rate limits, or what happens if the connection doesn't exist. The description adds minimal behavioral context beyond what's implied by 'update'.

  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 states the core purpose without unnecessary words. It's appropriately sized for a straightforward update operation and front-loads the essential information ('Update properties of an existing connection').

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

  Completeness2/5

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

  For a mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what 'properties' can be updated, what the response looks like, error scenarios, or how this differs from sibling tools. Given the complexity (4 required params including nested objects), more context is needed for the agent to use this effectively.

  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 4 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema descriptions (e.g., examples of 'type' values and 'properties' content are already in schema). 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 verb ('Update') and resource ('properties of an existing connection between memories'), making the purpose immediately understandable. It distinguishes from siblings like 'create_connection' (creates new) and 'delete_connection' (removes), though it doesn't explicitly mention these alternatives in the description text itself.

  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_connection' or 'update_memory'. It doesn't mention prerequisites (e.g., connection must exist), error conditions, or typical use cases, leaving the agent to infer usage from the name and schema alone.

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

• update_memoryC
  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 mentions 'update properties' but fails to specify whether this is a partial or full update, what happens to unmentioned properties, permission requirements, or error handling. For a mutation tool with zero annotation coverage, this leaves critical behavioral traits unclear.

  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 front-loads the core purpose. It avoids redundancy and wastes no words, though it could be slightly more structured for clarity. Every phrase contributes meaning, earning its place.

  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 as a mutation operation with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits, error cases, and return values, leaving gaps that could hinder an agent's ability to use the tool effectively in 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?

  Schema description coverage is 100%, so the schema already documents both parameters ('nodeId' and 'properties'). The description adds marginal value by implying 'properties' can include new details or changes, but it doesn't provide syntax, format, or constraints beyond what the schema offers. Baseline 3 is appropriate when the schema handles most documentation.

  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 ('existing memory') with specific examples of actions ('adding more detail or make a change when you find out something new'). It distinguishes from sibling 'create_memory' by specifying 'existing memory,' though it doesn't explicitly differentiate from other update operations like 'update_connection.'

  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 minimal guidance, only implying usage when new information is found or details need addition. It lacks explicit when-to-use scenarios, prerequisites, or comparisons to alternatives like 'create_memory' or 'search_memories,' leaving the agent with insufficient context for optimal tool selection.

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

• get_guidanceB
  3.3/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 provides 'help' but does not specify what form this help takes (e.g., textual advice, examples, documentation), whether it requires authentication, or any rate limits. This leaves significant gaps in understanding how the tool behaves beyond its basic purpose.

  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, clear sentence: 'Get help on using the memory tools effectively.' It is front-loaded with the core purpose, has no unnecessary words, and efficiently communicates the tool's intent without 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.

  Completeness3/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 (one optional parameter) and high schema coverage, the description is adequate for basic understanding. However, with no annotations and no output schema, it fails to provide details on behavioral aspects (e.g., response format, error handling) or deeper context, which could be important for effective use. It meets minimum viability but has clear gaps in completeness.

  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 'topic' parameter well-documented in the schema itself. The description does not add any additional meaning or context beyond what the schema provides (e.g., it doesn't explain the significance of topics like 'best-practices'). Since schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

  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 help on using the memory tools effectively.' It specifies the verb ('Get help') and the resource ('memory tools'), making it understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_memory_labels' or 'search_memories' in terms of its advisory versus operational nature, which prevents 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 Guidelines3/5

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

  The description implies usage context ('using the memory tools effectively'), suggesting it should be used for guidance rather than direct operations. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., when to seek help versus directly using tools like 'create_memory'), and does not mention any exclusions or prerequisites, leaving room for ambiguity.

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

• create_memoryA
  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 carries the full burden of behavioral disclosure. It mentions the 'Search → Create → Connect' workflow which adds important context about checking for existing memories, but doesn't disclose other behavioral traits like whether this is a write operation (implied by 'Create'), what permissions are needed, error handling, or what happens on duplicate creation attempts beyond the workflow advice.

  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 appropriately sized with two sentences that each serve distinct purposes: the first states the core function, the second provides important workflow guidance. It's front-loaded with the primary purpose and avoids unnecessary elaboration, though the workflow advice could be slightly more concise.

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

  Completeness3/5

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

  For a creation tool with 2 parameters, 100% schema coverage, but no annotations and no output schema, the description provides adequate context about the workflow but lacks details about behavioral aspects like error conditions, response format, or creation constraints. The workflow guidance is helpful but doesn't fully compensate for the missing structured information.

  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 the overall workflow context ('Search → Create → Connect') and the importance of checking existing labels, which provides semantic context beyond the schema's technical parameter descriptions. However, it doesn't add specific details about parameter usage beyond what's in the schema.

  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 a new memory') and resource ('in the knowledge graph'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'update_memory' or 'search_memories' beyond mentioning the Search → Create → Connect workflow, which is more about usage guidance than 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 Guidelines4/5

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

  The description provides clear context about when to use this tool through the Search → Create → Connect workflow, advising to check for existing memories first. It implies alternatives like 'search_memories' and 'list_memory_labels' but doesn't explicitly name them or specify when NOT 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_connectionA
  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 communicates the destructive nature ('permanently removes') and irreversible consequence ('use with caution'), which are critical for a deletion operation. It doesn't mention authentication requirements, rate limits, or error conditions, but covers the most important behavioral aspect for this type of 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 perfectly concise - a single sentence that communicates the core purpose upfront, followed by a crucial cautionary note. Every word earns its place, with no redundancy or unnecessary elaboration. The structure is front-loaded with the primary action.

  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 destructive operation with no annotations and no output schema, the description provides adequate context about the permanent nature of the action. It could benefit from mentioning what happens after deletion (e.g., whether it returns confirmation) or error scenarios, but given the straightforward nature of the operation and complete parameter documentation, it's reasonably 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 three parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema (it doesn't explain the meaning of 'connection' or provide additional context about the parameters). This meets the baseline expectation when schema coverage is complete.

  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 a specific connection') and resource ('between two memories'), distinguishing it from sibling tools like delete_memory (which deletes memories themselves) and update_connection (which modifies rather than removes connections). 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 Guidelines3/5

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

  The description provides implied usage guidance through the cautionary note ('use with caution - this permanently removes the relationship'), suggesting this should be used when permanent removal is intended. However, it doesn't explicitly state when to use this versus alternatives like update_connection for modifying relationships or when deletion is preferred over other operations.

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

• list_memory_labelsA
  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 full burden. It discloses the tool's behavior of listing labels with counts, which is useful. However, it doesn't mention potential limitations like pagination, sorting, or performance implications for large datasets, leaving gaps in behavioral context.

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

  Conciseness5/5

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

  The description is a single, well-structured sentence that efficiently conveys purpose and utility without any wasted words. It is front-loaded with the core action and includes a helpful parenthetical note.

  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 (0 parameters, no output schema, no annotations), the description is adequate but minimal. It explains what the tool does but lacks details on output format (e.g., structure of the list) or error conditions, which could be helpful despite the low complexity.

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

  Parameters4/5

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

  The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, maintaining focus on the tool's purpose. A baseline of 4 is applied for zero-parameter tools when schema coverage is complete.

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

  Purpose5/5

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

  The description clearly states the verb ('List') and resource ('all unique memory labels currently in use') with specific scope ('with their counts'). It distinguishes from siblings like 'search_memories' by focusing on labels overview rather than memory content.

  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 ('useful for getting an overview of the knowledge graph'), indicating when to use this tool. However, it doesn't explicitly state when not to use it or name specific alternatives among siblings like 'search_memories' for different purposes.

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

• delete_memoryA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates the destructive nature ('permanently removes'), scope ('all its connections'), and caution needed. However, it lacks details on permissions, error handling, or confirmation steps, leaving some behavioral aspects 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 front-loaded with the core action and includes a necessary warning in a single, efficient sentence. Every word earns its place, with no redundancy or unnecessary elaboration, 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.

  Completeness4/5

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

  Given the tool's complexity (destructive operation with no annotations or output schema), the description is mostly complete by emphasizing permanence and scope. However, it could improve by mentioning potential side effects (e.g., impact on connected data) or success/error responses, leaving minor gaps in 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 'nodeId' clearly documented as 'ID of the memory to delete.' The description does not add any additional meaning or context about the parameter beyond what the schema provides, so it meets the baseline for high schema coverage without extra value.

  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 a memory and all its connections') and distinguishes it from sibling tools like 'delete_connection' (which only deletes connections) and 'update_memory' (which modifies rather than removes). The verb 'delete' is precise and the resource 'memory' is explicitly identified.

  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 with the warning 'use with caution - this permanently removes the memory and all its connections,' which implies this tool should be used for irreversible deletion. However, it does not explicitly state when to use alternatives like 'update_memory' for modifications or 'delete_connection' for partial removal, missing explicit sibling differentiation.

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