Server Quality Checklist

Tool Scores

• verify_qualityC
  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 full burden for behavioral disclosure. It says 'scan' and 'return them for enrichment' which suggests read-only, but does not explicitly state that it does not modify data or confirm safety. It also does not disclose output format, permissions, or side effects. The description is too vague.

  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 that efficiently conveys the core action and outcome. It is front-loaded and contains no filler. However, it could benefit from a bit more structure or clarity on return format, but it is not 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?

  With 2 parameters, no output schema, and no annotations, the description should provide more context about what 'return them' means (list of entry IDs? entry objects? how to use with update_entry?). It also does not clarify whether project_dir is optional or defaults to current project, leaving ambiguity. Incomplete for a tool that feeds into a workflow.

  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 inline descriptions for both parameters. The tool description adds no additional meaning beyond what the schema already provides for project_dir and min_reason_chars. Baseline 3 is appropriate since schema already documents parameters well.

  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 scans entries for specific quality issues (legacy schema, thin reasoning, missing tags, isolated entries) and returns them for enrichment via update_entry. The verb 'scan' and the listed issue types give a clear purpose, and it distinguishes from siblings like update_entry (modification) and query_entries (general query).

  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 implies a workflow (scan then enrich via update_entry) but offers no explicit guidance on when to use verify_quality versus alternatives like query_entries. It does not mention when-not to use or prerequisites. The mention of update_entry is a hint but insufficient.

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

• deprecate_entryB
  3.1/5.0
  Behavior2/5

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

  Annotations are missing, so the description bears full responsibility for behavioral disclosure. It does not state what 'deprecated' means, whether the action is reversible, or any side effects beyond the non-destructive note in the merge_into parameter description.

  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 very short and front-loaded, with no redundant phrases. However, it could include more contextual information without being 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?

  With five parameters, no output schema, and no annotations, the description is too brief. It does not explain the overall effect on the entry, how deprecation affects queries, or the relationship between parameters like merge_into and superseded_by.

  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%, so the schema already documents all parameters. The description adds minimal value by noting the superseding decision is optional and for decisions only, which matches the parameter 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 clearly states 'Mark an entry as deprecated', using a specific verb and resource. It also explicitly mentions the optional superseding decision linking for decisions, distinguishing it from other tools like update_entry or prune_stale.

  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 like prune_stale or update_entry. No exclusions or context provided beyond the basic action.

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

• get_contextB
  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 fully convey behavioral traits. It mentions ranking by relevance and token budget, but omits side effects, authentication needs, rate limits, and what happens with conflicting parameters (e.g., id plus tags). This leaves significant behavioral ambiguity for a retrieval tool with 10 parameters.

  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 only two sentences, no redundant information, and a clear front-loaded purpose. Every sentence adds value, making it efficient for quick comprehension.

  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 10 parameters, no output schema, and no annotations, the description is incomplete. It fails to explain the output format, how relevance is determined, or how the token budget affects results. For a complex retrieval tool, more contextual detail is needed to avoid misuse.

  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 all 10 parameters with descriptions, achieving 100% coverage. The description adds value by explaining the special behavior of the 'id' parameter (single entry at full fidelity), which goes beyond the schema. However, it does not clarify interactions between parameters (e.g., how tags and query combine), so the added semantics is moderate.

  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 retrieves project context ranked by relevance within a token budget. It distinguishes fetching by id for full fidelity vs other parameters. However, it does not explicitly differentiate from sibling tools like query_entries or get_project_summary, so clarity is high but not perfect.

  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 guidance on using the 'id' parameter for a single entry, which helps the agent decide between id-based and query-based usage. However, it lacks explicit comparisons to alternative tools (e.g., when to use get_context vs query_entries) and does not state prerequisites or exclusion criteria.

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

• export_markdownB
  3.4/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 that the operation is a 'read-only projection' (non-destructive to the store) but 'overwrites the file whole' (destructive to output). This is useful behavioral transparency, though it omits details like permission requirements or side effects on the store.

  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 action ('Regenerate DECISIONS.md') and adds essential qualifiers ('derived, read-only projection'; 'overwrites the file whole'). Slight use of dash and semicolon could be cleaner, but it remains 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?

  The description explains what the tool does but does not cover return values (no output schema), the role of 'project_dir', or how it compares to similar tools. Given the simplicity (2 params, no output schema), it is minimally adequate but leaves gaps for an agent unfamiliar with the project.

  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% with descriptions for both parameters. The description's mention of 'overwrites the file whole' adds minor context to the 'path' parameter, but overall does not significantly enhance understanding beyond the schema. Baseline of 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 clearly states the tool regenerates DECISIONS.md from the decisions store, using a specific verb ('Regenerate') and resource. However, it does not differentiate itself from the sibling tool 'export_snapshot', limiting clarity for an agent choosing between them.

  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 gives no explicit guidance on when to use this tool versus alternatives like 'export_snapshot' or 'get_project_summary'. It does not mention prerequisites, exclusions, or typical use cases, leaving the agent without decision support.

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

