Server Quality Checklist

Tool Scores

• deleteProjectC
  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 merely states 'Delete a project' without mentioning reversibility, cascade effects on related nodes/links, permission requirements, or any confirmation steps. For a destructive operation, this is a significant transparency gap.

  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 a single concise sentence with no fluff, but it essentially restates the tool name without adding useful information. It is appropriately short, but not effective enough to earn a higher score because it lacks substance and is essentially a tautology.

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

  Completeness2/5

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

  For a destructive tool with no annotations and no output schema, the description is incomplete. It does not explain what happens on success, whether the operation is idempotent, or how associated data (e.g., nodes linked to the project) is affected. The simplicity of the parameter schema does not compensate for this missing behavioral 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 covers 100% of the single parameter with a description stating the project ID should be kebab-case and provides a pattern, so schema coverage is high. The tool description itself does not add any parameter-level information beyond what the schema already provides, matching the baseline of 3.

  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 'Delete a project' clearly identifies the action (delete) and the resource (project), distinguishing it from sibling tools like createProject and updateProject. However, it lacks any additional scope or specific behavior (e.g., permanent deletion) that would fully contrast it with alternatives, so it doesn't reach 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 such as updateProject or removeNode. There are no stated prerequisites, side effects, or indications of whether this should be used for soft-delete or hard-delete scenarios, 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.

• linkNodesC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description must disclose side effects, but it only states the basic action. It does not mention whether the relationship is idempotent, what happens if the relationship already exists, how metadata/strength defaults behave, or what response is returned. 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.

  Conciseness4/5

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

  The description is a single concise sentence with no filler, front-loading the core purpose. However, it is minimal and does not fully exploit the space to aid the agent, yet it remains efficient.

  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 7 parameters, nested objects, and no output schema, the description is severely under-specified. It provides no information about return values, error cases, or behavioral nuances, making it incomplete for an agent to invoke correctly in varied scenarios.

  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 covers all 7 parameters with descriptions (100% coverage), so the baseline is 3. The tool description adds no additional meaning beyond the schema; parameters like 'from', 'to', 'type', and optional ones are not elaborated in the description.

  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 states a specific verb ('Create') and resource ('relationship between two nodes'), distinguishing it from sibling tools like addNode (creates a node) and unlinkNodes (removes a relationship). However, it does not enumerate the relationship types or mention that it links existing nodes, leaving some ambiguity.

  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 such as unlinkNodes or addNode. There is no mention of prerequisites (e.g., nodes must exist) or when creating a relationship is appropriate.

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

• searchNodesC
  2.9/5.0
  Behavior2/5

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

  Annotations are absent, so the description carries full burden for behavioral disclosure. It only states 'search nodes by criteria' without revealing whether the operation is read-only, how results are returned, pagination behavior, or filtering semantics. This leaves critical behavioral aspects unaddressed.

  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, front-loaded sentence that efficiently states the core purpose. It is concise, but the brevity sacrifices substance—key context about usage and behavior is omitted, making it somewhat under-specified rather than appropriately concise.

  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 there are 6 parameters, no output schema, and no annotations, the description is incomplete. It does not explain return values, result format, or any behavioral constraints. The agent would need to look elsewhere for essential context, making this insufficient for a tool of this 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?

  Schema description coverage is 100%, so all parameters have individual descriptions. The tool description adds no additional meaning beyond what is already in the schema, which is acceptable given the high coverage. Baseline 3 is appropriate.

  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 'Search nodes by criteria' clearly identifies a search operation on nodes with criteria-based filtering. It uses a specific verb and resource, but 'criteria' is vague and it does not differentiate from the sibling tool queryNode, which likely serves a similar purpose.

  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 usage guidance is provided. The description does not state when to use this tool versus alternatives like queryNode or listProjects, nor does it mention any prerequisites or exclusions. The agent is left to infer the intended use case.

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

