Server Quality Checklist

Tool Scores

• get_promptB
  3.2/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 key behavioral traits: it's a retrieval operation (implied by 'Get'), requires a connection (via 'not_connected' error), and handles various failure scenarios. However, it doesn't mention rate limits, caching behavior, or whether it's idempotent, which are gaps for a tool with no annotations.

  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 appropriately sized and front-loaded with the core purpose in the first sentence. The 'Returns' and 'Raises' sections are structured but slightly verbose; the error cases could be more concise. Overall, most sentences earn their place by clarifying behavior and outputs.

  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 parameters, no annotations, but with an output schema), the description is fairly complete. It explains the purpose, return structure, and error cases. Since an output schema exists, it doesn't need to detail return values extensively. However, it lacks usage context and some behavioral details, preventing a perfect score.

  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, so the baseline is 3. The description adds no additional meaning beyond what the schema provides for parameters 'name' and 'arguments'. It mentions 'arguments' in the context of matching a prompt schema, but this is covered by the 'invalid_arguments' error case rather than parameter semantics.

  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: 'Get a rendered prompt from the connected MCP server' with specific verb ('Get') and resource ('rendered prompt'). It distinguishes from siblings like 'list_prompts' (which lists rather than retrieves) and 'execute_prompt_with_llm' (which executes rather than just retrieves). However, it doesn't explicitly contrast with all siblings, so it's not a perfect 5.

  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 when to use 'get_prompt' versus 'list_prompts' (for listing available prompts) or 'execute_prompt_with_llm' (for executing a prompt with an LLM). There's no context about prerequisites like needing a connection first, though this is implied by the error cases.

  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?

  With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool returns a dictionary with status and server information, which is helpful, but doesn't cover other important aspects like whether it requires authentication, has rate limits, or what specific status codes or information might be included. The description is minimal and lacks depth for a tool with no annotation support.

  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 and front-loaded: the first sentence states the core purpose, and the second briefly notes the return format. There is no wasted text, and every sentence adds value, making it highly efficient.

  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 annotations, but has an output schema), the description is minimally adequate. It explains the purpose and return format, but with no annotations, it could benefit from more behavioral context (e.g., authentication needs, typical use cases). The output schema existence reduces the need to detail return values, but overall completeness is just sufficient.

  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 the schema fully documents the lack of inputs. The description doesn't need to add parameter details, and it appropriately avoids discussing parameters, earning a baseline score of 4 for this context.

  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: 'Health check endpoint that verifies the server is running.' It uses specific verbs ('verifies') and identifies the resource ('server'), but doesn't explicitly distinguish it from sibling tools like 'ping' or 'get_connection_status' which might serve similar diagnostic functions.

  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 'ping' or 'get_connection_status' from the sibling list. It states what the tool does but offers no context about appropriate use cases or exclusions.

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

• echoB
  3.3/5.0
  Behavior2/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 disclosure. While 'echo back' implies a read-only, non-destructive operation, it doesn't explicitly state safety characteristics, performance expectations, or error conditions. The description mentions what happens ('echo back') but lacks depth about behavioral traits like idempotency or side effects.

  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 perfectly concise and well-structured. The first sentence states the core purpose, followed by clear 'Args' and 'Returns' sections. Every sentence earns its place - no redundant information, no fluff. The formatting with headings enhances readability without adding unnecessary length.

  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 (single parameter, no annotations, but has output schema), the description is reasonably complete. The output schema existence means the description doesn't need to detail return values, and the purpose, parameter, and return behavior are all covered. For a straightforward echo tool, this provides adequate context, though it could benefit from more behavioral transparency.

  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 description adds meaningful context beyond the input schema. While schema_description_coverage is 0%, the description explicitly documents the single parameter ('message: The message to echo back') and its purpose. For a tool with only one parameter, this provides adequate semantic understanding, though it doesn't elaborate on constraints like message length or 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 description clearly states the tool's purpose with 'Echo back a message' - a specific verb ('echo back') and resource ('message'). It distinguishes from siblings like 'ping' or 'health_check' by focusing on message reflection rather than connectivity testing. However, it doesn't explicitly differentiate from all possible message-related tools.

  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. There's no mention of use cases, prerequisites, or comparison to sibling tools like 'ping' (which might also return messages) or 'execute_prompt_with_llm' (which processes messages). The agent receives no contextual decision-making help.

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

