Server Quality Checklist

Tool Scores

• delete_noteC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description should disclose behavioral traits like permanence, error handling, or auth requirements. It only says 'delete', implying mutation, but omits consequences such as irreversibility or missing id behavior.

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

  Conciseness4/5

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

  The description is a single sentence with no wasted words. However, the brevity sacrifices necessary detail; it is efficient but borderline under-specified.

  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?

  Even with an output schema, the description fails to cover critical context: permanent deletion, error behavior (missing id), and that it handles both notes and bookmarks without a way to differentiate. This leaves gaps for correct invocation.

  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 has 0% description coverage for item_id. The tool description adds 'by its id number', which is nearly redundant with the parameter name. It does not clarify the id's source, format, or disambiguation between note and bookmark ids.

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

  Purpose5/5

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

  The description clearly states the action 'delete', the resource 'a note or bookmark', and the identification method 'by its id number'. It distinguishes well from sibling tools like add_note, add_bookmark (creation), and search_notes, list_notes (read).

  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 on when to use this tool versus alternatives, no prerequisites, and no mention of preconditions like id existence or permissions. The description simply states what it does without context for appropriate use.

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

• add_noteB
  3.2/5.0
  Behavior2/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. It only states 'Save a quick note or thought to the vault,' which is minimal. It does not mention whether the note is saved to a specific location, if it can be overwritten, any authentication needs, rate limits, or what the return value looks like (despite an output schema existing).

  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 extremely concise with two sentences and no superfluous words. Every sentence serves a purpose: the first states the action, the second gives a usage tip for tags.

  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 has 2 parameters and an output schema, the description lacks completeness. It does not explain where in the vault the note is saved, if there are limits on content length, or the format of the response. The output schema exists but the description offers no context about it.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description must add meaning. It partially does by explaining tags: 'Use tags to make it easy to find later, e.g. ["work", "idea", "todo"].' However, it does not explain the 'content' parameter beyond being a note/thought, and no constraints or format details are provided. This partially compensates for the low schema coverage.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: 'Save a quick note or thought to the vault.' It uses a specific verb ('save') and resource ('note/thought'), and distinguishes it from siblings like add_bookmark (bookmark), search_notes (search), list_notes (list), and delete_note (delete).

  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. It does not mention scenarios where add_note is preferred over search_notes, list_notes, or delete_note, nor does it indicate prerequisites or exclusions.

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

• search_notesB
  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 must carry the full burden of behavioral disclosure. It only mentions searching by text in content or tags but omits critical traits like read-only nature, authentication requirements, pagination, or result limits.

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

  Conciseness4/5

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

  The description is brief, consisting of two sentences that front-load the purpose. The second sentence provides usage context, though it is slightly awkward. No unnecessary words, but could be more precise.

  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 (one parameter, output schema exists), the description covers the basic purpose and scope. However, it does not mention whether results are ordered, limited, or how bookmarks are interleaved with notes, leaving some 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?

  With 0% schema description coverage, the description must compensate. It explains the query parameter implicitly by stating matching text in content or tags, but does not specify format, match type, or behavior for empty queries. The added value is minimal.

  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 searches notes and bookmarks by matching text in content or tags, using a specific verb and resource. It distinguishes itself from siblings like add_note, list_notes, and delete_note by focusing on 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 advises using the tool when the user wants to recall something, but it lacks explicit guidance on when not to use it or alternatives. 'Prefer this over guessing' is vague and does not provide concrete exclusion criteria.

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

• add_bookmarkB
  3.4/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 responsibility for behavioral disclosure. It indicates a write operation ('Save') but omits consequences such as idempotency, overwrite behavior, or error handling. The output schema exists but is not referenced, and no details about state changes or side effects are given.

  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 long, front-loaded with the primary action. Every sentence adds value: the first states the core function, the second clarifies which parameters are required and the purpose of 'note'. No redundancy or unnecessary detail.

  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 existence of an output schema, the description covers the basic purpose and two key parameters. However, it omits the 'url' and 'tags' parameters, and does not explain return values or behavior on duplicate URLs. It is adequate but not fully complete.

  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 explains the 'title' parameter (required) and 'note' (optional comment), but does not mention the required 'url' parameter or the optional 'tags' array. Meaning is added for only half the parameters, and the critical 'url' is left undefined.

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

  Purpose5/5

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

  The description clearly states the action ('Save a link/bookmark') and the target ('to the vault'). It specifies the resource type (link/bookmark) and distinguishes it from sibling tools like add_note, which are for notes. The verb 'save' is precise.

  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 saving web links, but lacks explicit guidance on when to use this tool versus alternatives (e.g., add_note for text). No when-not-to-use scenarios or prerequisites are mentioned. The context is clear enough for a simple tool, but the absence of explicit alternatives is a gap.

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

• list_notesA
  3.9/5.0
  Behavior4/5

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

  The description informs that results include both notes and bookmarks, and filtering is by a single tag only. This is useful behavioral context beyond the schema. As no annotations are provided, the description carries the full burden, and it adequately warns that any complex filtering or multiple tags would require a different tool like 'search_notes'.

  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 one compact sentence: 'List recent notes and bookmarks, optionally filtered by a single tag.' Every word is necessary and front-loaded with purpose. No filler.

  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?

  With two simple parameters, an output schema present, and sibling tools providing contrast, the description covers the essential behavior. It could briefly note that 'limit' defaults to 20 (implied by schema but not described) or that results are sorted by recency, but given the tool's simplicity and available context, it is sufficiently complete.

  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 covers both parameters with defaults but has 0% description coverage, so the description must add value. The description explains that 'tag' filters by a single tag (not multiple) and implies 'limit' controls recency or count. This compensation makes the param intent clearer, earning a higher score.

  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 that the tool lists recent notes and bookmarks with optional tag filtering. It specifies the resource and action distinctly, but doesn't explicitly differentiate from sibling tools like 'search_notes', which could cause slight ambiguity about scope.

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

  Usage Guidelines3/5

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

  The description implies a 'list' operation for browsing recent items, contrasting with search or add functions from siblings. However, it lacks explicit when-to-use or when-not-to-use guidance, such as distinguishing from 'search_notes' for non-tag or more complex queries.

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