Server Quality Checklist

Tool Scores

• ap2_aml_mandate_builderB
  3.3/5.0
  Behavior4/5

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

  Annotations already indicate readOnly=true, destructive=false, idempotent=true, openWorld=false. The description adds valuable context: client-side execution, zero PII, zero network, and that inputs are applied via AIN Bridge prefill. No contradictions.

  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 verbose and contains redundancy (e.g., 'Browser-based, client-side only' repeated, 'Zero PII' repeated). It also includes a typo ('payment sy'). Could be more concise and better structured.

  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?

  The description explains the tool's purpose and mechanism (client-side, zero PII) but lacks details on the output format (Policy Mandate JSON structure) and what 'Cat-12' refers to. Without an output schema, more clarity on return value would improve 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 schema has 100% coverage for the single parameter 'inputs', and the description adds meaning by explaining it is a map of tool input element IDs to values, applied via AIN Bridge prefill. This goes beyond the schema's basic description.

  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 translates AML/BSA controls, TM rules, and customer risk policy into a structured Policy Mandate JSON for agentic payment systems. It identifies the tool as an anchor tool for Cat-12, but does not differentiate from sibling tools like 'build_google_ap2_mandate'.

  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 explicit guidance on when to use this tool versus alternatives. The description mentions it is an anchor tool for Cat-12 and provides a link for interactive use, but does not specify use cases or exclusion criteria relative to sibling tools.

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

• list_ainumbers_toolsB
  3.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds valuable behavioral context: it returns deep-links and explains prefill-enabled tools accept a specific query parameter format for one-click invocation. This goes beyond 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 two sentences long, front-loaded with the main purpose. However, the second sentence focuses on a technical detail about prefill links, which may be less relevant for initial tool selection, slightly reducing effectiveness.

  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 three parameters and no output schema, the description should provide more context. It does not describe parameter usage, result structure beyond 'deep-links', pagination, or limits. The tool is under-described given its complexity.

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

  Parameters1/5

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

  Schema parameter descriptions have 0% coverage. The description does not explain any of the three parameters (query, category, limit). Without this, the agent cannot infer what values to provide or how they affect results. The description fails to compensate for the schema gap.

  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: 'Search the AINumbers catalog (420 client-side fintech tools).' The verb 'search' and resource 'catalog' are specific, and the tool is distinct from all sibling tools, which focus on different domains like sandbox, AML, auditing, etc.

  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 mentions when to use (to search catalog) but does not explicitly state when not to use or suggest alternatives. No exclusions or context comparisons are provided, leaving the agent to infer usage from purpose alone.

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

• inspect_visa_tap_signatureA
  3.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds valuable behavioral context: renders interactive widget, inputs via AIN Bridge, client-side execution with zero PII and zero network. No contradiction.

  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?

  Two sentences: first states primary purpose, second explains runtime behavior. Front-loaded and no unnecessary words.

  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?

  The description covers purpose and runtime environment, but lacks information about return values (no output schema). For an interactive tool, the agent needs to know what output to expect, which is not addressed.

  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 description for 'inputs'. The description echoes that inputs are applied via AIN Bridge. It adds no new detail beyond schema, but reinforces the mechanism.

  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 it inspects a Visa Trusted Agent Protocol HTTP Message Signature and scores TAP readiness. The verb 'inspect' and resource 'signature' are specific. However, it does not explicitly differentiate from sibling tools beyond its unique focus.

  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., agentic_mandate_sandbox, ap2_aml_mandate_builder). The description only explains what it does, not when to use it.

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