• read_resourceB
  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 of behavioral disclosure. It effectively describes the return structure and error scenarios, adding value beyond the input schema. However, it lacks details on permissions, rate limits, or side effects, which are important for a read operation in a server context.

  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 well-structured with clear sections (purpose, returns, raises) and avoids redundancy. However, the 'Returns' and 'Raises' sections could be more concise, as they detail output that might be covered by an output schema (which exists here), slightly reducing efficiency.

  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 one parameter with full schema coverage and an output schema present, the description provides adequate context by explaining the tool's purpose, return values, and error handling. It covers the essentials for a read operation, though it could benefit from more usage guidance or behavioral details to be 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 100% description coverage for its single parameter, so the baseline is 3. The description adds context by explaining that the URI is used to 'read a specific resource' and mentions example usage ('e.g., config://settings'), enhancing understanding beyond the schema's basic definition.

  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 'read' and resource 'specific resource from the connected MCP server', making the purpose evident. It distinguishes from siblings like 'list_resources' by focusing on individual retrieval rather than listing. However, it doesn't explicitly contrast with 'get_prompt' or other read-like 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 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 'list_resources' or 'get_prompt'. It mentions a 'connected MCP server' but doesn't specify prerequisites or exclusions, leaving usage context implied rather than explicit.

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

• addA
  3.5/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 states the operation ('Add two numbers together') and return value, but lacks details on error handling, performance, or constraints like input limits. This leaves gaps in understanding how the tool behaves beyond basic functionality.

  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 appropriately sized and front-loaded, starting with the core purpose. The structured sections (Args, Returns) enhance readability without redundancy. It could be slightly more concise by integrating the parameter details into a single sentence, but overall it's efficient.

  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 low complexity (simple arithmetic), no annotations, and an output schema that likely covers the return value, the description is mostly complete. It explains the operation and parameters adequately, though it could benefit from more behavioral context like error cases or usage examples.

  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 schema description coverage is 0%, so the description must compensate. It explicitly defines parameters 'a' and 'b' as 'First number' and 'Second number', adding clear meaning beyond the schema's type definitions. However, it doesn't specify constraints like number ranges, leaving some semantic gaps.

  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 ('Add two numbers together') and identifies the resource (numbers). It distinguishes itself from siblings like 'call_tool' or 'execute_prompt_with_llm' by focusing on basic arithmetic, making the purpose unambiguous and well-defined.

  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 lacks context about prerequisites, such as whether it's for simple calculations or part of a larger workflow, and doesn't mention any sibling tools as alternatives, leaving usage entirely implicit.

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

• connect_to_serverA
  3.8/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 describes key behaviors: the single-connection constraint, transport protocol selection based on input type (stdio for file paths, streamable-http for URLs), and detailed return structure including success/error cases. It also specifies that this is for testing purposes, which adds important context about the tool's intended use case.

  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 well-structured with clear sections (purpose, constraints, returns, raises) and uses bullet points for readability. While comprehensive, some sentences could be more concise (e.g., the returns section is quite detailed). Overall, it's appropriately sized for a connection tool with complex behavior, though not perfectly minimal.

  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?

  Given the tool's complexity (connection establishment with protocol selection and single-connection constraint), no annotations, 100% schema coverage, and the presence of an output schema (implied by the detailed return documentation), the description is complete. It covers purpose, constraints, return values, and error cases thoroughly, providing all necessary context for an agent to use the tool correctly.

  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 the single 'url' parameter with its description. The description adds marginal value by mentioning the transport protocol implications ('stdio for file paths, streamable-http for URLs'), but doesn't provide additional syntax, format, or validation details beyond what the schema provides. The baseline of 3 is appropriate when the schema does most of the parameter documentation work.

  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: 'Connect to an MCP server for testing' and 'Establishes a connection to a target MCP server using the appropriate transport protocol'. It specifies the verb ('connect', 'establishes') and resource ('MCP server'), though it doesn't explicitly differentiate from siblings like 'get_connection_status' or 'disconnect' beyond the testing context.

  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 context ('for testing') and mentions 'Only one connection can be active at a time', which provides some guidance on when to use it. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_connection_status' or 'disconnect', nor does it provide clear prerequisites or exclusions beyond the single-connection constraint.

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

• call_toolA
  3.9/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 describes key behaviors: it returns execution results with timing/metadata, raises specific error types (e.g., 'tool_not_found', 'invalid_arguments'), and handles failure scenarios. However, it doesn't mention rate limits, authentication needs, or side effects like network usage, leaving some gaps for a tool that interacts with external servers.

  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 well-structured and front-loaded with the core purpose, followed by details on returns and errors. It avoids unnecessary fluff, but the 'Returns' and 'Raises' sections are somewhat verbose and could be more streamlined. Most sentences earn their place by clarifying behavior, though minor trimming is possible.

  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 complexity of executing external tools, the description is reasonably complete: it covers purpose, returns, and error handling. With an output schema present, it doesn't need to detail return values extensively. However, it lacks information on prerequisites (e.g., server connection state) beyond error mentions, and behavioral aspects like idempotency or retries are not addressed, leaving minor gaps.

  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 'arguments') thoroughly. The description adds minimal value beyond the schema by reiterating that arguments are 'provided' and passed to the tool, but it doesn't explain parameter semantics like format constraints or examples. This 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 ('Execute a tool on the connected MCP server') and distinguishes it from sibling tools like 'list_tools' (which enumerates available tools) or 'connect_to_server' (which establishes connections). It explicitly identifies the resource as 'tools on the MCP server' and the verb as 'execute/call', making the purpose unambiguous.

  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 prerequisites ('connected MCP server') and failure scenarios like 'not_connected', but it does not explicitly state when to use this tool versus alternatives. For example, it doesn't clarify if this is the primary method for all tool executions or if direct tool calls are preferred when available. The guidelines are contextual but lack explicit alternatives or exclusions.

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

