Server Quality Checklist

Tool Scores

• pricingB
  3.2/5.0
  Behavior5/5

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

  With no annotations provided, the description carries full burden and delivers an exceptionally detailed 'Behavioral Transparency' section covering side effects (read-only, stateless), authentication needs, rate limits, error handling, idempotency, and data privacy. This far exceeds minimal requirements.

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

  Conciseness3/5

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

  The description is extensively detailed but contains redundancy (e.g., read-only and stateless repeated across sections). It could be more concise while retaining key points. Front-loading with 'Pricing + subscribe links' is misleading given the actual content.

  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 a wealth of behavioral detail, the description fails to coherently specify what the tool's output actually is (pricing info vs. security analysis). For a tool with no parameters and no output schema, a clear statement of return values is essential, and this is missing. The purpose confusion severely undermines completeness.

  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 zero parameters, so schema coverage is 100% and the baseline is 4 per rubric. The description does not need to elaborate on parameters, and it does not contradict the schema.

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

  Purpose1/5

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

  The description initially claims to provide 'Pricing + subscribe links for this MCP', but the subsequent behavioral description and usage guidelines describe a security analysis tool (threat detection, vulnerability analysis). This contradiction makes the purpose unclear and misleading, failing to state what the tool actually does.

  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 includes explicit 'When to use' and 'When NOT to use' sections, advising usage for security assessment and cautioning against sole reliance for production decisions. However, it does not distinguish this tool from siblings such as 'audit_tool_descriptions' or 'scan_mcp_url', missing an opportunity to guide selection.

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

• scan_mcp_urlA
  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 delivers a comprehensive 'Behavioral Transparency' section covering side effects, authentication, rate limits, error handling, idempotency, and data privacy. However, there is an inconsistency: the first paragraph states 'Free tier: 5 scans/day per key,' while the Behavioral section says 'Free tier: 10/day rate limit,' which may confuse the AI agent.

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

  Conciseness3/5

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

  The description is well-structured with headings, but contains redundancy (the 'Behavior' section repeats much of the 'Behavioral Transparency' section) and a contradiction in rate limit numbers. It could be more concise without losing essential 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?

  Despite the lack of output schema, the description explains the return format (structured report with findings, severity, score, verdict, hints). It covers the tool's purpose, usage, behavioral details, error handling, and privacy, making it complete for an AI agent to use effectively.

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

  Parameters2/5

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

  The input schema has 0% description coverage, so the description must compensate. The 'Args' section provides minimal explanations ('The url to analyze or process,' 'The api key to analyze or process') that add little beyond the schema's title and type. No format, constraints, or examples are given, leaving the agent with insufficient semantic guidance.

  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 action: fetch a remote MCP server's tool listing and scan tools against injection-pattern rules. It specifies the resource (remote MCP server's /tools/list) and the verb (scan), distinguishing it from sibling tools like audit_tool_descriptions or list_rules.

  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 includes explicit 'When to use' and 'When NOT to use' sections, providing clear guidance on appropriate contexts and cautions. It advises against sole reliance for production decisions, but lacks direct mention of alternative sibling tools for comparison.

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

• audit_tool_descriptionsA
  4.3/5.0
  Behavior4/5

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

  Despite no annotations, the description states it is read-only, stateless, idempotent, and mentions rate limits (10/day free, unlimited pro) and that no authentication is required for basic usage. This covers key behavioral traits, though it could specify error handling or what happens on rate limit exceed.

  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?

  Well-structured with clear sections (main description, behavior, when to use/not, args). Most sentences add value, though the 'Args' section essentially repeats parameter names and types without additional insight, slightly bloating 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 no annotations and no output schema, description provides context about when to use (behind auth, not deployed), behavioral traits, and parameter formats. Lacks details on exact security checks performed or output structure, but covers sufficient ground for selection.

  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 coverage is 0%, so description must compensate. It explains tools_json accepts multiple formats (raw list, object with tools, etc.) and briefly mentions api_key's purpose. However, the api_key description is vague ('to analyze or process') and doesn't clarify usage, leaving ambiguity.

  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?

  Description clearly states the tool audits a JSON string containing a tool list for security assessment. It distinguishes from sibling scan_mcp_url by noting it uses the same rule catalogue but is useful when the server is behind auth or not yet deployed. The verb 'audit' and specific resource 'tool list' make 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 Guidelines5/5

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

  Explicit 'When to use' and 'When NOT to use' sections provide clear guidance. It advises use for security assessment, threat detection, and automated scanning, while cautioning against sole reliance for production decisions and recommending manual review. Also suggests alternative scan_mcp_url for URL-based scanning.

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

• signed_safety_reportA
  4.4/5.0
  Behavior5/5

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

  With no annotations provided, the description carries full responsibility and delivers extensively: it declares the tool read-only and stateless, explains authentication (none for basic, Pro/Enterprise requires MEOK API key), rate limits (10/day free, unlimited Pro), error handling, idempotency, and data privacy. This far exceeds typical descriptions.

  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, tier, behavior, when to use/not, args, behavioral transparency). It is longer than necessary, but every sentence adds unique value. The front-loading of purpose is effective.

  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 absence of annotations and output schema, the description covers all essential gaps: behavior, side effects, auth, rate limits, errors, idempotency, privacy. It even hints at the return format (cert and verify URL). The tool is complex with 5 parameters, and the description provides sufficient context for an agent to use it appropriately.

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

  Parameters2/5

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

  Schema description coverage is 0%, yet parameter descriptions in the text only repeat the name and add generic phrasing like 'The subject to analyze or process.' No additional semantics or constraints are provided for any of the 5 parameters. The api_key parameter’s relation to tier is mentioned elsewhere but not in the parameter list.

  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 opens with a clear action verb and object: 'Issue a cryptographically signed safety report for the scanned MCP server.' It further specifies the return (cert with public verify URL) and distinguishes from sibling tools like audit_tool_descriptions and scan_mcp_url by focusing on cryptographic signing.

  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 includes explicit 'When to use' and 'When NOT to use' sections, listing appropriate contexts (security assessment, threat detection) and caveats (not solely for production decisions, combine with manual review). It also notes the tier restriction (Pro/Enterprise only).

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

• list_rulesA
  4.5/5.0
  Behavior5/5

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

  Thoroughly describes read-only, stateless, idempotent behavior, authentication, rate limits, error handling, and data privacy. With no annotations, the description fully informs the agent.

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

  Conciseness3/5

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

  Well-structured with sections, but somewhat verbose. Some behavioral points are repeated across sections, reducing conciseness.

  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?

  Covers all relevant aspects: purpose, usage, behavior, error handling, rate limits, idempotency, and data privacy. Very complete for a parameterless list tool.

  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?

  Input schema has 0 parameters, so schema coverage is 100%. Description adds no parameter details but doesn't need to; baseline score of 4 applies.

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

  Purpose5/5

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

  Clearly states 'List every detection rule in the canonical catalogue' with a specific verb and resource. It distinguishes itself from siblings like 'pricing' or 'signed_safety_report'.

  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?

  Includes explicit 'When to use' and 'When NOT to use' sections, providing actionable guidance. However, it does not mention alternatives among sibling tools.

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