Server Quality Checklist

Tool Scores

• scan_tokenA
  3.7/5.0
  Behavior3/5

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

  Annotations already declare the tool as read-only, non-destructive, idempotent, and open-world. The description adds context about using 6 agents and returning a consensus score, but does not disclose behavioral specifics like authentication requirements or rate limits, which are left to the schema. 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?

  The description is two sentences, front-loading the action and immediately stating the output. Every sentence is informative with no fluff.

  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 tool has 5 parameters and no output schema. The description explains the output structure but does not mention parameter details like depth options or authentication methods, which are in the schema. While schema descriptions cover parameters, the description could be more complete for 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?

  All parameters have descriptions in the schema (100% coverage). The tool description does not provide additional parameter semantics beyond the schema descriptions. It hints at depth but does not elaborate.

  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 performs a comprehensive multi-agent risk scan, distinguishing it from sibling tools like get_quick_score and check_rug_risk. It specifies the output includes consensus score, risk level, and agent-level findings.

  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 states the tool is for 'safe trading decisions', implying usage when a full risk scan is needed, but does not explicitly contrast with sibling tools like get_quick_score or check_rug_risk. No when-not guidance is provided.

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

• get_token_reportA
  3.8/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 value by specifying output format (markdown) and key report elements (score, risk level, findings, recommendations). 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, front-loaded with purpose and contents. Every word earns its place with no redundancy or fluff.

  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 annotations and rich schema, description is mostly complete. It covers purpose and output content, but could mention authentication methods (api_key vs tx_signature) or that results are shareable. Slight miss given sibling tools 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%, so parameters are already documented well. The description does not add extra meaning beyond schema, only implicitly ties 'shareable markdown' to output but not to parameters.

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

  Purpose5/5

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

  Description clearly states verb 'generate', resource 'shareable markdown report', and specific contents (score, risk level, security findings, recommendations). This differentiates it from siblings like 'get_quick_score' (just score) and 'check_rug_risk' (rug-specific).

  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 vs alternatives. Context like 'token analysis' is implicit but no mention of when to prefer 'get_quick_score' for speed or 'check_rug_risk' for focused risk assessment.

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

• check_rug_riskA
  4/5.0
  Behavior4/5

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

  Annotations already declare it as a read-only, idempotent operation. The description adds valuable context on the specific checks performed and the output format (SAFE/CAUTION/DANGER), enhancing transparency 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 purpose, and each sentence contributes meaning. No unnecessary words or repetition.

  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?

  For a tool with good annotations and schema, the description provides the output format and a list of checks. It could mention chain support or error handling, but it is sufficiently complete for the agent to understand the tool's capabilities.

  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 covers all parameters with descriptions, achieving 100% coverage. The description does not add new semantic information about parameters, but the schema is sufficient. 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 performs a 'rug-pull-focused security scan' and lists specific checks (mint/freeze controls, etc.), differentiating it from siblings like scan_token or get_quick_score. The verb 'checks' and resource 'rug-pull risk' are precise.

  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 rug-pull risk assessment but does not explicitly state when to use this tool versus alternatives like scan_token or get_quick_score. No guidance on prerequisites or exclusions is provided.

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

• get_pricingA
  4.2/5.0
  Behavior4/5

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

  Annotations already mark it as read-only and idempotent, so the description's job is lighter. It adds context about what is returned (rates, wallet, instructions), which goes beyond annotations. 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?

  Three sentences, each adding value: purpose, contents, optional filtering. No redundant phrases. Front-loaded with the core action.

  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?

  No output schema exists, but the description lists key output items (USDC rates, wallet/mint, free-tier limits, transaction instructions). It could mention response format, but given tool simplicity, it is 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 coverage is 100% with a clear description for the only parameter. The description simply restates the optional filtering. No additional 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?

  Description starts with 'Return current tool pricing and Solana payment details', clearly stating the verb and resource. It lists specific contents (USDC rates, wallet/mint, free-tier limits, transaction instructions) and mentions optional filtering. This distinguishes it from sibling tools like scan_token or verify_payment.

  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 this tool should be used when pricing or payment details are needed, and mentions optional filtering. It doesn't explicitly state when not to use or name alternatives, but the context is clear given sibling tools have different purposes.

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

• verify_paymentA
  4.2/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint, indicating safe, read-only, idempotent behavior. The description adds return value details (verification status, sender, amounts), which complements the 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 a single sentence followed by a list of return values, no filler words. Every sentence adds value, making it highly concise and well-structured.

  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 output schema, the description mentions return fields (status, sender, amounts) but lacks details on structure or types. Still, it provides sufficient context for a verification tool with simple responses. Adequate but not exhaustive.

  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 each parameter having a description. The tool description adds minimal extra meaning beyond the schema, only contextualizing tool_name as 'the tool the payment is for'. This meets the baseline but does not elevate 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's purpose: verifying a Solana USDC payment for a tool call. It specifies the blockchain and currency, and lists the return values, making it distinct from sibling tools which focus on token 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 does not provide explicit guidance on when to use this tool versus alternatives, though the sibling tools are unrelated. No when-not-to-use or alternative tool names are mentioned, leaving some ambiguity for an AI agent.

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

• get_quick_scoreA
  4.4/5.0
  Behavior5/5

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

  Beyond annotations (readOnlyHint, idempotentHint), the description adds valuable behavioral details: it is 'cached' and 'fast', returns specific data (score, band, metadata), and has a pricing model. These disclosures help the agent understand latency and cost implications.

  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 long, immediately stating the core purpose and return values, followed by critical pricing info. No extraneous words, and the most important details are 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 the tool's simplicity (5 parameters, no output schema), the description adequately covers purpose, return values, caching behavior, and pricing. It could mention what 'risk band' values are, but the agent likely infers from context. Sibling tools exist but differentiation is implicit.

  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 each parameter is already described in the input schema. The tool description does not add further parameter-level context (e.g., how to use api_key vs tx_signature). Baseline is 3 per guidelines for high schema coverage.

  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 function: 'Fast cached token risk check' and specifies it returns a score, risk band, and metadata for quick pre-trade screening. This distinguishes it from sibling tools like 'check_rug_risk' or 'scan_token' which likely offer more detailed or different analyses.

  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 provides context on when to use it ('quick pre-trade screening') and includes pricing details ('Free: 10 calls/day; paid calls: 0.02 USDC'), which helps an agent decide based on rate limits. However, it does not explicitly contrast with sibling tools or give conditions to avoid.

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