Server Quality Checklist

Tool Scores

• replay_insightsC
  2.8/5.0
  Behavior2/5

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

  With no annotations provided, the description must fully disclose behavioral traits. It only lists output fields but fails to mention whether the operation is read-only, if it has side effects, required permissions, error behavior for invalid session IDs, or performance implications. The description does not compensate for the missing annotation burden.

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

  Conciseness3/5

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

  The description is a single sentence listing multiple metrics, which is moderately concise but not optimally structured. It front-loads the key concept ('per-session insight metrics') but the list of metrics becomes dense. Adding bullet points or a clear delimiter would improve readability. The sentence is not overly long but could be more efficient.

  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?

  There is no output schema, so the description must cover return values. It lists several metrics but lacks details on data types, units (e.g., duration in seconds?), formatting, and edge cases (e.g., what happens if session_id is invalid or the session hasn't ended). It also doesn't explain how 'most-used tools' is represented. This incompleteness may lead to incorrect expectations.

  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% (the single parameter session_id has a description stating default behavior). The tool description adds context about the returned metrics but does not enhance understanding of the parameter beyond what the schema already provides. Baseline score 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 returns 'per-session insight metrics' and lists specific metrics like duration, tool-call count, error count/rate, and files touched. It uses a specific verb (retrieves) and resource (session insights), making the purpose clear. However, it does not explicitly differentiate from sibling tools like replay_stats or replay_sessions, leaving some ambiguity.

  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 when to use (to get detailed session metrics) but provides no guidance on when not to use, alternatives, or prerequisites. For example, it doesn't contrast with replay_stats (aggregate) or replay_sessions (list sessions). This lack of usage context forces the agent to infer appropriateness.

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

• replay_checkpointC
  2.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 full behavioral disclosure. It indicates a write/mutation operation ('force'), but does not disclose side effects, prerequisites, safety, or whether the action is reversible or idempotent.

  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 concise sentence with no redundant information. It efficiently communicates the core action, though it could benefit from more structure to include context without losing conciseness.

  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?

  Despite low complexity (1 optional parameter), the description lacks essential context: what a checkpoint is, how it affects the session, and what the outcome or return value is. Without annotations, an agent may misuse the tool.

  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% (the only parameter 'note' has a description). The description adds no additional meaning beyond the schema's 'Optional note describing the checkpoint'. Baseline 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 action ('force a checkpoint') and the resource ('current session'). The verb is specific and distinguishes this tool from sibling tools like replay_status, replay_resume, etc. However, it does not elaborate on what a checkpoint is, slightly limiting clarity.

  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 is provided about when to use this tool vs alternatives such as replay_status or replay_resume. The agent must rely solely on the tool name for context, which is insufficient for confident selection.

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

• replay_sessionsB
  3.1/5.0
  Behavior2/5

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

  No annotations are provided, so the description bears full responsibility for behavioral disclosure. It states 'List recent sessions' but does not clarify that this is a read-only operation, how 'recent' is defined (e.g., sorted by creation time), or any other behavioral traits like pagination or response format. The description is insufficient for an agent to understand the tool's side effects and constraints.

  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 a single sentence that is direct and efficient. It lists the key fields without unnecessary elaboration. Every word contributes to the purpose. No wasted space.

  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 is minimal for a simple tool with one parameter and no output schema or annotations. It covers the basic purpose and returned fields, but omits ordering, pagination, read-only nature, and relationship to sibling tools. It is adequately complete for a trivial list operation but leaves gaps that an agent might need to infer.

  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% (the single 'limit' parameter has a clear description). Baseline is 3. The description does not add additional meaning beyond the schema; it does not explain how the limit parameter interacts with 'recent' ordering or what the default behavior is. No extra value, but schema covers it adequately.

  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 verb 'list' and the resource 'sessions', and further specifies the fields included (status, model, duration, checkpoint count). This distinguishes it from siblings like 'replay_status' (which likely shows a single session's status) and 'replay_stats' (aggregated statistics). However, it does not explicitly differentiate from 'replay_search', which might also list sessions but with additional filtering criteria.

  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?

  There is no guidance on when to use this tool versus alternatives. No explicit conditions, prerequisites, or exclusions are provided. The implied use is for listing recent sessions, but without context on when to prefer this over 'replay_search' or 'replay_status'.

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

• replay_tagB
  3.4/5.0
  Behavior2/5

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

  No annotations are provided, so the description bears full responsibility for disclosing behavioral traits. It indicates the tool is a mutation (sets/removes tags) and mentions a default session, but it does not reveal whether operations are destructive (e.g., overwriting existing name), whether removing non-existent tags is safe, or what the response looks like. For a write tool with zero annotation coverage, this is insufficient.

  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 wasted words. The first sentence states the core purpose, and the second elaborates on the action and default. The description is front-loaded and efficient, earning every sentence.

  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 the tool has 4 optional parameters, no output schema, and no annotations, the description is adequate but incomplete. It covers the main operation and default session, but omits behavior details (e.g., what happens if both add and remove reference the same tag, whether the tool returns confirmation, or if it is safe to call repeatedly). More context would be needed for an agent to use it confidently.

  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%, so the baseline is 3. The description adds value beyond the schema by explaining the overall operation ('Sets a name and/or adds/removes tags') and the default behavior for session_id. It synthesizes the individual parameters into a coherent use case, which helps the agent understand how the parameters interact.

  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 uses a clear verb-resource pair ('Name or tag a session') and specifies the action ('Sets a name and/or adds/removes tags'). It distinguishes itself from sibling tools like replay_status or replay_checkpoint, but does not explicitly contrast with alternatives (e.g., replay_search). The purpose is clear but lacks direct sibling differentiation.

  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 an implicit usage clue by noting the default session ('default: the most recent'), which helps the agent understand when to omit session_id. However, there is no explicit guidance on when to use this tool versus alternatives (e.g., replay_search for retrieving by tags), nor any prerequisites or exclusions. The guidance is minimal but not absent.

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

• replay_searchA
  3.5/5.0
  Behavior3/5

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

  Without annotations, the description carries full behavioral burden. It discloses that results are 'ranked by match count' and that the query is optional for browsing by filters. However, it does not mention typical traits like response format, pagination, error handling, or any destructive implications, making it 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?

  The description is extremely concise at two sentences, with the core purpose front-loaded. Every sentence adds value: the first defines the action and scope, the second explains ranking and browsing mode. No waste.

  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?

  With 7 parameters, no annotations, and no output schema, the description should compensate by explaining results format and behavior. It covers input behavior (search, filters, ranking) but omits what the response contains, pagination limits, or error conditions. It is adequate for basic use but leaves gaps for a complex search tool.

  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 the baseline is 3. The description adds overall context about search behavior and query optionality, but does not provide additional meaning for specific parameters beyond what the schema already describes. The guidance on omitting query is the only extra semantic value.

  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 performs full-text search across recorded sessions with specific fields (event payloads, objective, name, tags) and optional filters, and that results are ranked by match count. While the purpose is specific and distinct from sibling tools like replay_sessions or replay_insights, the description does not explicitly differentiate itself from these alternatives.

  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 some usage guidance, such as 'Omit the query to browse by filters alone', which tells the agent when to omit the query. However, it lacks explicit context on when to use this tool versus siblings like replay_sessions or replay_insights, and does not state prerequisites or 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.

• replay_statusA
  3.7/5.0
  Behavior3/5

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

  With no annotations provided, the description carries full burden for behavioral transparency. It reveals the tool returns a summary (read-only), which is helpful, but does not mention whether it has side effects, requires a running session, or whether the 'current session' is reset on new calls. The description is adequate but leaves behavioral ambiguity.

  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 a single, concise sentence that front-loads the key output fields. Every word adds value with no redundancy.

  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 zero parameters, no output schema, and no annotations, the description provides a reasonable summary of what the tool returns. It could mention whether it requires an active session or how it relates to sibling tools, but overall it covers the essential purpose for a simple summarization 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 input schema is empty (0 parameters), so the description need not explain parameter details. However, it adds value by listing the fields included in the output (objective, status, counts, last activity), giving the agent an idea of what to expect despite no output schema.

  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 provides a current session summary with specific fields (objective, status, checkpoint/event counts, last activity). This is a specific verb+resource pattern and differentiates from siblings like replay_checkpoint (specific checkpoint operations) and replay_stats (likely numeric statistics).

  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 implies this is for getting a summary, but it doesn't explicitly state when to use it versus alternatives. Siblings like replay_checkpoint and replay_stats could overlap; without exclusion criteria, an agent might guess between them.

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

• replay_diffA
  3.8/5.0
  Behavior3/5

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

  With no annotations provided, the description partially carries the burden. It discloses that the tool computes deltas and file intersections but does not mention whether sessions must be complete, if it's read-only, or any side effects. Annotations would have helped.

  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 a single sentence that efficiently conveys purpose, behavior, and outputs with no wasted words. It is front-loaded with the core action.

  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's moderate complexity (2 string parameters, no output schema, no nested objects), the description is nearly complete. It explains what the tool does and outputs, though it could mention if output is returned directly or via some other means.

  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 description adds context about what comparison yields (metric deltas and file sets), but it does not provide format or validation beyond session IDs. Baseline 3 is appropriate as schema does the heavy listing.

  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 specifies comparing two sessions with explicit outputs (metric deltas and file touches). It distinguishes itself from siblings like replay_status or replay_checkpoint by clearly stating the comparison and side-by-side analysis.

  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 implies usage for comparing two sessions but does not explicitly state when to use this vs. alternatives like replay_insights or replay_stats. No exclusions or prerequisites (e.g., sessions must exist) are given.

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

• replay_statsA
  3.8/5.0
  Behavior3/5

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

  No annotations exist, so the description must carry the full burden of behavioral disclosure. The description implies a read-only operation by listing computed statistics, but it does not explicitly state that no data is modified, nor does it mention authorization, rate limits, or behavior with empty data. The lack of explicit safety guarantees is a gap, but the nature of the tool (analytics) provides reasonable inference.

  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—two sentences, 25 words—with no wasted words. It front-loads the core purpose ('Cross-session analytics') and immediately lists the specific metrics. Every sentence earns its place, and the structure is clear and scannable.

  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 tool has no output schema, so the description must adequately convey the return value. It lists the key metrics (total tool calls, error rate, death-cause breakdown, tool mix, per-project rollups), giving a solid picture of the output. However, it does not describe the format (e.g., JSON object, array, aggregation method) or edge cases (e.g., empty sessions). For a simple analytics tool with only two optional params, this is largely sufficient but not exhaustive.

  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 both parameters already having clear descriptions ('Only the N most recent sessions' and 'Only sessions whose project dir contains this'). The description adds a brief mention of 'Optional limit / project filter' but does not add new meaning beyond restating what the schema already conveys. Without additional semantic depth, the 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 the tool's purpose: 'Cross-session analytics across all recorded sessions.' It then lists specific metrics (total tool calls, error rate, death-cause breakdown, tool mix, per-project rollups), which leaves no ambiguity about what the tool does. This distinguishes it from siblings like replay_sessions (list sessions) or replay_insights (likely deeper analysis) by emphasizing aggregate statistics.

  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 implicitly conveys usage for obtaining aggregate session statistics, but it does not explicitly state when to use this tool versus alternatives (e.g., replay_sessions for raw session data, replay_insights for deeper patterns). No when-not guidance or alternative tool names are mentioned, which is a gap given nine sibling tools.

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

• replay_exportA
  3.9/5.0
  Behavior3/5

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

  No annotations are present, so the description carries full burden. It states the tool renders a trace and returns a path, but does not disclose whether it modifies state (e.g., creates files on disk, side effects), or if there are permissions, size limits, or blocking behavior. The description adds some value beyond the schema (output path return) but lacks rich 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.

  Conciseness5/5

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

  Single sentence with no wasted words. It front-loads the action ('Render a session') and ends with the output ('return the output path'). Perfectly sized for the complexity.

  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 3 parameters (all optional, no output schema), the description covers the core transformation but lacks detail on return format (just 'path'), side effects (file creation), and error cases (missing session). Adequate but not complete for a file-exporting 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?

  Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the tool takes a session, renders it as a trace, and returns a path, which provides semantic context for the unspecified session_id parameter and the default behavior. This elevates it above 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 uses specific verbs ('Render', 'return') and resources ('session as a self-contained trace'), explicitly naming the output formats ('html, json, or md') and the outcome ('output path'). This clearly distinguishes it from sibling tools like replay_status or replay_diff.

  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 implies use for exporting a session trace, but does not explicitly state when to use this over alternatives like replay_sessions (list sessions) or replay_tag (tag sessions). No when-not-to-use guidance or exclusion criteria are provided.

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

• replay_resumeA
  3.9/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 for behavioral disclosure. It states the tool generates a resume brief to paste into a new session, implying no destructive side effects. However, it does not explain whether the tool modifies state, what format the output is in, or any prerequisites (e.g., must the session be active?). These are acceptable gaps given the tool's simplicity and read-only nature.

  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 with two clauses, totalling 23 words. It is concise and front-loaded with the action. No wasted words. Could be slightly more structured by separating the instruction from the default behavior, but it remains effective.

  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 tool has a single optional parameter, no output schema, and no nested objects, so complexity is low. The description explains the tool's purpose (generate resume brief) and its intended use (paste into new session). It is complete enough for an agent to use correctly. A small gap: it does not specify the output format or length.

  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 the baseline is 3. The description adds context by stating the default behavior ('default: the most recent') beyond the schema's 'Session ID (default: most recent)'. This is helpful but not extensive, as the single parameter is well-documented.

  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 ('Generate') and noun ('resume brief') and clarifies the default behavior (most recent session). The action and purpose are unmistakably clear, distinguishing it from sibling tools that check status, create checkpoints, list sessions, etc.

  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 tells the agent when to use this tool: to continue work in a new Claude Code session. It implies the alternative is manual copy-paste or other workflow, and provides a clear use case. It does not explicitly list when not to use it or name alternative sibling tools for exclusion.

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