Server Quality Checklist

Tool Scores

• project_statusA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint and idempotentHint, and the description reinforces this with 'Read-only'. It adds what the response covers (memory presence, counts by kind, latest 5 entries), which matters because there is no output schema. It stops short of defining exact formats, but that is a minor gap.

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

  Conciseness5/5

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

  One sentence communicates scope, output content, and safety in under 20 words. Every phrase adds information and the core behavior is 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-only status tool with no output schema, the description covers the key return components sufficiently. It lacks details like ordering of latest entries or error behavior, but those are not necessary for deciding to call 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 coverage is 100% and the project_root description is thorough, so the schema carries the full parameter burden. The tool description adds nothing about parameters, which is acceptable under the high-coverage baseline.

  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?

  Description opens with a concrete verb ('Report') and identifies the exact output: whether memory exists, counts by kind, and the latest 5 entries. It is clearly a read-only status snapshot, which separates it from the memory_record and memory_search siblings.

  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 read-only label and summary-style output make the intended use obvious: check a project's memory state before deciding to record or search. It does not explicitly name alternatives, but the context is clear enough for an agent to infer when to call it.

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

• memory_recordA
  4.4/5.0
  Behavior5/5

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

  Beyond idempotentHint=true, the description reveals the exact idempotency key ('Identical kind+title+body is stored once') and the response signal ('the response reports created=false when it already existed'). It also discloses the full supersede contract — 'superseded memories are hidden from search by default' — which qualifies destructiveHint=false by explaining that replacement hides rather than deletes. No contradiction with annotations.

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

  Conciseness5/5

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

  Three sentences, each earning its place: purpose first, then dedup/idempotency behavior, then supersede semantics. Information is front-loaded with the core purpose and no word is wasted.

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

  Completeness4/5

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

  For a tool with six parameters including the relationship parameter supersedes, the description covers all non-obvious behaviors: deduplication, the created flag in the response, and the visibility effect on search. Since there is no output schema, this partial return-value disclosure is valuable; the remaining gap is that it never states what else the response contains (e.g., the new memory's id needed to chain supersedes).

  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 only 17% schema description coverage, the description compensates for most undocumented parameters: it gives kind semantic framing (note/decision/requirement/learning), makes title and body part of the dedup identity, and fully explains supersedes including its search-hiding consequence. Only tags receives no added meaning, but its purpose is evident from its name and schema constraints.

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

  Purpose5/5

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

  The description opens with 'Record a durable memory' — a specific verb acting on a clearly named resource — and enumerates the four kinds (note, decision, requirement, learning) that map directly to the kind enum. The verb contrast with sibling memory_search makes the read/write distinction obvious, and project_status is clearly out of scope. The meaning is unambiguous.

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

  Usage Guidelines3/5

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

  The description never explicitly states when to use this tool versus its siblings (e.g., no 'use memory_search to find memories' routing). Usage context is implied by 'Record a durable memory ... for a project' and by the disclosed dedup and supersede behaviors, which signal this is the safe write-tool to call repeatedly, but no explicit alternatives or exclusions are given.

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

• memory_searchA
  4.4/5.0
  Behavior5/5

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

  The annotations already declare readOnlyHint and idempotentHint, and the description adds substantial behavioral detail: literal word matching, prefix matching on the last word, excerpt-only hits by default, newest-first ordering among equal relevance, and empty results for unknown projects. None of this contradicts the annotations.

  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?

  Four sentences, each carrying distinct operational value: purpose, matching rules, excerpt behavior, and ordering/empty-result behavior. The purpose is front-loaded and no sentence is wasted.

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

  Completeness4/5

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

  The description covers scope, query behavior, result excerpt shape, ordering, and empty-result handling, which is solid for a read-only search tool with no output schema. It falls just short of a 5 because exact hit structure and defaults for optional parameters like limit and include_superseded are not described.

  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 only 33%, so the description must compensate. It does explain query matching semantics and the excerpt-versus-body behavior tied to include_body, but it leaves kinds and include_superseded semantics undocumented, and limit's default is not stated. Partial compensation, not 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 opens with a specific verb and resource: 'Full-text search over a project's memories.' This clearly distinguishes the tool from siblings memory_record (creating memory) and project_status (reading status), so an agent can select it without ambiguity.

  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 establishes a clear usage context: searching project memories with full-text semantics. However, it does not explicitly name alternatives or state when to prefer memory_record or project_status, so it misses the 'when-not-to-use' guidance that would earn a 5.

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