Server Quality Checklist

Tool Scores

• list_sessionsA
  4/5.0
  Behavior3/5

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

  No annotations provided, so description carries burden. It states it returns title, date, turn count, and id, implying a read-only operation, but doesn't mention rate limits or data freshness. Adequate but not thorough.

  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, front-loaded with purpose, no superfluous information. 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?

  For a simple list operation with only 2 optional parameters and no output schema, the description covers return fields, grouping behavior, and usage context. Slightly more could be said about ordering or data source, but it's sufficient.

  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 description does not need to add much. The description mentions grouping by project directory, but both parameters are already described in schema (cwd filter and limit). No added semantics beyond 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 the tool lists recent Claude Code conversations across all projects, grouped by project directory. It distinguishes from siblings like load_session, search_in_session, etc., which are different operations.

  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?

  Explicit examples of when to use: answering 'what sessions have I worked on recently?' or finding a past session before loading it. No explicit exclusions, but context is clear.

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

• search_sessionsA
  4/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 full burden. It discloses that it searches across all projects, matches specific fields, and returns matching sessions with IDs. However, it doesn't mention pagination, rate limits, or whether results are ordered, which are common behavioral traits. Adequate but not comprehensive.

  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, front-loaded with key information, no superfluous words. Every sentence earns its place: first explains what the tool does, second provides usage guidance and return 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 2 parameters, no output schema, and no annotations, the description is reasonably complete. It specifies what fields are searched, that it searches across all projects, and that it returns IDs. It could mention default limit or sorting, but overall sufficient for an agent to invoke correctly.

  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% (both query and limit are described in the schema). The description reinforces the query parameter by mentioning 'by keyword' but adds no new semantic detail 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 searches past Claude Code conversations by keyword, matching session titles, first messages, and project paths. It specifies the resource (conversations) and action (search), and distinguishes from siblings like list_sessions (which likely lists all) and search_in_session (which searches within a session).

  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 states when to use: 'when the user refers to a past conversation by topic.' It provides an example. While it doesn't mention when not to use or alternatives explicitly, the sibling tools imply differentiation, so it's clear enough.

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

• search_in_sessionA
  4.2/5.0
  Behavior3/5

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

  No annotations exist, so description must cover behavior. It states returns matching turns with turn numbers, but omits details like case sensitivity or search scope. Adequate but not exhaustive.

  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 front-load purpose and then provide usage guidance. No redundancy or wasted 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 search tool with no output schema or annotations, description covers purpose, usage, and parameter semantics reasonably well. Could elaborate on output format but is 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 description coverage is 100%. Description adds value by explaining how to use parameters (e.g., session by id or free-text, query keyword). This enhances understanding beyond 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 the tool finds specific turns within one past conversation by keyword, returning matching turns with turn numbers. It differentiates from sibling tools like list_sessions and load_session by focusing on internal search.

  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?

  Explicit guidance is given: use when the user asks about a topic inside a known or large session, with an example. It does not explicitly list when not to use or alternatives, but the context is clear.

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

• session_outlineA
  4.4/5.0
  Behavior4/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 states 'Very cheap even for huge sessions' indicating efficiency and non-destructiveness. It describes output as a 'numbered list of user prompts.' It could add details like output format exactness, but it's fairly transparent about behavior.

  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 three sentences, front-loaded with the core purpose and key features. Each sentence adds essential information: output, efficiency/use case, and identification method with sibling reference. 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?

  Given no output schema, the description explains the return value: 'numbered list of the user's prompts, one line each.' It covers identification and use cases. It could mention error scenarios or limitations, but for a simple tool 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?

  Schema coverage is 100%, so baseline is 3. The description adds value by explaining how parameters relate to usage: 'Identify the session by id or free-text query' and linking to load_session. This provides context beyond the schema 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 action: 'Get a quick MAP of a past Claude Code conversation: the numbered list of the user's prompts, one line each.' It uses specific verb and resource and distinguishes from siblings by noting it provides outlines and turn numbers for use with load_session.

  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 indicates when to use: 'to see what a session covered, or to find which turn numbers to then load with load_session's turns.' It also explains identification by id or query. It does not explicitly state when not to use, but the context implies alternatives like load_session for full content.

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

• load_sessionA
  4.6/5.0
  Behavior4/5

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

  With no annotations, the description details the output content (elided tool outputs, collapsed summaries) and parameters (turns range, maxTokens limit, includeThinking). It is transparent about what the tool does and does not include, though it could mention error handling or side effects.

  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 well-structured, front-loading the main action and then providing parameter guidance. It is concise with no redundant sentences, though slightly longer than necessary.

  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 6 parameters, no output schema, and multiple siblings, the description covers key aspects: parameter usage, alternative tools for large sessions, and output format. It is complete enough for an agent to use correctly, though it lacks return value details beyond the initial statement.

  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?

  100% schema coverage, and the description adds significant value: explains id source (list_sessions/search_sessions), turns syntax (e.g., '300-340'), default format (compact), default maxTokens (16000), and the meaning of includeThinking. This goes well 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 clearly states it loads a past conversation as compact Markdown, specifying what is included (human turns, collapsed tool-call summaries, assistant replies) and what is elided (tool outputs). It distinctly differentiates from siblings like list_sessions and session_outline.

  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 says when to use: 'Use this to pull a previous conversation's context into the current session.' Provides when-not-to-use guidance for large sessions, suggesting session_outline or search_in_session instead, and references alternatives like list_sessions/search_sessions for ids.

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