• baas_provider_comparatorA
  3.7/5.0
  Behavior4/5

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

  The description discloses key behavioral traits: browser-based, client-side execution, zero PII, and inputs via AIN Bridge. Annotations already indicate readOnly, idempotent, and non-destructive; the description adds environmental and data handling details without contradiction.

  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 relatively concise with two sentences that front-load the purpose and key constraints. There is minor redundancy (zero PII mentioned twice), but overall no wasted words.

  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 complexity (10 dimensions, weighting matrix), the description adequately explains the purpose, inputs, outputs (matrix and memo), and constraints (client-side, no PII). No output schema exists, but the output format is described sufficiently.

  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% as the schema's description for 'inputs' is identical to the main description. The description does not add new information about parameters beyond what the schema already provides, but it gives context about the capability dimensions and weighting matrix.

  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 verb (score and compare), the resource (BaaS providers), and specifies 10 capability dimensions. It distinguishes itself from sibling tools such as compare_agentic_payment_protocols by focusing specifically on BaaS providers.

  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 context about the tool being browser-based and client-side with zero PII, but it does not explicitly state when to use this tool versus alternatives like compare_agentic_payment_protocols or other evaluation tools. No when-to-use or when-not-to-use guidance is given.

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

• customer_risk_ratingA
  3.8/5.0
  Behavior4/5

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

  Annotations provide readOnlyHint, idempotentHint, etc. The description adds valuable behavioral context: browser-based, client-side only, zero PII, zero network, which goes beyond the annotations and clarifies execution environment.

  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 packed with information but has some redundancy (e.g., 'zero PII' mentioned twice). It front-loads the purpose and is structured, but could be more concise.

  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?

  There is no output schema and the description does not specify return values or effects. For a client-side widget tool, the agent needs to know what the tool returns or renders, which is missing.

  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 single parameter 'inputs' is described in schema as a map. The description explains it is used for 'prefill' via AIN Bridge, adding functional meaning beyond the schema's property definition.

  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 verb 'Score' and the resource 'KYC risk across six FATF dimensions'. It distinguishes from sibling tools by specifying its domain (risk scoring vs. mandate building, scanning, etc.).

  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 the tool is a client-side widget for risk scoring but does not explicitly state when to use it vs. alternatives or provide exclusions. Usage is inferred but not directly guided.

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

• score_mcp_readinessA
  3.8/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds value by disclosing that the tool 'runs client-side (zero PII, zero network)' and 'renders the interactive AINumbers tool as a widget', providing behavioral context beyond 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 two sentences, front-loaded with the core action, and every part adds value. No wasted words. It is appropriately sized for the complexity.

  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?

  The description explains what the tool computes and that it outputs a widget, which is sufficient given no output schema. It could briefly mention what fields the score covers, but overall it is complete for an interactive scoring tool.

  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 coverage is 100% and already describes the 'inputs' parameter as 'Map of tool input element IDs to values'. The description does not add further meaning or usage details for the parameter, so baseline 3 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?

  The description clearly states the tool's purpose: 'Compute a composite MCP server ship-readiness score across tool definitions, server.json, OAuth, transport, tool poisoning, and spec compliance.' It uses a specific verb ('compute') and resource ('ship-readiness score'), and differentiates from sibling tools like validation and scanning 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 explicit guidance on when to use this tool versus alternatives like 'validate_mcp_server_json' or 'scan_tool_poisoning'. It mentions client-side execution and zero PII, but fails to indicate preferred use cases or prerequisites.

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

• agentic_mandate_sandboxA
  4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, signaling safe simulation. The description adds valuable detail: 'Renders the interactive AINumbers tool as a widget; inputs are applied via the AIN Bridge and the tool runs client-side (zero PII, zero network).' This clarifies execution environment and data handling, going beyond annotations without contradiction.

  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 two sentences: the first defines the core purpose and capabilities, the second explains execution mode and safety. Every sentence earns its place, with no redundant or vague phrasing. It is front-loaded and 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 complexity (multiple policy aspects simulated) and the absence of an output schema, the description covers the main concerns: what it does, how it runs (client-side, zero network), and what it produces (Policy Mandate). It does not detail the widget behavior or result interpretation, but for a sandbox tool with annotations, it is largely sufficient.

  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%, with the single parameter 'inputs' already documented as a map of IDs to values. The description repeats this and adds 'Applied via AIN Bridge prefill,' which provides minor extra context but does not fundamentally improve understanding beyond the schema. Baseline 3 is appropriate.

  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 uses a specific verb ('simulate') and resource ('agent payment policies for tokenized A2A corridors'), listing concrete capabilities (spend caps, MCC allowlists, etc.) and outcomes (export Policy Mandate). It clearly distinguishes from sibling tools like 'build_google_ap2_mandate' or 'compare_agentic_payment_protocols' by focusing on simulation rather than construction or comparison.

  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 ('browser-based, client-side only, zero PII') but does not explicitly state when to use this tool versus alternatives or when not to use it. It lacks mention of prerequisites or exclusions, leaving the agent to infer fit from sibling names.

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

