Server Quality Checklist

Tool Scores

• minia2a_get_serviceA
  4/5.0
  Behavior3/5

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

  The annotations already declare readOnlyHint=true, so the read-only safety is covered. The description adds useful context about what information is returned (price, endpoint URL, input schema, usage instructions), similar to adding a scoping constraint. It does not go into deeper behavioral traits like rate limits or error behavior, but for a simple read-only lookup this is adequate.

  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 with no filler. The main purpose is front-loaded, and the usage guidance is packed into a short second sentence. Every word earns its place.

  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 single-parameter, read-only tool with no output schema, the description is nearly complete: it states what the tool does, what it returns, and when to use it. It could mention that serviceId typically comes from minia2a_list_services, but that is a minor gap rather than a significant omission.

  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 parameter serviceId is already documented as 'The service ID or name to get details for.' The description does not add additional meaning beyond the schema, such as how to discover valid serviceIds or format expectations. This meets the baseline but does not exceed 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 verb ('Get detailed information') and the specific resource ('a specific x402 service on minia2a.uk'), and lists the payload (price, endpoint URL, input schema, usage instructions). It distinguishes itself from sibling tools like minia2a_list_services (specific vs. list) and minia2a_call_service (preparation vs. invocation).

  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 says 'Use this before calling a service to understand what it needs,' which is a clear when-to-use directive. It does not name alternative tools or provide when-not-to-use conditions, but the context is strong enough to guide an agent to the right tool.

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

• minia2a_creditsA
  4.1/5.0
  Behavior5/5

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

  This goes well beyond the readOnlyHint annotation by disclosing key non-obvious behavior: no per-wallet balance endpoint, automatic credit decrement via ?wallet=<your-wallet>, and trial visibility through X-Trial-* headers or the 402 body. This is exactly the kind of context an agent needs to avoid incorrect assumptions. No contradiction with the 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?

  Three sentences with no wasted words. The main caveat about the missing per-wallet balance endpoint is front-loaded in the second sentence, and the final sentence adds useful headert/response details without padding.

  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 zero-parameter, read-only informational tool, the description is largely complete and the V5-specific note is valuable. The main gap is that 'platform-level stats' is vague and the description does not specify which stats are returned or how they relate to minia2a_get_stats.

  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 tool has zero parameters, so the baseline is 4. The description even enriches context by mentioning the ?wallet=<your-wallet> query parameter used in service calls, even though it is not an input to this tool.

  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 a verb and resource: 'Explain the V5 credit/trial model and report platform-level stats.' It is unambiguous that this is an informational/read-only tool, but it does not explicitly differentiate from the sibling minia2a_get_stats, which may also report platform-level stats.

  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 when to use it — for credit/trial model questions — and the note warns the agent that V5 has no per-wallet balance endpoint, which prevents a common misuse. However, it does not explicitly state when to prefer this over minia2a_get_stats or provide when-not conditions.

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

• minia2a_buy_creditsA
  4.2/5.0
  Behavior4/5

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

  Annotations already flag destructiveHint=true, and the description adds meaningful behavioral context: this is a claim operation tied to an on-chain transfer rather than an in-app purchase. It explains the required workflow and outcome, though it does not detail irreversibility, duplicate submission handling, or verification requirements beyond the transfer.

  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 compact and front-loaded with the core purpose. Every sentence earns its place: the first defines the action, and the second explains the necessary on-chain workflow and product constraint. No filler or redundant restating of the tool name.

  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 mutation-oriented nature and lack of an output schema, the description adequately covers the preconditions, action, and expected outcome. It could be even more complete with a note about what response to expect after submission or a pointer to verify resulting credits, but the essential information for correct invocation is present.

  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 provides 100% parameter coverage with clear descriptions for wallet and txHash. The description reinforces the workflow by connecting the transaction hash to the claiming process, but it does not add substantial new meaning beyond the schema for the parameters themselves.

  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 identifies the action ('Claim credits') and the precise context: a completed USDC transfer whose transaction hash is submitted to credit a wallet. It also distinguishes this from a generic purchase by stating V5 has no in-app balance purchase, helping differentiate it from sibling tools like minia2a_credits.

  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 explicit usage steps: send USDC on a supported chain to the platform wallet, then submit the transaction hash. It also states that there is no in-app purchase alternative. However, it does not explicitly mention when not to use the tool or point to a sibling for related actions like checking credit balance.

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

• minia2a_get_statsA
  4.2/5.0
  Behavior3/5

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

  The readOnlyHint annotation already establishes that this is a read-only operation. The description adds context about the kind of statistics returned (services, agents, transaction volume, uptime) but does not disclose additional behavioral details such as data freshness, response format, or any limitations. This is acceptable given the annotation coverage but not exceptional.

  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 concise sentences with no wasted words. The action and resource are front-loaded, followed by concrete examples and a use case. The only minor flaw is the vague 'and more', but it does not meaningfully detract from the clarity.

  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 zero-parameter, read-only statistics tool, the description provides enough context for an agent to decide when to call it. However, the absence of an output schema means the agent is left guessing about the exact response shape, and the description does not specify return format or whether the stats represent a snapshot or aggregated totals.

  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?

  There are zero parameters, and the schema coverage is effectively 100%, so there is no parameter semantics burden on the description. The description appropriately clarifies what the tool returns rather than parameter details, which would be irrelevant here.

  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 a specific verb ('Get'), a specific resource ('current platform statistics for minia2a.uk'), and enumerates the kinds of data included. This differentiates it from sibling tools like minia2a_list_services or minia2a_get_service without requiring the agent to open schemas.

  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 phrase 'Useful for understanding the marketplace's scale and health' provides clear context for when this tool should be used. It does not explicitly name alternatives or exclusion conditions, but the purpose is distinct enough that an agent can infer the appropriate use case.

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