• updateNodeC
  2.9/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 of disclosing behavioral traits. It merely states 'update' without explaining whether updates are partial or full replacement, how null fields are handled, what happens if the node doesn't exist, or any permission requirements. This is a significant gap for a mutation tool with 7 parameters.

  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, concise sentence that front-loads the core purpose. It contains no filler or redundant information. However, it is so brief that it misses opportunities to add behavioral context, so it doesn't fully earn a 5 for structure.

  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 an update tool with 7 parameters, no output schema, and no annotations, the description is incomplete. It fails to explain update semantics, parameter interactions, or error cases. The schema provides field names but not the behavioral context needed to use the tool 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?

  The input schema provides 100% coverage of parameter descriptions, so the baseline is 3. The tool description adds no additional parameter semantics beyond the schema. Since every parameter is already documented with descriptions (e.g., 'new node name', 'new tags list'), the description does not need to compensate.

  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: updating an existing node in the knowledge graph. The verb 'update' and resource 'existing node' are specific and differentiate it from sibling tools like addNode and removeNode. However, it lacks detail on what aspects of the node can be updated, so it doesn't fully distinguish from potential variants.

  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 does not mention that addNode is for creating nodes, nor does it discuss any prerequisites or contraindications. The only hint is the tool name itself, which is insufficient.

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

• updateProjectC
  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 must disclose mutation side effects, partial update behavior, or error responses. 'Update project metadata' only signals a write operation and fails to clarify whether only provided fields are changed or what happens if the project ID is invalid.

  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, front-loaded sentence that gets straight to the point. It is concise and free of fluff, though it is so brief that it omits potentially useful context, which keeps it from being a 5.

  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?

  The tool has 4 parameters, no output schema, and no annotations. The description is too sparse to be complete: it does not explain update semantics (partial vs full), required permissions, return values, or failure modes, leaving an agent with insufficient context for reliable invocation.

  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% coverage for parameter descriptions, so the baseline is 3. The description itself does not add semantic detail beyond the schema, merely calling everything 'metadata' without explaining individual fields.

  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 indicates an update operation targeting project metadata, distinguishing it from createProject, deleteProject, and updateNode. However, it does not enumerate the specific metadata fields, leaving the scope somewhat generic but still recognizable.

  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 given on when to use this tool versus alternatives. There is no mention of using createProject for new projects, updateNode for node-level changes, or any prerequisites or context that would help an agent choose this tool appropriately.

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

• addNodeB
  3/5.0
  Behavior1/5

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

  The description offers no behavioral details beyond the basic action. It does not disclose what happens on duplicate IDs, whether the operation is reversible, or any side effects. With no annotations to cover safety or behavioral traits, the description leaves all behavioral aspects uncertain.

  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 with no unnecessary words. It is front-loaded and does not waste the agent's attention, scoring high on conciseness.

  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 8 parameters, nested metadata objects, and no output schema, the one-line description is inadequate. It does not explain the node lifecycle, relationship to projects, or expected outcomes, leaving the agent with too much uncertainty for a mutation tool.

  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 provides descriptions for all 8 parameters, achieving 100% coverage. The description adds no additional parameter semantics, but the schema already does the heavy lifting, warranting the baseline score of 3.

  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 'Add a new node to the knowledge graph' clearly identifies the action (add) and the resource (node in the knowledge graph). It distinguishes the tool from siblings like updateNode and removeNode, which imply modification and deletion respectively.

  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 updateNode or linkNodes. There are no prerequisites or situational context given, such as whether the graph must already exist or how this relates to projects.

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

• createProjectB
  3.1/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 disclosing behavioral traits. It only states the generic fact that a project is created, but omits important details such as whether the operation is idempotent, whether workspacePath must be pre-existing, what side effects occur (e.g., directory creation), or what the response contains. 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.

  Conciseness4/5

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

  The description is a single, front-loaded sentence with no filler. It efficiently communicates the core purpose. However, it is slightly under-specified, which prevents a perfect score—it could have included a brief note on usage or outcome without becoming verbose.

  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?

  Although the schema fully covers the parameters, the tool is a create operation with no annotations and no output schema. The description does not explain the return value, error conditions, or dependencies (e.g., whether workspacePath must be valid). This leaves significant gaps in understanding the tool's full behavior, making it incomplete for an AI agent to invoke with confidence.

  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 provides descriptions for all three parameters (100% coverage), so the baseline is 3. The description adds no additional meaning beyond what the schema already specifies—it merely says 'with metadata' without elaborating on the parameters. The schema itself is clear enough, so the tool description does not need to compensate.

  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 'Create a new project with metadata' clearly states the action (create) and the resource (project), distinguishing it from sibling tools like updateProject, deleteProject, and listProjects. The verb-resource pair 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 guidance on when to use this tool versus alternatives. It does not mention that it is the creation counterpart to updateProject, nor does it offer any context about prerequisites (e.g., workspacePath must exist) or situations where a different tool might be more appropriate.

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