• update_entryA
  3.5/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden. It discloses that the verified_at timestamp is automatically refreshed, which is useful. However, it omits other behavioral traits such as whether the operation is idempotent, destructive, or requires specific permissions.

  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?

  Two concise sentences. The first directly states the action and target, the second adds a key behavioral detail. Every sentence earns its place without 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 mutation tool with three parameters, nested objects, no output schema, and no annotations, the description covers the basic purpose and one behavioral note. It lacks details on error handling, validation, or side effects, making it only moderately 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 baseline is 3. The description adds context for the 'id' parameter (entry types) but does not significantly enhance understanding beyond the schema. The 'updates' parameter is explained in the schema as well.

  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 that the tool updates existing decisions, pipelines, or constraints by ID, specifying the resource types and action. It adds value by mentioning automatic timestamp refresh, distinguishing it from read-only tools.

  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 like deprecate_entry or prune_stale. The description implies its use for general updates but does not explicitly state limitations or when to choose a different tool.

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

• get_compaction_reportA
  3.7/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 full burden. It implies a read-only check ('Check if...') but does not explicitly declare safety or side effects, leaving some ambiguity about whether it modifies state.

  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?

  Two sentences directly convey the core purpose, with no filler words. The description is front-loaded and efficient.

  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?

  The description lacks details about the return format (e.g., list of discrepancies or boolean) and does not explain the 'report' concept. Given no output schema, this omission reduces 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?

  Schema description coverage is 100%, and the parameter description ('Absolute path to another project to check') is self-explanatory. The tool description adds no further meaning, meeting the baseline for simple parameters.

  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 checks for loss or modification from the last compaction and surfaces discrepancies, which is a specific verb+resource. It implicitly distinguishes from sibling tools like verify_quality or prune_stale by focusing on compaction aftermath.

  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 phrase 'before proceeding' gives a hint of when to use, but there is no explicit guidance on when not to use or alternatives among siblings, leaving the agent to infer usage context.

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

• get_project_summaryA
  3.7/5.0
  Behavior2/5

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

  No annotations are provided, and the description does not disclose any behavioral traits such as side effects, access requirements, or rate limits. It only describes the response content, leaving the agent without information on potential impacts or permissions needed.

  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 that front-loads the tool's purpose and lists key outputs. It is reasonably concise, though slightly long. No extraneous information.

  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 no output schema, the description effectively enumerates return components (counts, constraints, decisions, id list, summary). It provides sufficient context for a summary tool, though it lacks error handling or edge-case details.

  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% with descriptive param docs for both 'project_dir' and 'token_budget'. The description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.

  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 it is the 'single orienting call for conversation start' and lists exactly what it returns (counts, constraints, decisions, id list, summary), distinguishing it from siblings like 'get_context' or 'query_entries' which are more specific query tools.

  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 marks it as 'for conversation start', providing clear context on when to use this tool (initial orientation). It does not list exclusions or alternatives, but the context is clear and no misleading guidance is present.

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

