Server Quality Checklist

Tool Scores

• get_tokenA
  3.6/5.0
  Behavior2/5

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

  No annotations provided, so the description is the sole source. It indicates a read-only behavior (gets a token) but does not disclose what happens if the token is not found, authentication requirements, rate limits, or any other operational traits.

  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, highly concise, and immediately communicates the core function. 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?

  For a simple tool with two required parameters and no output schema, the description covers the essential purpose and inputs. Lacks mention of output format or error handling, but adequate for the complexity.

  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 baseline is 3. The description adds value by clarifying that 'token' can be an address or symbol, which is slightly more explicit than the schema's 'Token address or symbol'.

  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 'Get' and resource 'single token', distinguishing it from sibling tools like get_tokens which likely retrieve multiple tokens. The input parameters (chain and token address/symbol) are explicitly mentioned.

  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?

  No explicit guidance on when to use this tool versus alternatives like get_tokens. The context implies it's for retrieving a specific token by identifier, but no exclusion criteria or when-not advice is given.

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

• get_toolsA
  3.6/5.0
  Behavior2/5

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

  No annotations provided, and description only states a read-like operation ('list'), but does not disclose any side effects, authentication needs, rate limits, or response structure. Agent cannot infer behaviors like idempotency or safety beyond the surface.

  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 short sentences, front-loaded with core purpose, zero redundant words. Every word adds value.

  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?

  No output schema, no annotations, and minimal description leaves significant gaps: no return format, no pagination info, no distinction from sibling tools beyond name. Agent lacks essential context for correct invocation.

  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% for the single parameter 'chains', but description adds value by clarifying it's optional and specifying comma-separated format, which is not explicit in schema 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?

  Description uses specific verb 'List' and resource 'available tools' with concrete examples (bridges, DEXes), clearly distinguishing it from siblings like get_chains (list chains) or get_quote (get quotes).

  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?

  Implies use when listing tools is needed, but lacks explicit when-not, prerequisites, or comparisons with alternatives. The optional chains filter is mentioned, but no guidance on when filtering is necessary.

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

• get_quoteA
  3.9/5.0
  Behavior3/5

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

  No annotations are provided, so the description bears full responsibility for behavioral disclosure. It states the tool returns 'best route, output amount, calldata, gas,' which implies read-only behavior. However, it does not mention that no state changes occur, nor does it discuss permissions, rate limits, or error conditions. This is adequate but not exhaustive.

  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 consists of two sentences: the first states the tool's function, and the second provides essential prerequisite guidance. Every word is informative and there is no redundancy or 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?

  Given the tool has 10 parameters, no output schema, and no annotations, the description provides useful prerequisite guidance (use get_chains and get_tokens first) but lacks details on output format, parameter interdependencies (e.g., sender/receiver optionality, fee constraint), or common error scenarios. It is somewhat complete but could be more helpful for a complex multi-parameter 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 description coverage is 100% and each parameter has a clear description in the schema. The tool description adds no additional parameter-level detail beyond summarizing the overall return. It does hint at requiring prior resolution of chain IDs and token addresses, but this is more about usage context. With complete schema coverage, 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 clearly states the tool's purpose: 'Get a cross-chain quote: best route, output amount, calldata, gas.' It distinguishes this tool from siblings like get_chains (which lists chains) and get_tokens (which lists tokens) by specifying that it provides a quote for cross-chain transfers.

  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 advises to use get_chains and get_tokens first to resolve chain IDs and token addresses, providing clear context for when to use this tool. It does not explicitly address when not to use it or mention alternatives, but the guidance is sufficient given the sibling tools serve different purposes.

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

• get_tokensA
  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 must convey behavioral traits. 'List' implies a read-only operation, but there is no mention of authentication, rate limits, or whether results are paginated. The description is minimal but sufficient for a simple listing 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 a single, well-structured sentence with 8 words. It front-loads the main action 'List supported tokens' and then adds the optional filtering condition. 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?

  For a simple list tool with no output schema, the description adequately covers purpose and optional parameters. It could mention that the result is a list of token objects, but that is implied. The tool is complete enough for an 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?

  Schema coverage is 100% with descriptions for both parameters. The description adds that filtering is optional, but does not provide format details beyond the schema's comma-separated and example values. 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 lists supported tokens and allows optional filtering by chains and chainTypes. It distinguishes from 'get_token' which retrieves a specific token, and other siblings like 'get_chains'.

  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 specifies when to use optional filters ('Optionally filter'), which guides usage. However, it does not explicitly mention when not to use this tool or contrast it with alternatives like 'get_token' for a single token.

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

• get_chainsA
  4.1/5.0
  Behavior3/5

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

  With no annotations, the description carries full burden. It correctly implies a read-only operation ('list'), but does not disclose potential nuances like rate limits, authentication requirements, or whether the list is exhaustive. For a simple listing tool, this is acceptable but not exemplary.

  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 primary action. Every sentence adds value without 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 optional parameter, no output schema, no nested objects), the description fully covers the necessary information. There is no missing context needed for correct invocation.

  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 input schema covers the only parameter with a description, and the tool's description adds an example ('e.g. EVM,SVM') that clarifies usage beyond the schema. This provides additional semantic value.

  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 'List' and resource 'chains', clearly indicating the tool's function. It is well-distinguished from sibling tools like get_instructions, get_quote, etc., which focus on different resources.

  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 optional filtering but lacks explicit guidance on when to use this tool vs alternatives or when not to use it. The context of sibling tools suggests different purposes, so it's adequate but not thorough.

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

• get_instructionsA
  4.2/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 the tool returns a guide but does not disclose details about side effects, permissions, or return format. Adequate but not rich.

  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 instruction 'CALL THIS FIRST.' Every word earns its place; no wasted text.

  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 parameterless tool with no output schema, the description provides sufficient context: it is the initial call to get an overview. Could elaborate on guide contents, but overall complete for its simplicity.

  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, schema coverage 100%. Description adds meaning by explaining the tool returns a guide, which is beyond the schema's type definition. Baseline 4 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?

  Description clearly states it returns the guide for Delora MCP, with a specific verb and resource. It distinguishes itself from sibling tools like get_chains, get_quote, etc., by being the first call.

  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 instructs 'CALL THIS FIRST,' providing clear context for when to use this tool over siblings. No when-not or alternatives mentioned, but the context is sufficient for a starting point.

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