• list_promptsA
  4.2/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 of behavioral disclosure. It effectively describes the tool's read-only nature (retrieves information) and error conditions (connection failures), but lacks details on rate limits, pagination, or performance characteristics. It adds useful context beyond basic functionality but is not comprehensive.

  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 well-structured with clear sections (purpose, returns, raises) and avoids redundancy. However, the 'Returns' section could be more concise, as some details (like 'success: True') might be inferred from context. Overall, it's efficient but has minor verbosity in the output description.

  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?

  Given the tool's simplicity (0 parameters, no annotations, but with an output schema), the description is complete. It explains what the tool does, what it returns, and error conditions, which is sufficient for a listing tool. The output schema will handle return value details, so the description doesn't need to duplicate that information.

  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 focuses on behavior and output rather than inputs, earning a baseline score of 4 for zero-parameter tools that avoid unnecessary parameter discussion.

  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 ('List all prompts') and resource ('available on the connected MCP server'), distinguishing it from siblings like 'get_prompt' (which retrieves a single prompt) and 'list_tools' (which lists tools rather than prompts). The verb+resource combination is precise and unambiguous.

  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 usage context by specifying 'on the connected MCP server' and mentions prerequisites ('if not connected... returns error'), but does not explicitly state when to use this tool versus alternatives like 'get_prompt' or 'list_tools'. The guidance is clear but lacks explicit sibling differentiation.

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

• get_connection_statusA
  4.3/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it's a read-only diagnostic tool (implied by 'Check'), returns detailed connection information, and specifies the exact structure of the return dictionary. It doesn't mention rate limits, authentication needs, or side effects, 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 perfectly structured and front-loaded: the first sentence states the core purpose, followed by specific details about what information is returned. Every sentence adds value with no redundancy or wasted words. The bulleted return format is clear and efficient.

  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?

  Given the tool's diagnostic nature, 0 parameters, and the presence of an output schema (implied by the detailed Returns section), the description is complete. It explains what the tool does, what information it provides, and the structure of the response without needing to cover parameters or complex behaviors.

  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, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, focusing instead on the tool's function and return values.

  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 ('Check') and resource ('current MCP server connection state'). It distinguishes itself from siblings like 'ping' or 'health_check' by focusing specifically on connection status details rather than basic availability or system health.

  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 context (checking connection state) but doesn't explicitly state when to use this tool versus alternatives like 'ping' for basic connectivity or 'health_check' for broader system status. No explicit when-not-to-use guidance or prerequisite information is provided.

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

• list_resourcesA
  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 and does well by disclosing behavioral traits: it describes the return structure (dictionary with success, resources, metadata), error conditions (if not connected or retrieval fails), and the scope of retrieval (comprehensive information about all resources). It does not mention rate limits or performance details, but covers key operational aspects.

  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 well-structured with clear sections (purpose, returns, raises) and is front-loaded with the core functionality. It is appropriately sized, but could be slightly more concise by integrating the 'Returns' and 'Raises' into a single behavioral section without redundancy.

  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?

  Given the tool's complexity (listing resources), no annotations, 0 parameters, and the presence of an output schema, the description is complete. It explains what the tool does, the return format, and error handling, which is sufficient for an agent to use it correctly without needing to rely heavily on other fields.

  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 does not discuss parameters, focusing instead on behavior and output. This meets the baseline of 4 for zero parameters, as it avoids unnecessary 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 specific verb ('List all resources') and resource ('available on the connected MCP server'), distinguishing it from siblings like list_tools or list_prompts. It explicitly mentions what information is retrieved (URIs, names, descriptions, MIME types) and the purpose (to enable accurate resource access).

  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 usage context by stating 'on the connected MCP server,' suggesting it should be used when connected. However, it does not explicitly state when to use this tool versus alternatives like list_tools or read_resource, nor does it provide exclusions or prerequisites beyond the connection requirement.

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