• queryNodeB
  3.2/5.0
  Behavior3/5

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

  No annotations are provided, so the description must disclose behavioral traits. 'Query' implies a read-only operation, and 'its relationships' hints at relationship traversal, but there is no explicit mention of safety, side effects, or limits. The description adds minimal behavioral context beyond the verb itself.

  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 with no filler words, front-loading the verb and resource. It is highly concise, though it may be under-specified; conciseness itself is exemplary.

  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?

  The tool has no output schema, so the description should explain what the query returns. It only states 'Query a node and its relationships' without detailing return format, depth behavior, or how relationships are represented. With no annotations and no output schema, the description is incomplete for a tool with 4 parameters and relationship traversal.

  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 all four parameters documented in the input schema. The description itself adds no parameter-specific meaning, but the schema already provides descriptions for id, depth, projectId, and includeNeighbors, so the description is not required to compensate.

  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 uses the verb 'Query' and specifies the resource 'a node and its relationships,' clearly stating the tool's function. However, it does not explicitly distinguish from sibling tool 'searchNodes' or mention that it queries by ID, so it is clear 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 such as 'searchNodes' or 'listProjects'. No context or exclusions are given, leaving the agent to infer usage from the name alone.

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

• removeNodeB
  3.2/5.0
  Behavior2/5

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

  With no annotations, the description carries full burden but only says 'remove' without explaining cascade behavior, irreversibility, or effects on connected edges. The cascade parameter suggests important behavior that is not disclosed in the text.

  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?

  A single sentence that states the core function without verbosity; it is front-loaded and earns 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?

  The description is minimal for a destructive operation with no annotations or output schema; it omits cascade behavior, permanence, and any return value information, leaving agents to infer these from the schema alone.

  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 descriptions cover 100% of parameters (id, cascade, projectId), so the description need not repeat them; baseline 3 is appropriate. The tool description adds no additional semantic context 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 uses the specific verb 'Remove' and identifies the resource as 'a node from the knowledge graph', clearly distinguishing it from project tools like deleteProject and node modification tools like updateNode.

  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 about when to use this tool versus alternatives such as unlinkNodes for edges or deleteProject for projects, and no exclusions or prerequisites are mentioned.

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

• unlinkNodesB
  3.4/5.0
  Behavior2/5

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

  With no annotations, the description carries full burden for disclosing behavioral traits. It only states the action without revealing side effects, irreversibility, error handling if the relationship or nodes don't exist, or whether it affects other data. This is insufficient for a mutating operation.

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

  Conciseness5/5

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

  The description is a single direct sentence, front-loaded with the primary action, and contains zero redundant words. It efficiently states the purpose without wasting tokens.

  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?

  While parameters are fully documented in the schema, the description lacks essential context for a mutating tool such as what happens when no relationship exists, whether deletion is permanent, or what the response is. No annotations or output schema compensate for this gap.

  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%, including details like optional 'type' meaning to delete all edge types if unspecified. The description adds no additional parameter context, so it does not exceed the baseline provided by 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 uses a specific verb ('Remove') and identifies the resource ('relationship between two nodes'), clearly distinguishing this from sibling tools like linkNodes (create relationship) and removeNode (delete a node). It leaves no ambiguity 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 the tool is used to remove relationships, but provides no explicit guidance on when to use it instead of alternatives, nor any prerequisites or exclusions. It relies on the agent's common sense about relationships versus nodes.

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

• listProjectsA
  3.6/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. 'List all projects' implies a read-only operation but does not report return format, pagination, or any side effects. It lacks depth beyond the literal meaning.

  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 concise sentence with no wasted words. It is appropriately front-loaded 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?

  Given the tool's simplicity (no parameters, no annotations, no output schema), the description is mostly sufficient. It names the action and resource clearly, though it omits return value details which could be inferred from a list operation.

  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 zero parameters, so there is nothing to document. The description's 'all' adds meaning by indicating the scope is unfiltered, which is useful context. This meets the baseline for zero params.

  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 ('List') and resource ('projects'), clearly indicating the action. It distinguishes from sibling tools like createProject, updateProject, and deleteProject, which have different operations.

  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 does not mention exclusions or specific use cases, leaving the agent to infer from context.

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