Server Quality Checklist

Tool Scores

• queryC
  2.7/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 searches/finds email messages, implying read-only, but does not explicitly declare side effects, permissions, or rate limits. The extensive focus on query syntax leaves behavioral traits unaddressed.

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

  Conciseness1/5

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

  The description is a huge wall of text, clearly copied from a man page. It is not front-loaded, and most of the content is irrelevant for an agent invoking the tool. Every sentence does not earn its place; the description is severely overlong and poorly structured.

  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 the existence of an output schema, the description does not explain return values or the overall behavior beyond finding messages. It discusses command-line options that are not part of the tool's parameters, creating confusion. The description is detailed for input but incomplete for the tool's actual interface and output.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description must compensate. It does so with a detailed guide on the query language, covering syntax, operators, fields, etc. This provides substantial meaning beyond the bare schema parameter name. However, the information is not structured as parameter-level docs and includes many options not reflected in the actual parameter (e.g., formatting options), which slightly reduces clarity.

  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 starts with 'Query `mu` by providing a valid query', clearly stating the verb and resource. It distinguishes from siblings (get_attachment, health_check, view) by focusing on searching mu. However, the purpose is somewhat buried in a large block of text, making it less immediately clear.

  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 explicit guidance on when to use this tool vs alternatives. The description provides examples but does not compare with siblings or state when not to use it. The agent must infer usage from context.

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

• get_attachmentB
  3.1/5.0
  Behavior3/5

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

  The description discloses that the tool downloads the attachment to a temp dir and opens it, and warns about the command prefix. However, it lacks details on side effects, idempotency, or permissions, and the manpage dump is noisy.

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

  Conciseness2/5

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

  The description is unnecessarily long, including a full man page. The key information is front-loaded but diluted by excessive detail, making it less efficient for an AI agent.

  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?

  The description does not explain the return value, error handling, or prerequisites despite having an output schema. It leaves gaps for an AI agent 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?

  The schema has 0% coverage, and the description adds meaning by stating that command includes paths and pattern, and warns about forbidden prefix. But it is not fully explicit about the expected format.

  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 first sentence clearly states the tool opens attachments in email by providing the email path. It distinguishes from sibling tools like health_check, query, and view.

  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 opening attachments but does not explicitly state when to use it versus alternatives or provide when-not-to-use guidance.

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

• health_checkB
  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 burden of disclosing behavior. It only says 'health check,' which implies a non-destructive read operation but does not specify details like what is checked or whether it affects server state.

  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?

  Extremely concise with one sentence that front-loads the purpose. No unnecessary words.

  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 simple tool with zero parameters and an output schema, the description is minimally adequate but lacks specifics like what the health check returns or covers. An output schema exists, so return values are documented, but the description could still add 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 no parameters, so the description does not need to add parameter details. The input schema is fully covered (100% coverage), but the description adds no additional value beyond stating the purpose.

  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 it's a health check for the MCP server, which distinguishes it from sibling tools like get_attachment, query, and view. However, it could be more specific about what 'health check' entails.

  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 on when to use this tool versus alternatives. For a health check, it's typically used to verify server status, but the description lacks explicit context or exclusion criteria.

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

• viewA
  3.6/5.0
  Behavior2/5

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

  No annotations are provided, and the description lacks any behavioral disclosure such as read-only nature, side effects, authentication needs, or error conditions. It only states the basic action.

  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 very concise at two sentences plus code examples, with no extraneous information. Every element serves a purpose.

  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 simplicity (one parameter, output schema exists), the description is largely complete. It covers the core action and provides a usage example, though it could mention expected output or behavior.

  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?

  With 0% schema description coverage, the description adds limited value by mentioning that paths come from mu find, but does not explain path format, constraints, or validation beyond the schema's title 'Paths'.

  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 'View emails using mu, by providing their paths,' which is a specific verb and resource. It includes an example and distinguishes from sibling tools like query and get_attachment.

  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 example of extracting paths via mu find, implying prerequisites, but does not explicitly state when to use this tool versus alternatives 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.