Server Quality Checklist

Tool Scores

• declared_mcp_serversA
  3.8/5.0
  Behavior4/5

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

  The description discloses a key behavioral trait: 'Values are never read', which is a strong privacy guarantee. It also clarifies the scope of information returned. Since no annotations are provided, this disclosure adds meaningful behavioral context, though it does not cover all potential behaviors (e.g., handling of missing .mcp.json files).

  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 front-loads the core purpose and then provides a concise, structured list of details. Every phrase adds value, and there is no redundant or explanatory fluff.

  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 inspection tool with one optional parameter and no output schema, the description provides sufficient context about what information is available, including the privacy note. It could be more complete by explicitly stating that it returns a list of servers, but this is strongly implied by the phrasing.

  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 already provides a complete description for the single 'dir' parameter, including its default behavior. The tool description adds no additional parameter-level information, so 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.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as returning information about MCP servers declared by the checkout, with a detailed list of what aspects are covered (launch command, package registry fetching, filesystem paths, environment variable names). However, it lacks an explicit verb like 'list' or 'inspect', making it slightly less actionable than ideal, though the title partially compensates.

  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 usage is implied: an agent would use this when needing to know which MCP servers a checkout declares. However, there is no explicit 'when to use' guidance or reference to sibling tools (e.g., instruction_files) to differentiate use cases, so the guidance remains implicit rather than explicit.

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

• auto_run_commandsA
  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 burden of disclosing behavior. It says 'Shows' and details the output, clearly implying a read-only inspection that does not execute hooks. However, it doesn't explicitly state that no commands are run or that no modifications occur, leaving a slight 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 an efficient two-sentence structure that front-loads the core purpose and then adds relevant detail. Every sentence earns its place with no filler.

  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 listing tool, the description covers the source (settings files), the output (command, trigger, script location status), and the optional input (via schema). It lacks an explicit read-only statement but is otherwise complete for its complexity.

  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 single 'dir' parameter is fully described in the schema (100% coverage) with defaults and meaning. The tool description adds no additional parameter semantics, so the baseline 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 identifies the tool's purpose: it shows hook commands declared in the checkout's settings files, including the command, trigger, and script location. This is specific and distinct from sibling tools that inspect MCP servers, summaries, instruction files, and agent extensions.

  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 when one wants to inspect configured hook commands, but it does not explicitly state when to use this over alternatives or provide exclusions. No mention of sibling tools or scenarios where this tool would be inappropriate.

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

• agent_extensionsA
  4.1/5.0
  Behavior4/5

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

  With no annotations, the description carries the transparency burden and does well by disclosing key behaviors: it searches root or one/two levels down, counts distinct extensions and markdown files, and explicitly states 'contents are never returned.' It omits details like output format or error behavior, but the essential behavioral facts are present.

  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 three sentences with useful scoping details, though the first sentence is long and packs the action verb later in the paragraph ('Counts...'). There is minimal redundancy, but it could be slightly more front-loaded, so it earns a 4 rather than a 5.

  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?

  Although there is no output schema, the description compensates by stating what is returned (counts, names, and sizes) and where it looks. It does not address edge cases like a missing directory or symlink behavior, but for a simple read-only inspection tool the essential context is covered.

  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 already fully documents the single optional `dir` parameter with 100% coverage, including its default behavior. The description adds no parameter-specific meaning beyond what the schema provides, so the baseline score of 3 applies.

  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 action ('Counts distinct extensions and the markdown files they carry') and clearly identifies the resource (`.claude/` or `.agents/` directories). It also distinguishes itself from sibling tools by scoping to skills, slash commands, subagents, and plugin markers, and explicitly states the output limitation ('Names and sizes only').

  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?

  Provides clear context on when to use the tool: it inspects agent extensions shipped in the checkout and handles monorepo layouts ('one to two levels down'). However, it never explicitly contrasts with sibling tools like instruction_files or declared_mcp_servers, nor states 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.

• instruction_filesA
  4.3/5.0
  Behavior4/5

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

  Despite no annotations, the description discloses a critical behavioral constraint: file contents are never returned, so the agent must open paths itself. It also mentions imports resolving outside the repo, adding context beyond simple listing. This is strong disclosure for a read-only metadata tool.

  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: the first enumerates what the tool returns, the second states a key limitation. Every word contributes, and the structure is well front-loaded.

  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?

  With no output schema, the description must convey return values, and it does: files with size, estimated token cost, and @import lines. It also tells the agent that contents are not included. This is complete for a simple, single-parameter listing 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?

  The input schema fully describes the only parameter 'dir' with default behavior, achieving 100% coverage. The description adds no additional parameter detail, so it meets the baseline but doesn't exceed 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 clearly identifies the tool's output: all instruction files (CLAUDE.md, AGENTS.md, .cursorrules, etc.) with size, token cost, and @import details. This is specific and distinct from sibling tools which cover MCP servers, summaries, commands, and extensions.

  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 purpose is evident: use when you need to know which instruction files exist and their imports/costs. It doesn't explicitly state exclusions or alternatives, but the sibling tools are semantically different, making the use case clear without further guidance.

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

• inherited_summaryA
  4.5/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 the full burden. It clearly explains the tool returns a 'headline count' (not detailed content) and enumerates exactly what categories it covers. It does not explicitly state read-only behavior, but the nature of a count implies it, and all listed items are inspection targets.

  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, front-loaded with 'Start here,' and every word adds value. It concisely lists the included categories and provides usage context without any fluff.

  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?

  For a summary tool, the description fully covers its scope, purpose, and when to use it. Given the simple one-parameter schema and no output schema, it provides sufficient context for an agent to select and invoke the tool correctly. The sibling tools are implicitly referenced by the categories listed.

  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 already provides 100% coverage with a clear description of the 'dir' parameter. The tool description does not add additional meaning beyond the schema, so it meets the baseline but does not go beyond 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 clearly states the tool provides a 'headline count' of agent-related items in a directory, listing specific categories (instruction files, hook commands, MCP servers, etc.). This is a specific verb+resource and distinguishes it from sibling tools that likely drill into individual categories.

  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?

  Explicit guidance is given on when to use: 'Use before working in a repo you did not write, or when reviewing a PR that touches agent config.' The phrase 'Start here' also signals this is the intended entry point before using more specific sibling tools.

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