Server Quality Checklist

Tool Scores

• delete_noteA
  3.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 responsibility for behavioral disclosure. It adds 'permanently,' indicating irreversibility, which is valuable, but it omits important details like error handling, idempotency, auth requirements, and side effects. The output schema exists but is not referenced, so the description only minimally covers the behavioral profile.

  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: one opening sentence and a one-line argument explanation. Information is front-loaded, with no wasted words or redundancy.

  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 simple single-parameter delete tool, the description covers the core operation and parameter provenance. However, with no annotations, it lacks details about edge cases (e.g., non-existent note, permissions) and doesn't mention what the response contains (though an output schema exists). It's adequate but not thorough.

  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 note_id (0% coverage), so the description must compensate. It does so by explaining the note_id is 'as returned by list_notes or search_notes,' giving the agent a clear source for a valid value. This adds meaningful context beyond the schema's bare title.

  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 the exact action: 'Delete a note permanently.' This is a specific verb (delete), resource (note), and qualifier (permanently), which clearly distinguishes it from siblings like add_note, list_notes, search_notes, and get_note.

  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 implicitly guides usage by stating the note_id must come from 'list_notes or search_notes,' providing a clear prerequisite. While it doesn't explicitly mention alternatives or when-not-to-use, the context is clear enough for a straightforward delete operation.

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

• add_noteA
  4/5.0
  Behavior2/5

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

  Since no annotations are provided, the description must disclose behavioral traits. It only says 'Save a new note' and explains parameters, without mentioning return behavior, idempotency, or side effects like persistence or interaction with other tools. This is a significant gap for a create 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 concise and front-loaded with the action 'Save a new note.', followed by clear, minimal parameter documentation. There is no fluff or redundant information.

  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 simple create operation, the description covers all necessary invocation details: required parameters, optional tags, and content format. An output schema exists, so the absence of return-value descriptions is acceptable. The tool is fully invocable based on this description.

  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 has no descriptions (0% coverage), but the description compensates by explaining each parameter: title is a short title, content is the body in Markdown, and tags are optional labels with an example array. This meets the need for parameter meaning.

  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 'Save' and clearly identifies the resource as 'a new note'. This distinguishes it from sibling tools like list_notes, get_note, and delete_note, which operate on existing notes.

  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 on when to use this tool versus alternatives. The description only states the action and lists parameters, so usage is implied rather than clearly contextualized. It does not mention any exclusions or direct the user to other tools for different needs.

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

• get_noteA
  4.3/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 burden. It discloses that the full note including body is returned, but doesn't mention error handling, permissions, or side effects (though 'Read' implies non-destructive). Basic transparency only.

  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: a clear purpose statement followed by a concise parameter explanation. No redundant phrases, perfectly front-loaded.

  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 single-parameter read tool with an output schema, the description is mostly complete. It could mention what happens for invalid IDs, but the output schema covers return values. Slight gap but not substantial.

  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?

  With 0% schema coverage, the description fully compensates by explaining note_id as 'The note's id, as returned by list_notes or search_notes.' This adds crucial provenance and format context beyond the bare 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 'Read one note in full, including its body.' This specific verb+resource distinguishes it from siblings like list_notes (likely summaries) and search_notes.

  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?

  It provides guidance that the note_id comes from list_notes or search_notes, implying a workflow. However, it doesn't explicitly say when to prefer this over alternatives, though the purpose is clear enough.

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

• search_notesA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries full burden. It discloses the key behavioral trait that results are snippets, not full bodies, and explains tag matching semantics (match_all). It also notes case-insensitivity for query. It does not mention edge cases like empty query behavior or result limits, but the main behaviors are covered.

  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 compact and well-structured, with a clear opening sentence and an Args section that maps directly to each parameter. Every sentence earns its place, and there is no redundancy or padding.

  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 presence of an output schema and the tool's moderate complexity, the description covers the essential behavior (snippet returns, parameter semantics) and directs users to get_note for full text. It does not explain what happens when both query and tags are omitted, but this is a minor gap. Overall, it is complete enough for effective use.

  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?

  Schema coverage is 0%, so the description must explain parameters. It does so thoroughly: query specifies text in titles and bodies with case-insensitivity, tags restrict results to notes with those tags, and match_all defines AND vs OR semantics. This adds significant meaning beyond the raw 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 starts with 'Find notes by text and/or tags', which clearly states the tool's function and its distinguishing aspect from siblings like list_notes (which likely lists all) and get_note (which retrieves a single note). The verb 'find' and resource 'notes' are 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 Guidelines4/5

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

  The description explicitly directs users to call get_note to read a full note, implying search_notes is for discovery and snippet preview. It does not explicitly contrast with list_notes, but the snippet behavior makes the use case clear. This is strong guidance, though not exhaustive.

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

• list_notesA
  4.6/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 disclosure. It adds valuable behavioral context: results are ordered by 'most recently updated first' and the response omits note bodies. It does not detail pagination or auth, but for a simple read-only list, this is sufficient and goes beyond a bare statement.

  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 efficiently structured: a clear first line, a brief note on return value and alternatives, and a concise parameter description. 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 simple list tool with one optional parameter and an output schema present, the description provides all necessary context: purpose, ordering, response contents, and parameter behavior. It is complete for its complexity band.

  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 zero description coverage for the 'tag' parameter. The description compensates fully by stating 'Optional tag to filter by', giving clear semantics that the schema lacks. This is exactly what parameter descriptions should provide.

  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 function with a specific verb and resource: 'List saved notes'. It also distinguishes itself from siblings by noting it returns only titles and tags, and explicitly points to get_note for reading a full note. This makes the purpose unambiguous and distinct.

  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 gives explicit guidance to use get_note when a full note body is needed, and implies list is for overview. It does not mention search_notes as an alternative for searching, but the listing with optional tag filter is clear. This is strong but not fully exhaustive in covering all sibling alternatives.

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