• disconnectA
  4.5/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 describes what the tool does ('clears all connection state and statistics'), safety characteristics ('safe to call even if no connection exists'), and return format. It doesn't mention rate limits or authentication needs, but those may not be relevant for this type of 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?

  The description is well-structured and front-loaded with the core purpose. Every sentence adds value: the first states what it does, the second explains safety characteristics, and the third details the return format. There's no wasted text.

  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?

  Given the tool's simplicity (0 parameters, no annotations, but has output schema), the description is complete. It explains what the tool does, its safety characteristics, and the return format. The output schema exists, so the description doesn't need to explain return values in detail beyond what's already provided.

  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, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, which is correct for this case.

  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 ('Close the current MCP server connection') and resource ('MCP server'), distinguishing it from siblings like 'connect_to_server' and 'get_connection_status'. It precisely defines what the tool does without being tautological.

  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 ('Safely disconnects from the active MCP server') and mentions it's 'safe to call even if no connection exists', which helps differentiate from potential alternatives. However, it doesn't explicitly state when NOT to use it or name specific sibling alternatives.

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

• list_toolsA
  4.5/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full burden and does well by disclosing the return structure (dictionary with success, tools, metadata), error conditions (returns error dict if not connected or retrieval fails), and what information is included (full input schemas). It doesn't mention rate limits, authentication needs, or performance characteristics, but covers the essential behavioral aspects.

  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 perfectly structured: a clear purpose statement, followed by what it retrieves, then the return format with bullet points, and finally error conditions. Every sentence earns its place with zero redundant information, and it's 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.

  Completeness5/5

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

  Given this is a read-only discovery tool with 0 parameters, 100% schema coverage, and an output schema exists, the description provides complete context. It explains what the tool does, what it returns, and error conditions - exactly what's needed for an agent to understand and use this tool effectively.

  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, so the baseline would be 3. However, the description explicitly states 'no parameters required' by implication and clarifies this is a discovery/list operation without input filters, which adds meaningful context beyond the empty schema.

  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 ('List all tools') and resource ('available on the connected MCP server'), distinguishing it from siblings like list_prompts or list_resources. It explicitly mentions retrieving comprehensive information including full input schemas, which sets it apart from other listing tools.

  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 discover available tools on a connected server. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools, though the context implies it's for tool discovery rather than other server operations.

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

• pingA
  4.5/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. It discloses the tool's behavior (responds with 'pong') and purpose (connectivity testing), but doesn't mention potential limitations like network timeouts, authentication requirements, or rate limits. The description is accurate but lacks operational context that would be helpful for an agent.

  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 perfectly structured and concise: purpose statement first, usage guidelines second, return value third. Each sentence earns its place - the first defines what it does, the second explains when to use it, and the third specifies the return value. No wasted words or redundancy.

  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?

  Given this is a zero-parameter tool with an output schema (implied by the return statement), the description provides complete context. It explains what the tool does, when to use it, and what it returns. For such a simple tool, no additional information about parameters, authentication, or complex behaviors is needed.

  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 with 100% schema description coverage, so the baseline is 4. The description correctly indicates this is a 'simple' tool with no inputs needed, which aligns perfectly with the empty input schema. No additional parameter information is needed or provided.

  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 ('responds with') and resource ('pong'), distinguishing it from siblings like 'echo' or 'health_check' which serve different testing purposes. It explicitly identifies this as a connectivity testing tool rather than a general-purpose echo or health monitoring tool.

  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 explicitly states when to use this tool: 'for testing basic connectivity and server responsiveness.' This provides clear context about its intended use case versus alternatives like 'health_check' (which might check deeper system status) or 'echo' (which might echo input rather than test connectivity).

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

• execute_prompt_with_llmA
  4.6/5.0
  Behavior5/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 and does so comprehensively. It details the complete 4-step workflow, explains error scenarios (raises section), describes the return structure, and mentions environmental variable defaults for LLM configuration.

  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 well-structured with clear sections (workflow, patterns, args, returns, raises) and efficiently conveys complex information. While comprehensive, some sections like the detailed llm_config defaults could be slightly more concise, but overall it earns its length.

  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?

  Given the tool's complexity (4 parameters, workflow with multiple steps) and the presence of an output schema, the description is complete. It covers purpose, usage patterns, parameter semantics, return structure, and error conditions, providing everything needed for effective tool invocation.

  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 description adds significant value beyond the 100% schema coverage by explaining the purpose and interaction of parameters. It clarifies that prompt_arguments are for MCP server substitution while fill_variables are for manual template replacement, and details the structure and defaults of llm_config. The only minor gap is not explicitly stating prompt_name is required.

  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 ('execute a prompt with an LLM and return the response') and distinguishes it from siblings by detailing its unique workflow. It explicitly mentions retrieving prompts from an MCP server, which differentiates it from generic LLM tools.

  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 usage by explaining the two prompt patterns (standard MCP prompts and template variables) and when to use each. However, it doesn't explicitly mention when NOT to use this tool or name specific alternatives among the sibling tools.

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