Server Quality Checklist

Tool Scores

• aim-text-guardD
  1.6/5.0
  Behavior1/5

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

  No annotations are provided, and the description does not disclose any behavioral traits beyond analyzing text. It fails to mention whether the tool modifies data, requires authentication, or has 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.

  Conciseness2/5

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

  The description is only 5 words, which is under-specified rather than concise. It provides no useful information and does not front-load key details.

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

  Completeness1/5

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

  With no output schema and no annotations, the description is completely inadequate. It does not explain what the tool returns, error conditions, or how to interpret results, making it unusable for an agent.

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

  Parameters3/5

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

  Schema coverage is 100% with one parameter 'text' described as 'Text to analyze for harmful content'. The description adds no additional meaning beyond the schema, so baseline of 3 applies.

  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?

  Description is 'AIM-Intelligence Text Guard Tool', which is a tautology of the tool name. It does not specify what action the tool performs or what resource it acts on, making it impossible to understand the tool's purpose.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus sibling tools like 'prompt-injection-detector' or 'ai-safety-guard'. The context of analyzing harmful text is implied by the input schema but not explicitly stated.

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

• ai-safety-guardD
  1.9/5.0
  Behavior1/5

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

  The description provides no behavioral details (e.g., whether it blocks actions, returns warnings, or modifies behavior). With no annotations, the agent has no insight into side effects or safety implications.

  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 extremely short (single sentence) but fails to convey essential information. It is under-specified rather than concise; a well-structured description would prioritize key details.

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

  Completeness1/5

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

  Given three parameters with enums and no output schema, the description is critically incomplete. It doesn't clarify the tool's output, side effects, or how it integrates with other guard tools. The agent cannot determine correct usage.

  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 explains parameters (mcp_type, operation_type, sensitivity_level) with enums. The description adds no additional value beyond what's in the schema.

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

  Purpose2/5

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

  The description 'AI Safety Guard - MCP Caution Instructions for AI Agents' is ambiguous. It does not explicitly state the tool's function (e.g., 'checks safety before calling an MCP' or 'provides safety guidelines'). The purpose is implied but not clearly conveyed.

  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 or why to use this tool versus siblings like 'prompt-injection-detector' or 'credential-scanner'. The description lacks context for appropriate invocation, forcing the agent to guess.

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

• aim-security-prompt-toolC
  2.2/5.0
  Behavior1/5

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

  No annotations provided, so description bears full burden. It only says 'Security Prompt Enhancement Tool', without disclosing any behavioral traits such as whether it modifies the prompt, returns a new string, or has side effects. This is insufficient for an agent to understand the tool's actions.

  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 a single short phrase, but it is under-specified rather than concise. It lacks essential information to be helpful. Every word should earn its place; here, the phrase barely adds value over the tool name itself.

  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?

  For a tool with no output schema and no annotations, the description fails to explain what the tool returns or its behavior. With sibling tools like 'prompt-injection-detector', more context is needed to distinguish usage. The description is incomplete.

  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 100%, so schema already explains the two parameters. The description adds no additional meaning beyond the parameter names and defaults. Baseline 3 is appropriate.

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

  Purpose3/5

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

  The description 'Security Prompt Enhancement Tool' is a vague noun phrase. It indicates the tool enhances prompts with security but lacks a clear verb and specific resource. It does not differentiate from sibling tools like prompt-injection-detector, which also deals with prompts.

  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. The description does not mention prerequisites, exclusions, or context where this tool is appropriate. Sibling tools exist, but no comparative information is provided.

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

• prompt-injection-detectorC
  2.9/5.0
  Behavior2/5

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

  No annotations provided, so description carries full burden. It does not disclose return format, whether it's a binary or score, or any side effects. Lacks behavioral details beyond detection itself.

  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?

  A single sentence that efficiently conveys the core purpose. Could include more detail without losing conciseness, but current length is appropriate.

  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?

  With no output schema, the description should hint at return values or detection output. It does not, leaving a gap in understanding tool behavior. Context signals indicate only 2 simple parameters, but output is undocumented.

  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?

  Input schema covers 100% of parameters with descriptions. The description adds no additional meaning beyond the schema, achieving the baseline for high coverage.

  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 detects prompt injection attempts using OWASP LLM01:2025 patterns, providing a specific verb and resource. It implicitly differentiates from sibling tools like 'aim-security-prompt-tool' by focusing on OWASP patterns, but does not explicitly contrast them.

  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 (e.g., aim-text-guard, credential-scanner). Missing context about appropriate scenarios or limitations.

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

• credential-scannerB
  3.4/5.0
  Behavior2/5

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

  No annotations are provided, so the description must disclose behavioral traits. It only states the scanning function, omitting key details such as whether the tool modifies the input, what it returns, or any performance implications. The 'mask_findings' parameter hints at output masking but is not explained.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that efficiently conveys the core functionality. No extraneous information is present.

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

  Completeness2/5

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

  Given the simplicity of the tool, the description lacks crucial details such as output format, behavior when credentials are found vs. not, and how masking works. Without an output schema, these omissions hinder complete understanding.

  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?

  Both parameters are well-described in the input schema (100% coverage). The description adds no further semantic value beyond the schema definitions, meeting the baseline expectation but not exceeding it.

  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 scans text for exposed credentials, listing specific types (API keys, passwords, tokens, SSH keys). This distinct purpose is easily differentiated from sibling tools like 'prompt-injection-detector' or 'url-security-validator'.

  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 use for credential detection but offers no explicit guidance on when to use or not use this tool versus alternatives. No context on potential false positives or limitations is provided.

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

• url-security-validatorA
  3.8/5.0
  Behavior3/5

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

  No annotations exist, so the description carries full burden. It names specific security checks (phishing, malware, HTTPS enforcement) but does not disclose whether the tool is read-only, authentication needs, or any 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 a single, concise sentence that conveys the essential purpose without any redundant or extraneous information.

  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 simple interface, the lack of output schema means the description should hint at the return format (e.g., boolean, object). It fails to do so, leaving the agent uncertain about what the tool returns.

  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. The description does not add meaning beyond what the schema provides, meeting the baseline of 3.

  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 explicitly states the tool validates URL safety for phishing, malware, and HTTPS enforcement, clearly identifying the verb and resource. It distinguishes from sibling safety tools like prompt-injection-detector and credential-scanner.

  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 for URL security validation but does not provide explicit when-to-use or when-not-to-use guidance. The context is clear, but no exclusions or alternatives are mentioned.

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