Server Quality Checklist

Tool Scores

• check_excessive_agencyA
  4.2/5.0
  Behavior5/5

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

  No annotations provided, so description carries full burden. It thoroughly covers read-only, stateless, idempotent, rate limits (10/day free, unlimited pro), authentication (none required for basic), error handling (structured errors), and data privacy (no storage). All key behavioral traits disclosed.

  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 clear sections (Behavior, When to use, etc.), but contains redundancy (e.g., behavior info repeated in both 'Behavior' and 'Behavioral Transparency'). Could be more concise; some sentences are wordy.

  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 has 12 parameters (1 required) and an output schema, the description covers behavior thoroughly and provides some parameter guidance. However, parameter descriptions are shallow and do not fully explain purpose or constraints for all fields, leaving some 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 0%, but the description includes an 'Args' section listing each parameter with a short description (e.g., 'The agent name to analyze or process'). These descriptions are present but mostly generic and repetitive, adding limited meaning beyond parameter names.

  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 starts with 'Assess agent for excessive permissions (least privilege)' – a specific verb+resource that clearly states the tool's purpose. It is distinct from sibling tools like assess_agent_security or check_data_leakage, which focus on other security aspects.

  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 context for appropriate invocation. However, the 'When to use' is somewhat generic ('structured analysis') and could be more specific to excessive agency assessment.

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

• assess_agent_securityA
  4.3/5.0
  Behavior5/5

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

  With no annotations, the description fully covers side effects (read-only, idempotent), authentication, rate limits, error handling, and data privacy in a structured 'Behavioral Transparency' section.

  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-organized with sections, but contains redundancy (Behavior and Behavioral Transparency overlap) and overly repetitive parameter descriptions. Could be trimmed.

  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?

  Thorough coverage of behavior, usage, and transparency. Only weakness is weak parameter descriptions, but output schema exists and the overall context is complete.

  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 coverage is 0%, so the description must compensate. However, the 'Args' section provides only minimal, repetitive descriptions like 'The has_input_validation to analyze or process.' that add little meaning beyond the parameter names.

  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 starts with 'Full OWASP Agentic AI Top 10 security assessment', a clear verb+resource. It distinguishes from sibling tools like check_data_leakage by being an overall assessment.

  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?

  Has explicit 'When to use' and 'When NOT to use' sections, providing clear guidance on appropriate contexts and a caveat against real-time use without human review.

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

• check_data_leakageA
  4.3/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 extensive behavioral details: read-only, stateless, idempotent, authentication requirements, rate limits, error handling, and data privacy. This fully informs the agent of the tool's behavior.

  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-organized into sections (Behavior, When to use, Args, Behavioral Transparency) and front-loaded with the purpose. However, there is some redundancy between the Behavior section and the later Behavioral Transparency details, and the Args section is lengthy with low-value content.

  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 (10 parameters, no annotations, presence of output schema), the description covers all necessary aspects: purpose, usage guidelines, behavioral traits, parameters, and error handling. It provides sufficient information for an agent to correctly select and invoke the tool.

  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 Args section provides one-line descriptions for each of the 10 parameters, but these are mostly tautological (e.g., 'The agent name to analyze or process') and do not add meaningful semantics beyond the schema's titles and types. With 0% schema description coverage, the description should compensate but fails to do so effectively.

  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 starts with 'Assess cross-context data exposure risks', a specific verb+resource that clearly indicates the tool's function. It distinguishes from sibling tools like assess_agent_security and check_excessive_agency, which focus on other security aspects.

  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 context for invocation. It advises against real-time production use without human review, but does not directly compare with sibling tools, reducing the score from perfect.

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

• check_prompt_injectionA
  4.3/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 and does an excellent job. It covers side effects (read-only, stateless), authentication, rate limits, error handling, idempotency, and data privacy in a dedicated section.

  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 and front-loaded purpose. It is somewhat long but every sentence adds value; minor redundancy exists (e.g., repeating behavioral details in both inline and a dedicated section).

  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 an output schema present, the description covers behavioral aspects thoroughly. However, it misses describing the 'caller' parameter and has slight inconsistency about api_key/authentication, 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?

  The schema has 0% description coverage, so the description must compensate. It describes 'input_text' and 'api_key' in an Args block but omits the 'caller' parameter entirely. The descriptions given are minimal (e.g., 'The input text to analyze'). Partial coverage prevents a higher score.

  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 it checks text for prompt injection attack patterns. It uses a specific verb-resource combination and distinguishes from sibling tools like check_tool_poisoning or check_data_leakage.

  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 dedicated 'When to use' and 'When NOT to use' sections, providing clear context for when to invoke the tool. It could explicitly mention alternatives among siblings, but the guidance is sufficient.

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

• check_tool_poisoningA
  4.4/5.0
  Behavior5/5

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

  The description discloses read-only, stateless, idempotent behavior, rate limits (10/day free, unlimited pro), authentication options, error handling, and data privacy. All claims are specific and beyond the absent 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?

  Well-structured sections (Behavior, When to use, Args, Behavioral Transparency) but slightly verbose, with some redundancy (Behavior and Behavioral Transparency overlap). Could be tightened.

  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 essential aspects: purpose, behavior, usage guidelines, parameters, error handling, rate limits, authentication, privacy. No gaps given the presence of an output schema.

  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?

  With 0% schema description coverage, the description must compensate, but parameter descriptions are generic ('to analyze or process') and sometimes misleading (e.g., api_key described as 'to analyze or process' rather than for authentication). Adds minimal value beyond property names.

  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 checks for tool poisoning (name/description manipulation), a specific security analysis function. It distinguishes from sibling tools like assess_agent_security and check_prompt_injection by focusing on this niche.

  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 context. Advises use for structured analysis/classification and warns against real-time production use without human review, offering strong guidance.

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