• validate_ap2_mcp_policyA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, etc. Description adds that the tool runs client-side, zero PII, zero network, and renders an interactive widget. No contradiction with 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?

  Three sentences, front-loaded with the primary purpose, then secondary functions, then usage context. No redundant information.

  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?

  While the description covers purpose and behavior, it does not explain the tool's output (e.g., what it returns or displays). Given no output schema, this is a gap for the 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 a clear description for the parameter. The description adds context about AIN Bridge prefill but does not significantly extend parameter meaning beyond the 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 it validates AP2 Policy Mandate JSON payloads against a named schema, and additionally auto-generates MCP tool definitions and simulates agent ingestion. This distinguishes it from siblings like 'agentic_mandate_sandbox' and 'build_google_ap2_mandate'.

  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?

  Explicitly says 'Use when authoring or testing AP2 agentic payment policies,' providing clear context. Does not specify when not to use or mention alternatives, but the sibling list offers potential alternatives.

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

• audit_mcp_oauthA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds valuable behavioral context: the tool 'renders the interactive AINumbers tool as a widget, runs client-side (zero PII, zero network).' This explains execution model and security properties beyond 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 two sentences. The first sentence conveys the core purpose and technical specifics. The second adds behavioral and privacy details. No unnecessary words; information is front-loaded.

  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?

  With no output schema, the description could be more explicit about what the audit produces (e.g., a report, risk score). However, it covers purpose, usage, behavioral traits, and privacy. The input schema is simple, and context signals indicate low complexity, so the description is mostly complete.

  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% for the single 'inputs' parameter, which is described as a map of IDs to values applied via AIN Bridge prefill. The description adds context about the interactive widget but does not further clarify the parameter's meaning beyond the 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 tool audits MCP OAuth 2.1 authorization, specifying validations for RFC 9728, RFC 8707, and token-passthrough/confused-deputy risk. It distinguishes itself from sibling tools (e.g., scan_tool_poisoning, validate_mcp_server_json) by focusing on OAuth audit.

  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 explicitly says 'Use when a developer is securing an MCP server's authorization,' providing clear context. However, it does not mention when not to use the tool or suggest 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.

• build_google_ap2_mandateA
  4.2/5.0
  Behavior4/5

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

  The descriptions adds context beyond annotations: it states the tool runs client-side, zero PII, zero network, and inputs are applied via AIN Bridge. The annotations already declare readOnlyHint, destructiveHint, and idempotentHint, so the description provides valuable operational details without contradiction.

  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 three sentences, front-loaded with the main action, and every sentence adds value. No redundant or irrelevant information.

  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 single parameter and presence of annotations, the description covers the tool's operation well. It explains the scope, the rendering behavior, and the parameter semantics. Minor missing context on 'Open/Closed' VDC types, but overall complete.

  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?

  With 100% schema coverage, the baseline is 3. The description adds meaning by explaining that the 'inputs' parameter is a map of tool input element IDs to values, applied via AIN Bridge prefill. This clarifies the usage beyond the schema's brief description.

  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 builds or validates a Google AP2 Checkout/Payment Mandate VDC and distinguishes it from the AINumbers Policy Mandate. It specifies the target (external AP2 spec) and mentions rendering the interactive AINumbers tool, providing a specific verb+resource combination.

  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 mentions targeting the external AP2 spec and not the AINumbers Policy Mandate, giving some guidance on when to use. However, it does not explicitly exclude alternatives or compare with sibling tools like 'validate_ap2_mcp_policy' or 'ap2_aml_mandate_builder', 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.

