Server Quality Checklist

Tool Scores

• bridge_historyC
  2.9/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 does not disclose what operations the journal covers, how far back history extends, whether this is a read-only safe operation, whether audit includes sensitive info, or pagination limits.

  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 sentences, front-loaded with the core purpose, no wasted words. Efficiently compact though under-specified.

  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?

  With no annotations, 0% schema coverage, no output schema, and 2 unspecified parameters, the description is too thin. It hints at the transfer-completion use case but fails to document parameters or return/behavior details.

  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?

  Schema description coverage is 0%, so the description must explain the parameters (limit, includeAudit). It does not. The text enumerates no parameter details at all, leaving the agent to guess their semantics.

  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?

  Clear purpose: lists recent transfers and operation journal. Sensibly oriented around the sibling tool bridge_status (for unfinished transfers), which helps distinguish it from the status tool.

  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 the use case (check for unfinished transfers), but no explicit when-to-use vs alternatives or when-not-to-use guidance. It mentions using bridge_status alongside, which gives some context, but lacks clear exclusions.

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

• bridge_list_chainsA
  3.6/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. It's a read/list tool and the description conveys read intent ('Возвращает поддерживаемые сети'), but it doesn't disclose return format, default behavior when mode is omitted, or pagination. It does clarify the mode default ('По умолчанию — все') which adds some value.

  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 sentences, no wasted words. The first states the purpose, the second provides a practical usage tip. Efficient and front-loaded.

  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?

  For a simple discovery tool with optional single parameter and 100% schema coverage, the description is reasonably complete. It could mention that mainnet is the operational default or clarify testnet applicability, but the network-key guidance meaningfully promotes correct usage across the sibling tool suite.

  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 the mode parameter fully documented in the schema (enum with descriptions). The description adds marginal value by clarifying the default ('По умолчанию — все'), and its main instruction about using network keys relates to tool output, not parameters. Baseline 3 is appropriate.

  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 states a clear purpose: returns supported networks and their CCTP domains. It adds a useful cross-tool guideline (use returned network keys like 'base', 'arbitrum' in other tools), which helps distinguish its discovery role from siblings like bridge_start or bridge_quote.

  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 instructs when to use the output — to supply network keys to other bridge tools. However, it doesn't explicitly state when not to use it or name alternatives, though its discovery nature is implied against the operational siblings present.

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

• bridge_wallet_infoA
  3.7/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 full burden. It does disclose an important safety property ('keys are never returned'), which is valuable behavioral context. However, there's no mention of account prerequisites, whether chain selection is needed, fee details, or specificity about what 'current limits' means. For a no-annotation read tool, the disclosure is partial but the key privacy aspect is covered.

  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?

  One concise sentence delivers the purpose and the key safety disclosure. Zero waste, front-loaded with the action and data types, ends with the important constraint about keys never being returned. Appropriately sized for a parameterless read tool.

  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?

  The tool is simple (no params, no output schema, read-only semantics) so the completeness bar is lower. The description covers what it shows and the critical privacy guarantee. Minor gaps exist around what 'current limits' specifically refers to and whether any setup is needed, but for a zero-parameter informational tool the coverage is 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?

  The tool has zero parameters, so there's no parameter schema to compensate for. The description adds meaning about the data returned (address, signer type, current limits) without needing to document parameters. This receives the baseline 4 for tools with no parameters since the semantic burden is inherently lighter.

  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 shows wallet address, signer type, and current limits. It names the verb 'shows' and the specific data types. However, it doesn't explicitly distinguish itself from sibling tools like bridge_start or bridge_status, though its function (wallet info) is distinct enough from the action-oriented siblings to be reasonably clear.

  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 this is an informational read tool for wallet details, but provides no explicit guidance on when to use it versus siblings. There are no exclusions or alternative tool recommendations. For a zero-parameter read-only tool like this, the context is fairly self-evident, but explicit guidance would help.

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

