Server Quality Checklist

Tool Scores

• preflight_transactionA
  4.4/5.0
  Behavior5/5

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

  With no annotations, the description carries the full burden, and it handles this well. It discloses that analysis is static-only, lists omitted capabilities (bytecode verification, proxy resolution, runtime simulation, MEV analysis, counterparty judgment), and explicitly states that 'safe_to_present' does not mean execution is safe. It also clarifies that the descriptor and ABI are caller-supplied, which is a key dependency.

  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 well-structured into PURPOSE, GUIDELINES, and LIMITATIONS sections. Every sentence provides substantive information, and the purpose statement is front-loaded. No redundant or fluff content exists; it is concise yet comprehensive for a complex tool.

  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 (nested objects, no annotations, no output schema), the description covers key aspects: what it does, how to use it, and its limitations. It also names the return categories (present/review/block plus audit, comprehension, danger, assurance, limitations). However, it does not describe the exact output schema or error behavior, leaving minor gaps. Overall, it is nearly complete for a preflight analysis 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?

  Schema coverage is 0%, so the description must compensate. It mentions binding 'chain_id, sender, destination, calldata selector, decoded arguments, ETH value, and an inline ERC-7730 descriptor,' giving high-level meaning to transaction fields and the descriptor. However, it does not detail the expected structure or format of the descriptor object, nor does it explain the exact interpretation of 'safe_to_present' beyond a one-line caveat. It adds semantic value but leaves some param-level 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?

  The description clearly states the tool's purpose: 'Analyze one exact unsigned EVM call before it is presented to a signer.' It specifies the resource (unsigned EVM call), the verb (analyze), and the scope ('only the selected function is assessed'). It distinguishes from siblings by framing itself as 'PRIMARY transaction-time gate' and listing specific outputs (present/review/block) that differ from likely descriptor validation or contract scanning.

  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?

  Explicit guidance is given: 'Use this as the PRIMARY transaction-time gate.' The meanings of block, review, and safe_to_present are explained, clarifying when to rely on the tool. However, it does not explicitly mention when to use alternatives (e.g., scan_contract, explain_signature, check_descriptor), so it lacks a full when-not comparison.

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

• scan_contractA
  4.6/5.0
  Behavior5/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It honestly states limitations: 'Requires a verified ABI on Sourcify; returns matched=false with a reason when the ABI is unavailable or the fetch fails. Does not analyze bytecode, proxy implementations beyond the fetched ABI, or runtime behavior.' It also clarifies the interpretation of findings: 'Flags DANGEROUS CAPABILITIES... not proof of malicious intent.' The return shape is disclosed, providing a complete picture.

  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 headers (PURPOSE, GUIDELINES, LIMITATIONS, EXAMPLE), making it easy to scan and front-loaded with the purpose. It is slightly longer than needed, but every section contains valuable information. The format is appropriate for the tool's complexity.

  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 no output schema and no annotations, the description is remarkably complete. It explains the return structure, failure modes, limitations, and usage context in detail. It also provides an example, making it fully actionable for an agent. The description covers all necessary aspects for correct invocation and interpretation.

  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 the baseline is 3. The description adds an example call with both parameters, which is helpful, but it does not add semantic meaning beyond the schema descriptions (address format, chain_id values). The example is a minor bonus but not a significant enhancement.

  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: 'Assess a deployed EVM contract for structural danger primitives by ADDRESS — no descriptor needed.' It elaborates with specific actions ('Fetches the contract's verified ABI from Sourcify and flags every signable function that is a 'loaded gun'') and lists the specific primitives detected. It distinguishes from siblings by noting 'no descriptor needed' and explicitly stating it is not a signing gate, unlike preflight_transaction.

  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?

  Provides explicit when-to-use guidance: 'Call this to vet a contract an agent is about to interact with BEFORE any transaction is even built — the earliest possible safety check.' It also gives alternative tool guidance: 'Once a pending call is built, use preflight_transaction; neither this discovery scan nor check_descriptor is a signing gate.' This clearly explains when to use this tool versus alternatives.

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

• check_descriptorA
  4.7/5.0
  Behavior5/5

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

  With no annotations, the description carries the full behavioral burden. It discloses limitations: static analysis, no simulation against live chain state, no economic exploit detection, and explicitly states its verdict is not a pending-call decision. This is rich and honest transparency.

  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 structured into PURPOSE, GUIDELINES, LIMITATIONS, and EXAMPLE sections. Each segment is purposeful and front-loaded; nothing is redundant or wasteful, making it highly concise for its complexity.

  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?

  Even without an output schema, the description fully covers the tool's purpose, usage boundaries, limitations, and example invocation. It leaves no critical gap for an agent to understand when and how to use it.

  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% and the descriptor parameter is already documented. The description adds an example call but largely reaffirms the schema's structure. Baseline 3 applies because the description does not significantly augment parameter understanding 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 opens with a specific verb ('Authoring-time review') and names the resource (ERC-7730 Clear Signing descriptor). It clearly distinguishes from sibling tools by focusing on descriptor analysis rather than transaction preflight or contract scanning.

  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 'Use this while writing or reviewing a descriptor' and 'Never use it to approve a pending transaction... use preflight_transaction' provides clear when-to-use and when-not-to-use guidance, directly naming the alternative tool.

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

• explain_signatureA
  4.7/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. It discloses limitations: does not run danger-primitive scan, does not simulate on-chain effects, and returns found=false with available function names when the name is missing. It also warns 'MUST NOT approve a pending signature', which is a critical behavioral constraint.

  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 well-organized into PURPOSE, GUIDELINES, LIMITATIONS, and EXAMPLE sections. It front-loads the core purpose and each section is concise without filler. The length is justified by the tool's complexity and the need to differentiate from siblings.

  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?

  There is no output schema, so the description explicitly defines the return object: {found, function, sentence, tier, reason}. It also covers the failure case (found=false) and provides a concrete example. This makes the tool's behavior fully understandable without requiring additional context.

  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 all parameters already well-described. The description adds an example invocation and clarifies 'function' vs 'signature' usage, but this is largely redundant with the schema. No significant new parameter semantics are provided, so 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's purpose: 'Review UX copy for ONE function of an ERC-7730 descriptor'. It specifies the resource (ERC-7730 descriptor), the action (review/explain), and the output. It also explicitly differentiates from siblings by noting it is not bound to chain/sender/calldata and does not approve signatures, distinguishing it from preflight_transaction, check_descriptor, and scan_contract.

  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 gives explicit when-to-use guidance: 'Use this only while authoring or reviewing confirmation copy'. It also names alternatives: 'Use preflight_transaction for every pending call' and 'use check_descriptor / scan_contract for that' for danger-primitive scan. This fully covers when and when not to use the tool.

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