• scan_tool_poisoningA
  4.2/5.0
  Behavior5/5

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

  The description adds significant behavioral context beyond annotations: client-side execution, zero PII, zero network, widget rendering. Annotations already declare read-only, idempotent, and non-destructive.

  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?

  Two sentences: first sentence states purpose and output, second adds behavioral context. No extraneous words, front-loaded.

  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, no output schema, and ample annotations, the description adequately covers purpose, behavioral context, and privacy. The output is described as risk score and flagged patterns, which suffices.

  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%, and the tool description does not add new semantic meaning beyond what the schema provides for the 'inputs' parameter. Baseline 3 is appropriate.

  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 for tool-poisoning and prompt-injection smells, returns a risk score and flagged patterns, and distinguishes itself from siblings like 'lint_mcp_tool_definition' by focusing on security-specific analysis.

  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 security scanning but does not explicitly provide when-to-use or when-not-to-use guidance relative to sibling tools like 'lint_mcp_tool_definition' or 'score_mcp_readiness'.

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

• compare_agentic_payment_protocolsA
  4.3/5.0
  Behavior4/5

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

  Annotations indicate readOnlyHint=true and idempotentHint=true. The description adds significant context: 'Renders the interactive AINumbers tool as a widget; inputs are applied via the AIN Bridge and the tool runs client-side (zero PII, zero network).' This discloses execution model and data privacy beyond 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 two sentences. The first sentence states purpose and dimensions; the second adds usage context and behavioral details. It is front-loaded and every sentence adds value.

  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 (comparing multiple protocols across dimensions) and lack of output schema, the description covers purpose, usage, input mechanism, and behavioral traits (zero PII, client-side, widget render). It is complete for an agent to decide when and how to invoke.

  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% coverage for the single parameter 'inputs'. The description adds that inputs are 'applied via the AIN Bridge prefill', which provides extra context but is not essential. Baseline 3 is appropriate.

  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 compares specific agentic payment protocols across well-defined dimensions (credential, signing, scope, etc.) and can optionally recommend a fit. The verb 'compare' and resource 'protocols' are clear, and it distinguishes from siblings like decode_x402_payment or validate_ap2_mcp_policy.

  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 says 'Use when a developer or strategist needs to orient across the fragmenting agentic-payments standards,' providing clear context. It does not explicitly state when not to use, but the sibling list implies more specific tools exist for deeper dives. This is a minor gap.

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

• decode_x402_paymentA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by disclosing that inputs are applied via AIN Bridge and the tool runs client-side with zero PII and zero network activity. This confirms no side effects and privacy implications beyond what annotations cover.

  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?

  Two efficient sentences. The first packs the core purpose, while the second clarifies usage context and runtime behavior. No redundant words; every sentence serves a purpose. This is ideal conciseness for a tool with a single parameter and clear annotations.

  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 is a decoder/linter with no output schema, the description does not explain what the tool returns (e.g., decoded data structure, lint results). While annotations and schema coverage are strong, omitting output format leaves a gap. The description mentions 'describe the flow' but doesn't specify the output shape, which could confuse an agent.

  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 single parameter 'inputs' is fully documented in the schema (100% coverage). The description adds meaning by explaining these are applied via AIN Bridge prefill and referencing the manifest input_schema. This provides operational context not present in the schema alone.

  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 verb 'decode' and 'lint' with specific resources: 'x402 payment header' and 'exact-scheme PaymentPayload'. It also specifies the audience (developers integrating x402) and the action (describe HTTP-402 flow). This distinguishes it from sibling tools, which are unrelated (e.g., audit_mcp_oauth, baas_provider_comparator).

  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?

  Explicitly states when to use: 'when a developer is integrating x402 and needs to inspect a header, check a payload shape, or understand the flow.' No explicit when-not or alternatives are provided, but the sibling tools are clearly different, implying this is the right tool for x402 debugging. Guidance is clear but lacks exclusions.

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