• reload_constraintsA
  3.8/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 carry the burden. It discloses the scope ('constraints only, not the full store') and hints at the outcome ('same block as session start'), but does not mention side effects, permissions, or other behavioral traits. This is adequate but not detailed.

  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 with no wasted words. It front-loads the action and condition, making it easy to scan. Every sentence adds value.

  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 has a single optional parameter, no output schema, and a well-defined purpose, the description covers the necessary context for an agent to decide when and how to invoke it. It could mention the result format or side effects, but for a simple reload tool it is nearly 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?

  The input schema has 100% coverage for the single parameter 'project_dir'. The description does not add additional meaning beyond what the schema already provides. Per guidelines, baseline is 3 for high coverage, and no extra value is added.

  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 ('re-surface') and the resource ('project's constraints'), and explicitly distinguishes it from a full store reload. However, it does not explicitly contrast with sibling tools, so a 4 is appropriate.

  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 specifies the condition for use ('when a long session has buried the ones injected at start') which provides clear context. It lacks explicit when-not-to-use or alternative tools, but the scenario is well-defined.

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

• record_entryA
  3.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 must carry the full burden. It identifies the tool as a write operation and mentions server-side validation, but lacks information on side effects (e.g., creating directories), authorization needs, or return values.

  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-loading the core purpose and following with essential grouping information. Every sentence is informative without superfluous content.

  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 25 parameters and no output schema, the description adequately covers required fields per kind but omits return value specification and side effects like the project_dir parameter's effect. It is sufficient for basic usage but has clear gaps.

  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 grouping parameters by kind and indicating required fields, which is not present in the schema's individual descriptions.

  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 as a unified write tool for recording decisions, constraints, or pipelines, differentiating it from sibling tools like query_entries or update_entry which handle reading or updating.

  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 for when to use the tool and specifies required fields per kind, but does not explicitly exclude scenarios or mention alternatives like update_entry for modifications.

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

• mirrorA
  4/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses that pull merges with newest-wins conflict resolution, backfill does upsert, and the tool is no-op if remote is unconfigured. It lacks details on error handling or side effects but covers core behavior well.

  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?

  Two concise sentences, each adding value. The first states the overall purpose, the second elaborates on the two ops and the no-op condition. No wasted words.

  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?

  The description covers the core sync behavior but lacks details on how the remote store is configured, what the return values are (no output schema), and does not address potential issues like conflicts beyond the simple newest-wins rule. It is adequate for basic usage 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 coverage is 50% (op described, project_dir not). The description adds meaning for op beyond the schema but does not address project_dir at all. With low coverage, the description should compensate but fails to explain the essential parameter.

  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 synchronizes entries with a remote store and distinguishes two operations (pull and backfill) with precise definitions. This differentiates it from sibling tools that operate on individual entries or snapshots.

  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 explains when to use each op: pull for merging remote to local, backfill for pushing local to remote. It also mentions the no-op condition. However, it does not explicitly guide when not to use this tool versus alternatives like import_snapshot.

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

• prune_staleA
  4/5.0
  Behavior3/5

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

  With no annotations, the description correctly notes the tool is not destructive ('does not delete'). But it lacks details on rate limits, authentication needs, or the exact format of the returned entries. Adequate but not rich.

  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?

  Two sentences, no redundancy. Front-loaded with the main action and quickly clarifies non-destructive behavior. Every word earns its place.

  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 simple read-only tool with two parameters and no output schema, the description covers the use case and periodic call recommendation. Missing details on return format are minor.

  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%, so the description does not need to add much. It implies the 'days' parameter but adds no new meaning beyond the schema. Baseline 3 is appropriate.

  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 finds entries not verified in N days and returns them for review without deletion. The verb 'Find' and resource 'entries' are specific, and it distinguishes itself from deletion tools like 'deprecate_entry'.

  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 suggests calling periodically to keep context fresh, providing a clear usage pattern. However, it does not explicitly state when not to use it or compare to alternatives like 'query_entries'.

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

• import_snapshotA
  4.2/5.0
  Behavior4/5

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

  Describes key behavioral traits (non-destructive, auto-run) given no annotations. Could expand on prerequisites or failure modes but sufficient.

  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 concise sentences, fully front-loaded with purpose and key behavior. No extraneous text.

  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?

  Covers essential behavior for a simple tool with one parameter. Missing return value info but acceptable given no output schema.

  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 already fully describes parameter ('project_dir') with 100% coverage; description adds no additional semantics.

  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?

  Clearly states the action (import) and resource (snapshot file). Distinguishes from siblings like export_snapshot.

  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?

  Specifies non-destructive behavior and auto-run condition, but lacks explicit guidance on manual use cases or when to prefer this over alternatives.

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

• query_entriesA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses key behaviors: exact AND-combination, stable ID order, no ranking, that empty results are valid, and that superseded/deprecated entries are included unless filtered. This adds significant context beyond the schema.

  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, consisting of two sentences that efficiently convey the tool's core purpose, usage context, and key behavioral traits without any extraneous text.

  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 large number of parameters (16) and no output schema, the description provides high-level context and behavioral notes but does not explain the return format or pagination. However, it is sufficiently complete for a query tool with well-documented parameters.

  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 baseline is 3. The description does not add new information about individual parameters beyond what is already in the schema, so it meets the minimum expectation.

  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 it is a structured field filter using exact AND-combined predicates, explicitly distinguishing it from relevance search. It specifies the behavior regarding stable ID order and no ranking, making the purpose 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 provides a clear use case: 'Use when you know the field values (e.g. absolute constraints scoped to 'hooks/').' It implies when not to use (not for free-form search) but does not explicitly compare to sibling tools like get_context or get_project_summary.

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

• export_snapshotA
  4.4/5.0
  Behavior4/5

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

  Discloses that the operation is non-destructive and specifies the exact file location and .gitattributes modification. With no annotations, the description adequately covers key behavioral traits.

  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?

  Two concise sentences with no fluff. The action is stated first, then purpose and side effects. Every sentence is meaningful.

  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 simple tool with one parameter and no output schema, the description covers the action, output location, side effects, and use case. It does not mention return value or error scenarios, but these are less critical for an export tool.

  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 already describes the single parameter, but the description adds value by explaining that the snapshot is placed next to the project, which provides context about how the parameter is used.

  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 exports the whole store to a compressed snapshot at a specific path, and adds a .gitattributes guard. It distinguishes from sibling tools like import_snapshot and mirror.

  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?

  Explicitly states 'For sharing project memory with a team via git', providing a clear use case. However, it does not explicitly contrast with alternatives like import_snapshot or describe when not to use it.

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