Server Quality Checklist

Tool Scores

• mcpdev_inspector_call_toolA
  3.9/5.0
  Behavior4/5

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

  The description adds context beyond annotations: it mentions the tool's response content and includes an example, which helps clarify behavior. Annotations indicate destructiveHint=true and openWorldHint=true, but the description doesn't contradict these; it supports them by describing execution with arguments. However, it doesn't detail potential side effects or error handling, leaving some gaps.

  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, usage, args, returns, examples) and is front-loaded with the main purpose. It's concise overall, but the 'Args' section slightly duplicates schema information, though it's useful for quick reference. Every sentence adds value, such as the example clarifying practical use.

  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 (5 parameters, destructive operation, no output schema), the description is fairly complete: it explains the purpose, parameters, returns, and includes an example. However, it lacks details on error cases, response formats, or how to handle different transport types, which could be important for a tool with openWorldHint=true and destructiveHint=true.

  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 parameters. The description lists parameters in the 'Args' section but doesn't add significant meaning beyond the schema, such as explaining interactions between parameters (e.g., how transport relates to target). It provides an example that illustrates usage, but this is more about guidelines than parameter semantics.

  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: 'Execute a tool on a target MCP server' and 'invoke a specific tool on the target server with provided arguments.' It uses specific verbs ('execute', 'invoke') and identifies the resource ('target MCP server'), distinguishing it from sibling tools that list or read rather than execute.

  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 stating it's for executing tools on MCP servers, but it doesn't explicitly guide when to use this versus alternatives like the sibling tools (e.g., list_tools or read_resource). There's no mention of prerequisites, such as needing to know the tool name from list_tools, or exclusions for specific scenarios.

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

• mcpdev_inspector_list_promptsA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true, covering safety and idempotency. The description adds useful context about discovering prompt templates and the return format ('JSON object with prompts array'), but doesn't mention rate limits, authentication needs, or error behavior beyond the timeout parameter.

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

  Conciseness5/5

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

  The description is efficiently structured with a clear purpose statement, usage context, parameter listing, and return format - all in four concise sentences. Every sentence earns its place by providing distinct information without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

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

  For a read-only list operation with comprehensive annotations and full schema coverage, the description provides adequate context. It explains the purpose, usage, parameters, and return format. The main gap is the lack of an output schema, but the description compensates by specifying the return structure. It could benefit from more behavioral details like error handling.

  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 100% schema description coverage, the input schema already fully documents all three parameters. The description's Args section repeats the parameter names and basic types but doesn't add meaningful semantic context beyond what's in the schema descriptions. The baseline of 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.

  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 available prompts') and resource ('from a target MCP server'), distinguishing it from sibling tools like mcpdev_inspector_list_resources and mcpdev_inspector_list_tools. The second sentence further clarifies the purpose by explaining it's for discovering prompt templates.

  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 discover what prompt templates a target MCP server provides'), but doesn't explicitly state when not to use it or name specific alternatives among the sibling tools. It implies usage for prompt discovery 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.

• mcpdev_inspector_read_resourceA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds valuable context beyond annotations by specifying that it returns 'text or base64-encoded blob' content, which helps the agent understand output format. However, it doesn't mention potential errors (e.g., if the URI doesn't exist) 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.

  Conciseness4/5

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

  The description is well-structured with a clear purpose statement, usage note, and sections for Args and Returns. It's appropriately sized, but the Args section repeats schema details unnecessarily, slightly reducing efficiency. Every sentence adds value, such as clarifying the return format.

  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 (4 parameters, no output schema), the description is mostly complete. It covers purpose, usage, parameters (via schema), and return format. However, it lacks details on error handling or edge cases (e.g., invalid URIs), which would be helpful for an agent. The annotations provide good safety context, compensating somewhat.

  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 parameters. The description repeats some parameter info (e.g., 'target (string): Target MCP server - command or URL') but doesn't add significant meaning beyond what's in the schema. The baseline score of 3 is appropriate as the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  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 ('Read a specific resource') and resource ('from a target MCP server'), distinguishing it from sibling tools like list_resources (which lists rather than reads) and call_tool (which invokes tools rather than reading resources). The verb 'fetch the content' further clarifies the operation.

  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 fetch the content of a resource by its URI'), but it does not explicitly state when not to use it or name alternatives. For example, it doesn't contrast with list_resources (which might be used first to discover URIs) or get_prompt (which handles prompts rather than general resources).

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

