Server Quality Checklist

Tool Scores

• uninstall_mcpC
  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 carries full burden. It states this is a removal operation, implying mutation/destructive action, but doesn't disclose behavioral traits like whether this requires specific permissions, whether the removal is reversible, what happens to the client configuration, or any rate limits. For a mutation tool with zero annotation coverage, this is inadequate.

  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 that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with every word earning its place.

  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?

  Given this is a mutation tool with no annotations, no output schema, and 2 parameters, the description is incomplete. It doesn't address what happens after removal, potential side effects, error conditions, or return values. For a destructive operation, more context about behavior and outcomes is needed.

  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 (mcp_id, client) with descriptions and enum values. The description doesn't add any parameter meaning beyond what the schema provides, such as explaining what constitutes a valid MCP identifier or the implications of choosing different clients. Baseline 3 is appropriate when 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 ('Remove') and target resource ('an MCP from a client configuration'), providing a specific verb+resource combination. It doesn't explicitly distinguish from siblings like 'list_installed' or 'sync_registry', but the removal action is distinct enough from listing/installation operations.

  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 versus alternatives. The description doesn't mention prerequisites (e.g., MCP must be installed first), when-not-to-use scenarios, or relationships to sibling tools like 'list_installed' (to check what's installed) or 'install_mcp' (the inverse operation).

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

• get_infoB
  3.2/5.0
  Behavior2/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 of behavioral disclosure. It states this is a read operation ('Get information'), implying it's non-destructive, but doesn't clarify aspects like authentication needs, rate limits, or response format. For a tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves beyond basic purpose.

  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 that front-loads the purpose ('Get information') and lists specific details without unnecessary words. Every element (installer, registry URL, cache location, supported clients) earns its place by clarifying scope, making it appropriately sized and structured for quick comprehension.

  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 low complexity (no parameters, no output schema, no annotations), the description is adequate but not fully complete. It covers the purpose and scope well, but without annotations or output schema, it should ideally mention behavioral traits (e.g., that it's a safe read operation) or response format to better guide usage. It meets minimum viability but has clear gaps in context.

  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 zero parameters, and schema description coverage is 100%, so there's no need for parameter details in the description. The baseline for zero parameters is 4, as the description appropriately omits parameter information. It doesn't add semantics beyond the schema, but that's acceptable given the lack of parameters.

  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's purpose with a specific verb ('Get') and enumerates the types of information retrieved (installer, registry URL, cache location, supported clients). It distinguishes itself from siblings like 'list_installed' or 'list_mcps' by focusing on system configuration rather than installed packages. However, it doesn't explicitly contrast with all siblings, preventing a perfect 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. It doesn't mention prerequisites (e.g., needing the installer running), exclusions (e.g., not for modifying settings), or comparisons to siblings like 'list_mcps' (which might list available packages). Without such context, users must infer usage from the purpose alone.

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

• install_mcpB
  3.2/5.0
  Behavior2/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 mentions secrets handling and implies installation actions, but fails to describe critical behaviors: whether this is a read/write operation, potential side effects (e.g., client restarts), error conditions, or response format. For a tool that modifies client configurations, this is a significant gap in transparency.

  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 that directly address the core action and a key constraint (secrets). It's front-loaded with the main purpose and wastes no words, making it easy to parse quickly while still providing essential context.

  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?

  Given the tool's complexity (installation with 4 parameters, no annotations, and no output schema), the description is insufficient. It doesn't explain what happens on success/failure, return values, or interactions with siblings like 'list_installed'. For a mutation tool with rich parameters, more context is needed to guide 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%, providing detailed parameter documentation. The description adds minimal value beyond the schema, only implicitly referencing 'secrets' without explaining their role or format. Since the schema already covers parameters thoroughly, the baseline score of 3 is appropriate, as the description doesn't significantly enhance parameter understanding.

  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 ('Install') and resource ('a single MCP to a client'), making the purpose immediately understandable. It distinguishes from siblings like 'install_all' (which installs multiple) and 'uninstall_mcp' (which removes). However, it doesn't explicitly differentiate from 'sync_registry' or other installation-related tools, keeping it from a perfect score.

  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 implied usage by mentioning secrets requirements, suggesting when to use this tool (for single MCP installation with optional secrets). However, it lacks explicit guidance on when to choose this over 'install_all' (for bulk) or prerequisites like needing 'list_mcps' first, which is only hinted in the schema. No clear exclusions or alternatives are stated.

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

• list_installedB
  3.2/5.0
  Behavior2/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 states the tool shows installed MCPs but doesn't disclose behavioral traits such as whether it's read-only, what the output format is (e.g., list, JSON), if there are rate limits, or any authentication needs. This leaves significant gaps in understanding how the tool behaves.

  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 that front-loads the purpose ('Show what MCPs are already installed') and specifies the scope. There is no wasted text, making it appropriately sized and well-structured for quick understanding.

  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?

  Given no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a list of MCP names, details), behavioral aspects, or error handling. For a tool with one parameter but missing structured output info, more context is needed to be fully helpful.

  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%, with the parameter 'client' fully documented in the schema (including enum values and default). The description adds minimal value by mentioning 'specific client or all clients', which aligns with the schema but doesn't provide additional semantics beyond what's already structured.

  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 'Show' and the resource 'MCPs already installed', specifying the scope as 'in a specific client or all clients'. It distinguishes from siblings like 'list_mcps' (which likely lists available MCPs) by focusing on installed ones, though it doesn't explicitly name the distinction.

  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 needing to check installed MCPs, with the parameter 'client' allowing filtering. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_info' (which might provide client details) or 'list_mcps' (which might list available MCPs), leaving usage context somewhat inferred.

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