• bridge_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. It discloses that no transactions are sent (read-only behavior), which is the key transparency point. However, it doesn't describe what happens on validation failure, rate limits, or what the response format looks like.

  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 concise sentences with zero wasted words. The first sentence states purpose and what's checked; the second gives an actionable sequencing directive. Front-loaded and efficient.

  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?

  This is a straightforward quote/check tool with 4 simple parameters, all documented. The description covers the non-obvious aspects (no transaction sent, call order relative to bridge_start). No output schema exists, so some description of what's returned would help, but for a validation tool the current coverage is quite 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?

  Schema coverage is 100% and each parameter has its own description. The description names the checked items (balances, commission, limits) but adds little param-specific meaning beyond the schema. Baseline 3 is appropriate since schema already documents all params.

  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 the verb ('Проверяет маршрут') and the resource scope (balances, commission, limits) without sending transactions. It distinguishes itself from bridge_start (which actually executes) by explicitly noting no transactions are sent.

  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?

  Provides an explicit usage directive: 'Вызывай перед bridge_start' (call before bridge_start), establishing clear sequencing context. It doesn't explicitly exclude sibling tools like bridge_status or bridge_wallet_info, but the sequencing guidance is strong.

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

• bridge_statusA
  4.1/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full disclosure burden. It does well: states idempotency (repeat safe, mint only once), the conditional behavior (only mints when ready), and the retry instruction. These are genuinely useful behaviors beyond schema. Could add side effects but this is solid coverage for a non-destructive-ish 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?

  Two sentences, zero waste. Every clause carries actionable meaning: what it does, the once-only guarantee, and the retry instruction. Front-loaded with the primary purpose. Ideal length.

  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 2-param tool with no output schema, this description is quite complete. It covers the operation flow, idempotency, and retry behavior. It doesn't show what return value indicates readiness vs completion, but with no output schema the description need not detail return formats. Minor gap: could clarify what to do with history/other bridging tools, but overall adequate for complexity.

  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 50% (transferId has no description; autoMint does have one). The description adds meaningful semantics: autoMint is implicitly explained by 'проверяет готовность... выпускает USDC' suggesting default behavior. The 'false — только проверить' schema text covers autoMint. The description augments transferId context (it identifies which transfer to bridge). Reasonably compensates for coverage gap.

  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?

  Description clearly states the verb ('Проверяет готовность аттестации' and 'выпускает USDC'), the resource (Circle attestation for USDC bridging), and the action's outcome. It distinguishes from siblings implicitly — bridge_start initiates, bridge_status checks/completes. However, it doesn't explicitly name a sibling alternative, so not a 5.

  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 gives explicit guidance: check attestation readiness, then mint USDC; if not ready, wait a minute and retry. This is clear operational context. However, it doesn't explicitly say when NOT to use this vs siblings (e.g., 'use bridge_start to initiate'). Clear context but no explicit exclusions.

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

• bridge_startA
  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 of behavioral disclosure. It transparently states the mutation side-effects (approve + burn), the idempotency guarantee (duplicate protection with same key), the partial-pipeline nature (issuance is separate), and dryRun's no-transaction behavior. It doesn't describe return format details, but the core behavioral traits are well disclosed.

  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?

  Three sentences, each earning its place: first states core function, second covers the critical idempotencyKey requirement, third mentions dryRun. Front-loaded with the action verb. Slightly dense but efficient — could arguably be trimmed but remains tight and purposeful.

  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?

  This is a financially destructive operation (burning USDC) with 6 params and no output schema and no annotations. The description makes a solid effort: it covers the two-step pipeline, idempotency, and dryRun validation. It could add return-value expectations (transferId is mentioned) and clarify recipient semantics, but given the complexity and risk profile, it covers most essential operational 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?

  Schema description coverage is only 33% (2 of 6 params documented: dryRun and idempotencyKey), while from/to/amount/recipient lack schema descriptions. The description adds meaning for idempotencyKey (duplicate-protection) and dryRun (no-transaction check) beyond the schema, but the from/to/amount/recipient params remain undocumented in both schema and description, leaving meaning gaps.

  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+resource combination — 'performs approve and USDC burn in source network' — and clearly distinguishes from siblings by noting that issuance is done separately via bridge_status. It specifies the immediate return of transferId and the separate issuance flow, which effectively differentiates it from sibling 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?

  The description explicitly says when to use this tool vs bridge_status ('issuance in target network is done separately via bridge_status'), mandates idempotencyKey usage to prevent duplication, and recommends dryRun for cost-free validation. This gives clear when/when-not and alternative guidance.

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