Server Quality Checklist

Tool Scores

• delete_checkpointC
  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 but only states the action without disclosing behavioral traits. It doesn't mention if deletion is permanent, requires specific permissions, has side effects, or what happens on success/failure. This is inadequate for a destructive operation.

  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, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly.

  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?

  For a destructive tool with no annotations and no output schema, the description is incomplete. It lacks critical context like permanence, error handling, or prerequisites, leaving significant gaps for safe and effective use.

  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 schema fully documents the 'name' parameter. The description adds no additional meaning beyond implying the checkpoint must exist and be unneeded, but doesn't specify format or constraints. Baseline 3 is appropriate as the schema does the heavy lifting.

  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 ('Delete') and the resource ('a checkpoint'), making the purpose immediately understandable. It doesn't distinguish from siblings like 'reset_to_checkpoint' or 'list_checkpoints', but it's not tautological or misleading.

  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 provides minimal guidance with 'you no longer need', which implies usage for cleanup, but offers no explicit when-to-use rules, alternatives, or exclusions compared to siblings like 'reset_to_checkpoint'. This leaves gaps in decision-making context.

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

• list_checkpointsB
  3.4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It discloses that the tool lists checkpoints with creation times and notes, which is useful behavioral context. However, it doesn't mention potential limitations like pagination, sorting, or error conditions, leaving gaps in transparency for a read operation.

  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 that are front-loaded and waste-free. The first sentence states the core purpose, and the second adds specific details about what information is shown, making it efficient and well-structured.

  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's simplicity (0 parameters, no output schema, no annotations), the description is adequate but minimal. It covers the basic purpose and output details, but for a tool with siblings, more context on differentiation would enhance completeness. It meets the minimum viable standard without being fully comprehensive.

  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 has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a high baseline score for not adding unnecessary information.

  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 resource ('all available checkpoints for the current session'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'checkpoint_context' or 'get_context_stats', which might also relate to checkpoints, so it doesn't reach the highest score.

  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 provides no guidance on when to use this tool versus alternatives like 'checkpoint_context' or 'delete_checkpoint'. It implies usage for viewing checkpoints but lacks explicit when/when-not instructions or prerequisites, leaving the agent to infer context.

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

• reset_to_checkpointA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively explains the tool's behavior: it resets context to a checkpoint, injects a handoff message that appears as if written just before reset, and describes what happens after calling ('your context will be restored to the checkpoint state plus your handoff message'). It doesn't cover potential side effects or error conditions, but provides substantial 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?

  The description is well-structured and appropriately sized. It starts with the core purpose, then explains the handoff message feature with specific guidance on content, and concludes with the post-call effect. Every sentence adds value without redundancy, making it efficient and front-loaded with the most important 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?

  For a tool with 2 parameters, 100% schema coverage, no output schema, and no annotations, the description provides substantial context about the tool's purpose, behavior, and usage. It explains the unique handoff message feature thoroughly. The main gap is the lack of information about what happens to unsaved work or whether the reset is reversible, but overall it's quite complete for this complexity level.

  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% description coverage, providing clear documentation for both parameters. The description adds some semantic context by explaining the purpose of 'message_to_self' ('briefing message for your future self') and what it should contain, but doesn't add significant meaning beyond what the schema already provides. This meets the baseline expectation when schema coverage is high.

  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 with specific verbs ('reset your context back to a saved checkpoint') and resources ('checkpoint'), and distinguishes it from siblings by mentioning the unique 'handoff message' feature. It goes beyond a simple reset operation by explaining the message injection aspect.

  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 about when to use this tool ('to reset your context back to a saved checkpoint') and what the handoff message should contain, but doesn't explicitly state when NOT to use it or mention alternatives like 'checkpoint_context' or 'delete_checkpoint' from the sibling list. The guidance is helpful but lacks explicit exclusion criteria.

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

• checkpoint_contextA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It explains what the tool does ('captures your entire conversation history up to this point') and provides context about when it's useful. However, it doesn't mention potential limitations like storage constraints, whether checkpoints persist across sessions, or error conditions.

  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 efficiently structured with a clear purpose statement followed by bulleted usage guidelines. Every sentence adds value, and the information is front-loaded with the core functionality stated first. No wasted words or redundant 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?

  For a tool with no annotations and no output schema, the description does well at explaining what the tool does and when to use it. However, it doesn't describe what the tool returns (e.g., success confirmation, checkpoint ID) or potential error cases, leaving some gaps in 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%, so the schema already documents both parameters (name and note) with good descriptions. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline of 3 for high schema coverage.

  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 specific action ('Save your current context state as a named checkpoint') and distinguishes it from sibling tools like delete_checkpoint, list_checkpoints, and reset_to_checkpoint. It explains what resource is being operated on (context state) and the verb (save).

  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 provides explicit guidance on when to use this tool with three specific examples ('After fully understanding a codebase or task', 'Before starting a large, context-heavy operation', 'When you feel sharp and well-oriented'). It doesn't mention when not to use it or alternatives, but the clear positive guidance earns a top score.

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

• get_context_statsA
  4.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 behavioral traits by listing what the tool returns (turns, token count, compaction events, context age) and its purpose for decision-making. However, it doesn't cover aspects like performance, error conditions, or rate limits, leaving some gaps in 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?

  The description is appropriately sized and front-loaded: it starts with the core purpose, lists returns in a bulleted format for clarity, and ends with usage guidance. 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.

  Completeness4/5

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

  Given the tool's complexity (simple read operation with no parameters) and lack of annotations/output schema, the description is mostly complete. It explains what the tool does, what it returns, and when to use it. A minor gap is the absence of output format details, but this is mitigated by the straightforward return list.

  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 tool has 0 parameters with 100% schema description coverage. The description doesn't need to add parameter semantics, so a baseline of 4 is appropriate as it compensates by providing clear output information and usage guidance without unnecessary parameter details.

  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 with specific verb ('Get') and resource ('statistics about your current context window health'), and distinguishes it from sibling tools by focusing on monitoring rather than manipulation (checkpointing, deleting, listing, resetting).

  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 states when to use this tool: 'Use this to decide when you might want to checkpoint or reset.' It provides clear context for usage and distinguishes it from sibling tools by indicating it's for decision-making before taking actions like checkpointing or resetting.

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