• mcpdev_inspector_get_promptA
  4.2/5.0
  Behavior4/5

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

  The description adds valuable behavioral context beyond annotations: it explains that the tool renders prompts with arguments, which clarifies the 'prompt_args' parameter's purpose. Annotations already cover safety (readOnlyHint=true, destructiveHint=false) and idempotency, so the bar is lower. The description doesn't contradict annotations and adds useful operational context about rendering behavior.

  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: a clear purpose statement in the first sentence, followed by a usage guideline in the second sentence. The Args/Returns sections are formatted but not part of the description text itself. Every sentence earns its place with zero waste.

  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 (5 parameters, no output schema, rich annotations), the description is mostly complete. It explains the core purpose and rendering behavior well. However, it doesn't mention what happens if the prompt doesn't exist or if arguments are invalid, which could be helpful context despite the annotations covering safety aspects.

  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 fully documents all 5 parameters. The description adds minimal value beyond the schema by mentioning 'provided arguments' for 'prompt_args', but doesn't provide additional syntax, format, or semantic details. This meets the baseline of 3 when schema coverage is complete.

  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 ('Get', 'retrieve', 'render') and resource ('a specific prompt from a target MCP server'). It distinguishes from sibling tools like 'list_prompts' (which lists prompts) by specifying retrieval of a single prompt with template rendering.

  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 retrieve and render a prompt template with provided arguments'), but doesn't explicitly state when not to use it or name alternatives. It implies usage for rendering prompts rather than just listing them, but lacks explicit exclusions or sibling comparisons.

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

• mcpdev_inspector_list_resourcesA
  4.2/5.0
  Behavior4/5

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

  The description adds valuable context beyond annotations: it specifies that this tool discovers resources from a target server, which clarifies the 'openWorldHint' annotation. While annotations cover safety (readOnly, non-destructive, idempotent), the description usefully explains the tool's exploratory purpose and return format, enhancing behavioral understanding without contradictions.

  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 appropriately sized, with a clear purpose statement followed by Args and Returns sections. It's front-loaded with the core functionality. However, the Args section could be more concise by relying on the schema, making it slightly verbose.

  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 (list operation with server targeting), rich annotations (readOnly, openWorld, idempotent), and no output schema, the description is complete. It explains the purpose, parameters, and return format adequately, providing all necessary context for an agent to use it correctly without needing output schema details.

  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 100% schema description coverage, the schema already fully documents all parameters. The description's 'Args' section repeats schema information without adding significant meaning beyond it. This meets the baseline of 3, as the schema does the heavy lifting for parameter documentation.

  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 available resources') and target ('from a target MCP server'), distinguishing it from sibling tools like list_tools or list_prompts. It explicitly mentions discovering what resources a server exposes, which is distinct from reading resources or calling 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 when to use this tool ('to discover what resources a target MCP server exposes'), but it doesn't explicitly state when not to use it or name alternatives. It implies usage for resource discovery rather than tool or prompt listing, but lacks explicit exclusions or comparisons to siblings.

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

• mcpdev_inspector_list_toolsA
  4.5/5.0
  Behavior4/5

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

  The description adds valuable context beyond annotations by specifying what information is returned ('tool names, descriptions, and input schemas') and providing concrete examples of usage patterns. While annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, the description enhances understanding with practical implementation details without contradicting the 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 efficiently structured with a clear purpose statement, usage guidance, parameter overview, return specification, and practical examples - all in well-organized sections. Every sentence serves a distinct purpose with no redundancy or wasted words.

  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 moderate complexity, comprehensive annotations (readOnlyHint, openWorldHint, idempotentHint), and complete schema documentation, the description provides all necessary context. It explains the tool's discovery purpose, distinguishes it from alternatives, and provides implementation examples, making it fully adequate despite the absence of an output schema.

  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 100% schema description coverage, the input schema already thoroughly documents all parameters. The description adds minimal value beyond the schema, providing only basic examples without additional semantic context. This meets the baseline expectation when schema coverage is complete.

  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 ('List') and resource ('all available tools from a target MCP server'). It distinguishes from siblings by focusing specifically on tools rather than prompts or resources, and explicitly mentions what information is returned (tool names, descriptions, and input schemas).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit guidance on when to use this tool ('Use this to discover what tools a target MCP server provides') and distinguishes it from sibling tools that handle different operations (calling tools, getting/listing prompts, listing/reading resources). The examples further clarify appropriate usage contexts for different server types.

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