Server Quality Checklist

Tool Scores

• blameA
  4.1/5.0
  Behavior4/5

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

  Annotations already indicate readOnlyHint=true, so the description adds value by explaining it covers AI session history, not git commit history, and that results are sorted by specificity.

  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?

  Well front-loaded with main purpose and use cases. A bit wordy but informative; could be streamlined slightly but still effective.

  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?

  Context about when to use is thorough, and sibling tools are memory-related so blame fits. However, no output schema and no description of return format limits completeness.

  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 33% (path has description, since has description) but description only clarifies path parameter format. Other parameters (all, limit, harness, project) are not mentioned, leaving gaps.

  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 tool finds prior sessions discussing a file, distinguishes from git blame, and gives specific use cases (before editing, refactoring, deleting, or when user asks why).

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

  Usage Guidelines5/5

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

  Explicitly instructs when to call: before file changes or when user queries intent. Also clarifies what it is not (git blame), helping avoid misuse.

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

• howA
  4.4/5.0
  Behavior4/5

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

  Beyond the readOnlyHint annotation, the description reveals the data source (commands user's agents ran), ordering (by number of separate sessions), and that records are excluded from ordinary search. It does not detail error conditions or response format, but the added source and ranking context is valuable.

  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 well-structured and front-loaded: it defines the output in the first sentence, gives a direct use case in the second, then details query parameters and uniqueness. Every sentence contributes, with no unnecessary words.

  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 retrieval tool with no output schema, the description is comprehensive: it explains what, how, when, and why, and notes the scope parameter. It doesn't describe the return shape, but the essential context for invoking correctly is present.

  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 fully covers all three parameters with descriptions, so the baseline is 3. The description adds example queries and reiterates the 'every word must appear' constraint, but it doesn't introduce significant semantic detail 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 states exactly what the tool does: returns the real command with real flags used by this user on this machine, sourced from agent-run commands and ordered by session frequency. It clearly distinguishes itself from ordinary search by noting command records are kept out of it, separating it from sibling tools.

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

  Usage Guidelines5/5

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

  The description explicitly tells the agent when to use it: 'Call before inventing a build, test, deploy or debug invocation.' It also warns that guessed commands are plausible and fail, providing clear context for preferring this tool over alternatives.

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

• rememberA
  4.5/5.0
  Behavior4/5

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

  The description adds meaningful context beyond the readOnlyHint=false annotation: it states memory is durable and persisted for future sessions, and it imposes content constraints (self-contained, single fact). While it doesn't mention side effects like storage limits or overwrites, the tool is conceptually simple and the description adequately 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.

  Conciseness4/5

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

  The description is longer than two sentences but every sentence serves a purpose: defining the action, giving trigger scenarios, specifying content format, and listing exclusions. It is front-loaded with the core purpose and stays focused. Slightly dense but not wasteful.

  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 write-only tool with no output schema, this description is thorough. It explains the tool's role, content guidelines, defaults, and even provides a concrete example. The absence of return-value documentation is acceptable since there is no output schema, and the schema already documents the parameters. A small gap is not explaining how 'tags' interrelate, but that's a minor omission.

  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?

  Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the desired format of 'text' (self-contained, one fact, with example), and by clarifying the 'project' default ('defaults to notes'), which mirrors the schema but reinforces practical usage. It doesn't mention tags, but the schema already describes them. This enriches beyond the schema without duplicating it.

  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 ('Store one durable decision or conclusion') and immediately explains the intended scope (durable, for future sessions). It distinguishes from siblings by explicitly framing this as the writing counterpart to recall, using concrete trigger phrases like 'remember this' and 'don't forget.'

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

  Usage Guidelines5/5

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

  The description gives explicit when-to-use examples (after a decision, bug resolved, user asks to remember) and clear when-not-to-use exclusions (no transcripts, routine conversation, or code-obvious facts). This is strong operational guidance with no ambiguity.

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

• fixA
  4.7/5.0
  Behavior5/5

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

  Goes well beyond annotations by explaining that results are evidence from the user's own history, not guaranteed fixes, and that every line of a stack trace is checked. It also discloses the meaning of an empty result, which is essential for correct interpretation.

  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?

  Every sentence provides unique, necessary information without redundancy. The description is well-organized, front-loading the core action and then adding important caveats and result interpretation.

  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?

  Despite having no output schema, the description fully explains what to expect (commands, empty result, non-guarantee), making the tool's behavior complete and self-contained. The complexity is moderate, and the description covers all necessary aspects.

  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 already describes both parameters (error and limit), but the description adds value by clarifying that entire stack traces are acceptable and that all lines are checked. This enhances the meaning of the error parameter beyond the schema's generic description.

  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 returns commands that followed a given error in past sessions, with the specific usage of passing failing output verbatim. It distinguishes itself from sibling tools by focusing on error-to-command history recovery, not generic recall or diagnostics.

  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 explicitly says to use this tool when hitting an error before diagnosing, and gives clear instructions to pass the failing output verbatim. It does not discuss alternatives or when not to use it, but the context is clear enough to infer appropriate usage.

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

• recall_contextA
  4.8/5.0
  Behavior5/5

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

  Beyond the readOnlyHint annotation, the description discloses matching semantics (query terms matched verbatim against transcript text), output specificity (one digest, not many), and the expected user-facing deja-vu line. It also instructs not to mention recalls that did not help, adding useful behavioral context.

  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 front-loaded with the core purpose and remains dense without fluff. Some longer usage instructions about when to mention the recall could be trimmed, but each sentence contributes meaningful guidance for tool selection and invocation.

  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?

  Given no output schema and no title, the description fully compensates by specifying output size and content (markdown digest, problem/decisions/outcome), matching behavior, when to use it, and the interaction protocol for surfacing results to the user. The tool is complex enough that this level of detail is necessary and sufficient.

  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?

  Schema coverage is 100% and both parameters are documented, so the baseline is 3. The description adds valuable guidance on how to construct the query parameter—using verbatim tokens like error strings, function names, or flags—which goes beyond the schema's generic 'Search terms identifying the session to digest.'

  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 returns a full markdown digest of the single best-matching prior session, covering problem, decisions, and outcome. It distinguishes itself from the sibling recall tool by emphasizing one deep digest versus browsing many sessions.

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

  Usage Guidelines5/5

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

  The description explicitly says to use it after recall, or directly when the user asks to be reminded how something was handled. It also gives an exclusion criterion: 'Not for browsing many sessions — use recall for that,' naming the alternative sibling tool directly.

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

• recallA
  4.9/5.0
  Behavior5/5

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

  Beyond of readOnlyHint=true, the description fully discloses behavior: returns only ~4KB chunks of dense text, result markers represent the user's later judgment, and the expected user-facing response format with a specific line ('deja-vu recalled'). It also communicates that failed recalls should not be reported, adding valuable behavioral context above 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?

  Despite being several sentences long, every sentence is purposeful: it covers what the tool does, when to call it (with examples), how to query, what distinguishes it from related tools, and how to report results. The description is front-loaded with the core function and ends with actionable output behavior, showing excellent information density without waste.

  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?

  Given no output schema, the description suitably conveys what the caller should expect: dense text under ~4KB, bracketed markers carry user judgment, and follow-up via recall_context when a match is complete. It also explains the output behavior so the agent knows how to present results. The combination of everything is complete enough for correct invocation and interaction.

  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 already provides 100% coverage: query, limit, offset, and harness are each described. However, the description adds actionable guidance for the query parameter, directing to use the most specific token (exact error string, function name, file path, flag) and confirming multiple words are ANDed. This is a meaningful supplement beyond the schema's 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?

  The description clearly states the tool's primary function: 'Search the user's own past coding sessions across every AI tool they've used' and return matches as dense text. It explicitly differentiates itself from the recall_context sibling by naming it as the follow-up tool, and scopes itself to prior user sessions, preventing confusion with general-knowledge search.

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

  Usage Guidelines5/5

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

  The description is exemplary with explicit when-to-use triggers like 'the moment the user implies work already happened' with concrete phrases ('didn't we fix this before?'), plus a mandatory rule: 'always before debugging an error or re-implementing something that might already exist.' It also states when not to use it, explicitly excluding general knowledge and API docs, and points to recall_context as the alternative.

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