• minia2a_check_endpointA
  4.3/5.0
  Behavior5/5

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

  Beyond the readOnlyHint annotation, the description discloses the nine validation signals, the return format (score 0-100%), and the per-check PASS/FAIL detail. This accurately sets expectations for behavior and output without contradicting the annotations.

  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?

  The description is moderately long but every component adds value: purpose, check list, return format, and usage note. The date and parenthetical example are minor extras, but the text is generally tight and 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?

  For a single-parameter validation tool with no output schema, the description adequately covers what it checks, what it returns, and when to use it. It does not mention failure behavior or network prerequisites, but these are not essential for correct selection and invocation.

  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 covers the single parameter (endpointUrl) with 100% description coverage and an example. The description adds no additional parameter semantics beyond the schema, so the baseline of 3 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?

  The description names a specific verb ('Validate'), a specific resource ('any x402 endpoint'), and a concrete purpose ('Claude Code auto-mode readiness'). It enumerates the exact checks, making it clearly distinguishable from siblings like minia2a_list_services and minia2a_call_service.

  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?

  It explicitly states 'Use this before calling a paid endpoint to verify it works with autonomous agents', which gives a clear when-to-use instruction. It does not mention when-not-to-use or alternatives, but the pre-call usage directive is actionable and sufficient.

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

• minia2a_list_servicesA
  4.3/5.0
  Behavior4/5

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

  With readOnlyHint=true, the safety profile is already disclosed. The description adds useful behavioral context by stating this is a pre-call discovery step and enumerating what the listing returns (name, description, price, endpoint), reinforcing that it is non-mutating and informational.

  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 tight sentences with no filler. The main action is front-loaded, the return contents are summarized, and the usage intent is stated in a single clause.

  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?

  For a low-complexity read-only list operation with fully documented parameters and no output schema, the description fully covers what the tool does, what it returns, and when to use it. Nothing essential is missing.

  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%: limit, search, and category each already have meaningful descriptions. The tool description adds no parameter-specific semantics beyond the schema, so the baseline 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 begins with a specific verb and resource: 'List available x402 services on minia2a.uk'. It clearly distinguishes itself from siblings like call_service or get_service by framing this as the discovery/listing operation that precedes invocation.

  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 says 'Use this to discover what capabilities are available before calling them', giving a clear when-to-use signal. It does not mention when not to use it or contrast with get_service, but the intended usage context is unambiguous.

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

• minia2a_registerA
  4.4/5.0
  Behavior4/5

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

  The description goes beyond the destructiveHint annotation by explaining side effects: wallet generation, private key return, platform non-custody, and per-wallet trial limits. It does not describe every possible failure mode, but it reveals the key behaviors an agent should know before invoking it.

  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 compact and front-loaded. The first sentence gives the core purpose and reward; the second explains the optional-input behavior and security implications; the last clarifies the trial scope. Every sentence contributes, with no 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?

  For a tool with no output schema, the description covers the main behaviors well: registration, trial calls, wallet generation, private key return, and custody. The only notable gap is that the return value for the supplied-wallet path is not specified, but the provided information is sufficient for correct invocation in the common cases.

  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?

  Input schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics by explaining the EIP-191 signature content, the dependency between wallet and signature, and the fallback behavior when wallet/signature are omitted. This is genuinely useful 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?

  The description states a specific verb and resource: register for minia2a.uk using a self-custody wallet and EIP-191 signature, with a concrete outcome of 5 free trial calls. This clearly distinguishes it from sibling tools like minia2a_credits or minia2a_call_service, which serve different purposes.

  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 clearly explains the two usage modes: provide an existing wallet+signature, or omit them and have the tool generate a fresh wallet. It does not explicitly state when not to use the tool or name alternatives, but the conditional guidance is strong and actionable.

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

• minia2a_call_serviceA
  5/5.0
  Behavior5/5

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

  Beyond the destructiveHint annotation, the description discloses real behavioral details: the private key never leaves the process, only the signature is transmitted, automatic payment never silently charges, and a 402 response triggers manual or automatic payment handling. No contradiction with the annotations exists.

  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 dense but well-structured with numbered access paths, followed by the autoPay caveat and a critical final note about wallet. Every sentence earns its place and there is no repetition of the schema.

  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?

  The tool has a complex payment/trial model, and the description fully covers trial buckets, 402 handling, automatic payment, security, and failure conditions. A generic success return format cannot be defined since output depends on the called service, but the x402 flow is well specified.

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

  Parameters5/5

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

  Schema coverage is already 100%, and the description adds essential meaning beyond the schema: the privateKey is used locally for EIP-191 signing, autoPay requires privateKey and USDC, and wallet alone does not access the wallet trial bucket. These details materially affect how parameters must be combined.

  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 opens with a specific verb and resource: 'Call an x402 service on minia2a.uk', then explains three distinct access paths. This clearly separates it from sibling metadata, registration, and stats tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives explicit guidance on exactly when to use each mode: omit everything for the paid path, pass privateKey for trial calls, and enable autoPay with privateKey for automatic 402 payment. It also states an important exclusion: wallet alone does NOT reach the wallet bucket.

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