• list_mcpsB
  3.3/5.0
  Behavior2/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 of behavioral disclosure. It mentions filtering capabilities but doesn't describe key behaviors such as pagination, rate limits, authentication requirements, or what the output format looks like (e.g., list structure, fields included). For a read operation with zero annotation coverage, this leaves significant gaps.

  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 that front-loads the core purpose ('List all available MCPs in the registry') and succinctly adds filtering options. Every word earns its place with no redundancy or wasted text, making it highly concise 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 moderate complexity (listing with filters), no annotations, and no output schema, the description is minimally adequate but incomplete. It covers the purpose and basic usage but lacks details on behavioral traits and output format, which are crucial for an agent to use it effectively without trial and error.

  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 input schema already fully documents both parameters ('category' and 'essential_only') with clear descriptions. The description adds no additional meaning beyond what the schema provides, such as examples of categories or implications of filtering. Baseline 3 is appropriate when 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 tool's purpose with a specific verb ('List') and resource ('all available MCPs in the registry'), making it easy to understand what it does. However, it doesn't explicitly differentiate from sibling tools like 'list_installed' or 'get_info', which might offer similar listing functionality with different scopes.

  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 by mentioning filtering options ('by category or show only essential MCPs'), but it doesn't provide explicit guidance on when to use this tool versus alternatives like 'list_installed' or 'get_info'. No exclusions or prerequisites are stated, 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.

• install_allA
  3.9/5.0
  Behavior3/5

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

  With no annotations, the description carries full burden. It discloses key behavioral traits: it can install all or essential MCPs, skips MCPs needing secrets unless provided, and implies batch operation. However, it doesn't cover important aspects like whether installation is destructive to existing configurations, authentication requirements beyond secrets, error handling, or rate limits.

  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 that front-loads the core purpose and includes all essential qualifications. Every word earns its place with no redundancy or unnecessary elaboration.

  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?

  For a tool with 4 parameters, no annotations, and no output schema, the description is adequate but has clear gaps. It explains the what and some behavioral constraints, but doesn't cover return values, error conditions, or detailed operational context that would be helpful for an agent.

  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 all 4 parameters. The description adds no specific parameter information beyond what's in the schema, but doesn't need to compensate for gaps. The baseline 3 is appropriate when schema does the heavy lifting.

  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 action ('Install all MCPs'), specifies the target ('to a client'), and distinguishes from siblings by mentioning the optional scope ('or just essential ones') and secret-handling behavior. It's more comprehensive than the sibling 'install_mcp' which presumably installs individual MCPs.

  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 implies when to use this tool (bulk installation with optional filtering) versus alternatives like 'install_mcp' (single MCP installation), but doesn't explicitly name alternatives or state when not to use it. It provides context about secret handling but lacks explicit exclusions.

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

• sync_registryA
  4.1/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 the tool's purpose (updating cache from GitHub) but lacks details on behavioral traits like potential rate limits, network dependencies, authentication needs, or what happens if GitHub is unreachable. The description adds basic context but doesn't fully compensate for the absence of 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?

  The description is two concise sentences with zero waste. The first sentence states the core action and resource, and the second provides clear usage context. It's front-loaded and appropriately sized for the tool's 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 the tool's moderate complexity (network operation to update cache), lack of annotations, and no output schema, the description is somewhat complete but has gaps. It explains the purpose and usage but doesn't cover behavioral aspects like error handling or response format. It's adequate as a minimum viable description but could be more 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 100% description coverage, with the 'force' parameter well-documented in the schema. The description doesn't add any parameter-specific information beyond what the schema provides, but since there's only one optional parameter with full schema coverage, the baseline is high. No additional semantic value is needed here.

  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 ('Update the local registry cache') and resource ('from GitHub'), with explicit purpose ('to get the latest MCP list'). It distinguishes from siblings like 'list_mcps' (which likely shows cached data) by emphasizing the refresh/update function.

  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 for when to use this tool ('to get the latest MCP list'), implying it should be used when fresh data is needed. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools, such as contrasting with 'list_mcps' for cached vs. fresh data.

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