Server Quality Checklist

Tool Scores

• cook4fun_claimB
  3.4/5.0
  Behavior2/5

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

  No annotations provided, and the description offers only minimal behavioral info (claiming fees). Missing details on whether the call is a write operation, triggers transactions, requires wallet balance, or has side effects like gas fees.

  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?

  Single sentence, front-loaded with key action and resource. No wasted words; the entire description is functional and to the point.

  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?

  Despite missing annotations and some behavioral details, the description covers the essential purpose and parameter for a simple claim operation. It could mention expected outcomes or return values, but the lack of output schema reduces burden. Still fairly complete given tool simplicity.

  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% for the single required parameter (token), and the schema description adequately defines it. The tool description adds no extra semantic value beyond the schema, so the score is at baseline.

  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 specifies the action ('claim'), the resource ('wallet's share of a reward-sharing coin's accrued fees'), and distinguishes from sibling tools (buy, sell, launch, list_coins, wallet) by focusing on claiming rewards rather than purchasing, selling, or managing.

  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 like buying or selling. No prerequisites, context, or conditions for claiming are mentioned, leaving the agent to infer usage.

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

• cook4fun_buyA
  3.5/5.0
  Behavior3/5

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

  Without annotations, the description carries the full burden. It discloses slippage protection, a key behavioral trait, but omits details like whether the purchase is immediate, transaction result, or reversibility.

  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?

  Two front-loaded sentences convey the action and key details without redundancy. Could be slightly more structured but efficient overall.

  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?

  For a transaction tool with 3 parameters, no output schema, and no annotations, the description lacks completeness. It does not explain the return value, gas implications, or failure conditions, which are critical for an AI agent to use 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 description adds value by clarifying how to reference the token (0x address or $TICKER) and gives an example for ethAmount. However, the slippageBps parameter, though mentioned as slippage-protected, is not explicitly described, and schema coverage is 67%.

  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 'Buy' and resources 'cook4.fun coin' and 'ETH', clearly distinguishing it from sibling tools like cook4fun_sell or cook4fun_launch.

  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 buying coins but does not explicitly state when to use this tool over alternatives like cook4fun_claim or cook4fun_sell, nor does it mention prerequisites like having ETH.

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

• cook4fun_walletA
  3.8/5.0
  Behavior3/5

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

  No annotations provided, so description carries full burden. It indicates read-only behavior ('Show'), but does not disclose auth requirements or any side effects.

  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?

  Single, clear sentence with no wasted words. Front-loaded with action and result.

  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?

  Description explains return value (address and balance). No output schema needed for simple read. Contextually adequate.

  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?

  No parameters in schema; schema description coverage is 100%. No additional parameter info needed.

  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 action (Show) and resource (wallet address and ETH balance). Distinct from sibling tools (buy, sell, etc.).

  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 vs alternatives. It is implied for checking wallet info, but no explicit when-not or alternatives provided.

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

• cook4fun_launchA
  3.9/5.0
  Behavior3/5

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

  Discloses main actions (deploy, open pool, optional buy) and a prerequisite. No annotations present, so description carries full burden; lacks details on costs, reversibility, or side effects.

  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?

  Single compact sentence that conveys essential information without redundancy.

  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 10 parameters, no output schema, and no annotations, the description is minimal. Lacks explanation of return values, post-launch behavior, or parameter interactions.

  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?

  No parameter details in description; schema covers 60% of parameters with descriptions. Description adds no value beyond schema, 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 explicitly states the tool launches a new coin, detailing actions (deploys token, opens Uniswap V4 pool, optional first buy). It clearly distinguishes from sibling tools like cook4fun_buy, cook4fun_sell, etc.

  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?

  Mentions prerequisite ('requires a wallet with ETH'), providing context. No explicit when-not or alternatives, but sibling names imply usage for creation.

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

• cook4fun_list_coinsA
  4/5.0
  Behavior4/5

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

  The description discloses that the operation is read-only and requires no wallet, which is useful behavioral transparency given no annotations. It does not mention rate limits or empty returns, but the tool is simple.

  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 extremely concise with two sentences, front-loading the key purpose and behavioral hint. 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?

  Given the simplicity of the tool (one optional param, no output schema), the description covers the basic purpose and read-only nature. However, it omits the limit parameter and does not clarify the return format beyond market caps.

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

  Parameters2/5

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

  The input schema has zero description coverage, and the tool description does not mention the 'limit' parameter or its effect. The parameter is optional with constraints, but the description should guide usage.

  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 lists the newest coins on cook4.fun with their market caps, using a specific verb and resource, and is distinguished from sibling tools like buy, sell, etc.

  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 indicates it is read-only and requires no wallet, providing context for when to use. However, it does not explicitly exclude scenarios or mention alternatives among siblings.

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

• cook4fun_sellA
  4.2/5.0
  Behavior3/5

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

  With no annotations provided, the description adds value by stating 'Auto-approves and is slippage-protected.' However, it lacks details on failure modes, gas costs, or prerequisites, leaving some behavioral gaps.

  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 essential information: the main action, amount specification methods, and behavioral features. No redundancy or 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 no output schema and no annotations, the description covers inputs and key behaviors. Missing: return value, error handling, and prerequisites. Still mostly complete for a sell tool.

  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 80%, and the description adds meaning by explaining the three amount modes (exact, percent, all) corresponding to parameters. It does not elaborate on 'slippageBps' beyond the general claim of slippage protection.

  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 action: selling a cook4.fun coin back to ETH. It distinguishes from sibling tools like buy, claim, launch, etc., by specifying the seller's perspective and the target asset (ETH).

  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 explains how to specify the amount (exact, percentage, or all) and mentions auto-approve and slippage protection. It does not explicitly contrast with alternatives, but the context of selling vs. other operations is clear from sibling tool names.

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