• validate_a2a_agent_cardA
  4.4/5.0
  Behavior5/5

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

  Beyond annotations (readOnly, idempotent), the description reveals that the tool runs client-side with zero PII and zero network, and renders an interactive widget. This adds significant behavioral context not captured by 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?

  Two sentences, front-loaded with purpose, no extraneous information. Every sentence adds value.

  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?

  The description covers purpose, client-side execution, privacy, and widget rendering. However, it does not specify the output format or error handling, which is a minor gap given no output schema.

  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?

  Schema coverage is 100% and the description reinforces the inputs parameter by explaining it is applied via AIN Bridge prefill and that the tool runs client-side. This adds value beyond the schema alone.

  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 validates A2A agent-card.json against v1.0 shape, checks signatures, and confirms extension declarations. It distinguishes from sibling validation tools by specifying the exact resource and scope.

  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 for validating A2A agent cards but does not explicitly state when to use this tool versus alternatives like validate_mcp_server_json or validate_ap2_mcp_policy. No exclusion criteria or context for selection is provided.

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

• validate_mcp_server_jsonA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description adds valuable behavioral context: it runs client-side, zero PII, zero network, and inputs are applied via the AIN Bridge. This goes beyond annotations without contradiction.

  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 two sentences with a clear front-load: first sentence states core functionality, second sentence gives usage context and technical details. No wasted words; every sentence serves a purpose.

  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?

  The description explains inputs, outputs (findings, score, skeleton), and interaction model (widget, AIN Bridge, client-side). Without an output schema, it covers the return values adequately. Minor gap: no detail on findings format, but overall 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 single parameter 'inputs' has 100% schema description coverage, explaining it is a map of tool input element IDs to values applied via AIN Bridge prefill. The tool description reinforces the AIN Bridge detail, adding value beyond the 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 tool validates an MCP server.json against a specific schema (2025-12-11) and registry rules, and returns findings, a score, and an optional skeleton. It distinguishes itself from sibling tools like 'lint_mcp_tool_definition' and 'score_mcp_readiness' by targeting server.json validation for registry publishing.

  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 explicitly says 'Use when a developer wants to check a server.json before publishing to the MCP Registry', providing clear context. However, it does not mention alternatives or when not to use this tool, which would improve guidance.

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

• lint_mcp_tool_definitionA
  4.7/5.0
  Behavior5/5

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

  Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=false. The description adds valuable context: 'Renders the interactive AINumbers tool as a widget; inputs are applied via the AIN Bridge and the tool runs client-side (zero PII, zero network),' explaining runtime behavior and data safety. No contradictions.

  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?

  Two sentences: first covers purpose and outputs, second gives usage and behavioral details. No wasted words, front-loaded with core 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 100% schema coverage, no output schema (but description mentions returns), and rich annotations, the description fully covers the tool's behavior, including return value, usage context, and client-side execution.

  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?

  Schema coverage is 100%, with the only parameter 'inputs' having a description. The description goes beyond by explaining that inputs are applied via AIN Bridge prefill and that the tool runs client-side, adding semantic context.

  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 states 'Validate an MCP tool definition against JSON Schema 2020-12 and current naming, output-schema, and annotation rules; returns findings, a conformance score, and a recommended annotation set.' This is a specific verb with clear resource and outputs, and it distinguishes from siblings like 'validate_mcp_server_json' by focusing on tool definitions.

  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 explicitly says 'Use when a developer wants to check an MCP tool definition before publishing.' This provides clear context, though it doesn't explicitly state when not to use or list alternatives. However, the purpose is distinct enough among siblings.

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