Server Quality Checklist

Tool Scores

• get_launch_feedA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden of disclosing behavior. It adds a key behavioral constraint: 'Returns only launches newer than the specified time.' However, it does not mention whether the operation is read-only, possible limits, pagination, response format, or error behavior, leaving some ambiguity for a 'get' tool.

  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 concise, front-loaded sentences. Each sentence adds value: purpose, use case, and behavior. There is no fluff or repetition, making it appropriately sized.

  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 simple polling tool with one well-documented parameter and no output schema, the description covers the core aspects: what it does, why it's useful, and the time-filter behavior. It lacks details about the response structure or limits, which could be important, but the simplicity of the tool and the clarity of the parameter make it 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?

  The schema already documents the parameter fully (since_minutes_ago with default 60 and a clear description). The tool description adds no additional meaning beyond the schema, aside from referring to 'a given timestamp' which is slightly inconsistent with the actual minutes-based parameter, but the schema resolves this. Thus, the description does not enhance parameter understanding beyond the schema.

  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 retrieves a feed of token launches since a given timestamp, with a scope defined by time. It distinguishes itself implicitly from siblings like 'watch_launches' via the word 'polling' and 'feed', but it does not explicitly differentiate from similar tools such as watch_launches.

  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 states the primary use case: 'Useful for polling new launches periodically.' This provides clear context for when to use the tool, but it does not mention alternatives or when not to use it, so it lacks explicit exclusions.

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

• multi_quoteA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden of disclosing behavior. It explains that the tool 'Shows how many tokens you'd receive for a given ETH amount,' indicating a read-only quote operation, but it does not mention any limitations, data freshness, or whether quotes are binding. Core behavior is clear, but additional context would improve 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 two sentences, front-loaded with the primary action and result. It is concise, avoids unnecessary details, and every sentence contributes meaningful 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 tool's simplicity (two parameters, no output schema), the description adequately explains both what the tool does and what it returns. It does not detail the exact return structure, but the phrase 'Shows how many tokens you'd receive' across multiple tokens gives sufficient context for an agent to invoke it correctly.

  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 already provides 100% coverage for both parameters, so the description adds minimal extra meaning. It does clarify that tokens are 'LaunchPad tokens' and that the quote is for a 'given ETH amount,' aligning with the schema, but this is not significant beyond what the schema already states. 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 function: 'Get buy quotes for multiple tokens at once.' It specifies both the verb and the resource, and the reference to 'multiple LaunchPad tokens' distinguishes it from sibling tools that handle watching launches, sniping buys, or checking safety.

  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 a clear use case with 'Useful for comparing opportunities,' which implies when this tool should be used. However, it does not explicitly state when not to use it or mention alternatives, though the sibling tool names make the distinction evident.

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

• snipe_buyA
  4/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It discloses a 0.5% platform fee, the DEPLOYER_PRIVATE_KEY requirement, and the return value (tx hash and tokens received). These go beyond the schema and provide critical behavioral context for an agent, though it does not cover failure modes or slippage behavior.

  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 concise sentences: the first states the core action and mechanism, the second covers the fee, and the third lists the env var requirement and return value. Each sentence adds necessary information without redundancy or filler.

  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 appropriately includes the return format ('tx hash and tokens received'). It also covers prerequisites (env var) and costs (fee). It could optionally mention potential failure conditions or slippage application, but for a simple buy operation, the current coverage 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%, so the schema already documents all three parameters (token, eth_amount, slippage_percent). The description adds no additional parameter-specific semantics beyond global fee info, which is not tied to any single 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 states a specific verb and resource: 'Buy a token on the OBSD LaunchPad with ETH via PlatformRouter.' This clearly distinguishes it from sibling tools like watch_launches or multi_quote, which serve monitoring and quoting purposes. No ambiguity about what the tool does.

  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 through its action-oriented phrasing ('Buy a token...') but does not explicitly mention when to use this tool versus alternatives, nor does it provide exclusions or alternative tool references. The context (LaunchPad, ETH, fee) gives clear situational hints, but explicit guidance is missing.

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

• watch_launchesA
  4.2/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the burden. It discloses the ordering behavior ('newest first') and enumerates the exact fields returned, giving an agent a good sense of the output. It does not mention limitations like rate limits or pagination, but for a simple read tool this is reasonably transparent.

  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 main action and resource. The first sentence states the purpose and output fields; the second gives a clear use case. There is no wasted wording.

  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 only one optional parameter and no output schema, the description is sufficiently complete: it explains the ordering, return fields, and use case. Minor gaps like not describing the limit parameter in prose are covered by the schema, so the overall context is adequate.

  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 'limit' parameter, including a default value and description. The tool description does not add additional parameter semantics, relying on the schema, which matches the baseline 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 uses the specific verb 'Get' with the resource 'recent token launches from the OBSD LaunchPad on Base', clearly indicating a retrieval operation. It enumerates the returned fields (token address, pool, creator, etc.), which distinguishes it from siblings like get_launch_feed.

  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 clear use context: 'Use this to discover newly deployed tokens to trade.' It implies when to use the tool but does not explicitly state when not to use it or mention alternative tools, so it lacks exclusions.

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

• get_token_safetyA
  4.3/5.0
  Behavior4/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 the read-only nature ('Check', 'Returns') and enumerates the returned fields (liquidity depth, burn stats, fee rates, age, safety score). This is transparent for a simple read operation, though it doesn't detail the score's interpretation or edge cases.

  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 pack a clear purpose, a list of return values, and a usage recommendation. Every word earns its place, with no filler or redundancy.

  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 low complexity (one parameter, no output schema), the description is complete enough. It lists the key output fields and the use case, making it fully usable without 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?

  The input schema already has 100% coverage for the single 'token' parameter, with description 'Token contract address to check.' The description adds no further parameter meaning, so a baseline score of 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 ('Check') and resource ('safety metrics for a LaunchPad token'), clearly distinguishing it from sibling tools like snipe_buy or get_launch_feed. It directly states what the tool does and what it returns.

  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 before trading to assess risk.' This provides a clear when-to-use context, though it does not name alternative tools or state when not to use it.

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