Server Quality Checklist

Tool Scores

• get_walletB
  3.1/5.0
  Behavior2/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 states it 'Get[s] wallet details', implying a read-only operation, but does not disclose behavioral traits such as required permissions, error handling, rate limits, or what happens if the wallet ID is invalid. For a tool with no annotations, this leaves significant gaps in understanding its 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 concise and front-loaded in a single sentence, efficiently stating the tool's purpose and key details without unnecessary words. Every part of the sentence contributes to understanding, making it well-structured and easy to parse.

  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's low complexity (1 parameter, no output schema, no annotations), the description is somewhat complete but lacks depth. It covers the basic purpose and parameter source, but without annotations or output schema, it should ideally include more on behavior, error cases, or return format to be fully helpful. It meets minimum viability but has clear gaps.

  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 description coverage is 100%, with the parameter 'walletId' well-documented in the schema. The description adds minimal value beyond the schema by mentioning the ID comes from 'create_wallet', but does not provide additional semantics like format constraints or examples. Baseline 3 is appropriate as the schema handles most of the parameter documentation.

  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's purpose with a specific verb ('Get') and resource ('wallet details'), specifying what information is retrieved (status, address, and public key). However, it does not explicitly differentiate from sibling tools like 'list_wallets', which might retrieve multiple wallets, leaving some ambiguity.

  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?

  The description provides no guidance on when to use this tool versus alternatives. It mentions the wallet ID comes from 'create_wallet', but does not specify if this is for single-wallet retrieval after creation, or how it differs from 'list_wallets' for browsing wallets. No explicit when/when-not or alternative usage is stated.

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

• create_walletA
  4/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 and does well by disclosing key behavioral traits: the asynchronous nature of wallet creation, the initial status ('creating'), transition to 'ready', and the need for polling with wait_for_wallet_ready. It doesn't cover aspects like rate limits, error handling, or authentication needs, but the disclosed information is valuable.

  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 front-loaded with the main purpose, followed by essential behavioral details in two concise sentences. Every sentence earns its place by adding critical information without 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?

  Given the complexity (asynchronous creation with polling), no annotations, and no output schema, the description is fairly complete. It explains the creation process and next steps but could improve by mentioning error states or response format. However, it covers the core context adequately.

  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 parameters thoroughly. The description adds no additional meaning beyond what the schema provides (e.g., it doesn't explain parameter interactions or default behaviors like scheme defaults). Baseline 3 is appropriate as the schema does the heavy lifting.

  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 action ('Create an MPC wallet via Para') and resource ('wallet'), distinguishing it from siblings like get_wallet or list_wallets. However, it doesn't explicitly differentiate from sign_raw or wait_for_wallet_ready in terms of purpose, which slightly reduces specificity.

  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 context on when to use this tool (for creating wallets) and explicitly mentions an alternative tool (wait_for_wallet_ready) for polling until ready. It doesn't specify when not to use it or compare with other siblings like get_wallet, but the guidance is sufficient for basic usage.

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

• list_walletsA
  4.2/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 and does well by disclosing key behavioral traits: it's a read operation (fetch), uses Promise.allSettled for individual calls, has a rate limit (max 10 IDs), and explains the implementation workaround. It doesn't mention error handling or response format details.

  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 perfectly concise with three sentences that each earn their place: states purpose, explains implementation rationale, and specifies constraints. It's front-loaded with the core functionality and wastes no 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 tool with no annotations and no output schema, the description does well by covering purpose, implementation, and constraints. However, it lacks details about the return format (e.g., structure of results from Promise.allSettled) and error handling, which would be helpful given the complexity of batch operations.

  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 the 'walletIds' parameter fully. The description adds minimal value by restating the max 10 limit but doesn't provide additional semantics like ID format examples or validation rules beyond what the schema implies.

  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 specific action ('Batch-fetch multiple wallets by their IDs') and distinguishes it from siblings like 'get_wallet' (singular fetch) and 'create_wallet'. It explains this is a workaround for Para's lack of a native list endpoint.

  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 context about when to use this tool (when needing multiple wallets, up to 10 IDs) and implies an alternative (using 'get_wallet' for single wallets). However, it doesn't explicitly state when NOT to use it or compare it to all siblings like 'sign_raw' or 'wait_for_wallet_ready'.

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

• sign_rawA
  4.2/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 of behavioral disclosure. It effectively describes key traits: the data format requirement ('0x-prefixed hex string'), the wallet status prerequisite ('must be in "ready" status'), and the return value ('Returns the signature'). However, it lacks details on error conditions, rate limits, or authentication needs, which are important for a signing operation.

  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 and front-loaded, with three sentences that each serve a distinct purpose: stating the action, specifying prerequisites, and indicating the return. There is no wasted language, making it easy for an AI agent to parse and understand quickly.

  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 (a signing operation with prerequisites), lack of annotations, and no output schema, the description does a good job covering the essentials: purpose, input requirements, and return value. However, it could be more complete by addressing potential errors, security implications, or the signature format, which would help an agent use it more effectively.

  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 description coverage is 100%, so the input schema already fully documents the parameters. The description adds minimal value beyond the schema by reiterating the data format requirement and wallet status, but does not provide additional semantic context or usage examples. This meets 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 clearly states the specific action ('Sign arbitrary data'), the resource ('with a wallet via MPC'), and distinguishes it from siblings by focusing on signing rather than wallet creation, retrieval, listing, or status waiting. It provides a precise verb+resource combination that leaves no ambiguity about the tool's function.

  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 context for when to use this tool: when you need to sign data with a wallet via MPC. It implicitly suggests using 'wait_for_wallet_ready' to ensure the wallet is in 'ready' status first, but does not explicitly name alternatives or state when not to use it, which prevents a perfect score.

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

• wait_for_wallet_readyA
  4.4/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 and does so effectively. It discloses key behavioral traits: it's a polling operation (not a one-time check), specifies the polling interval ('every 2 seconds'), mentions a configurable maximum wait time with a default ('default 30s'), and clarifies the success condition ('status becomes "ready"'). This provides clear operational context beyond basic parameters.

  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 core purpose and followed by operational details. Every word earns its place: no fluff, no repetition, and it efficiently covers polling mechanics, timing, and the success condition in minimal 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?

  Given the tool's moderate complexity (polling with timing), no annotations, and no output schema, the description is largely complete. It explains what the tool does, how it behaves, and key parameters. However, it lacks details on return values (e.g., what happens on success vs. timeout) and error conditions, which would be needed for a score of 5, especially without an output schema.

  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 both parameters ('walletId' and 'maxWaitMs') with their types and default values. The description adds marginal value by reiterating the default in seconds ('default 30s') and implying 'walletId' is for polling, but does not provide additional semantic context (e.g., format of walletId or behavior if maxWaitMs is exceeded). Baseline 3 is appropriate when schema handles most documentation.

  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 specific action ('Poll a wallet'), the target resource ('wallet'), and the precise goal ('until its status becomes "ready" (MPC key generation complete)'). It distinguishes this tool from siblings like 'get_wallet' (which presumably retrieves current state without polling) and 'create_wallet' (which initiates creation).

  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 usage context by specifying it's for waiting until a wallet's MPC key generation is complete, suggesting it should be used after wallet creation. However, it does not explicitly state when not to use it (e.g., for non-ready status checks) or name alternatives like 'get_wallet' for immediate status checks, which would be needed for a score of 5.

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