Server Quality Checklist

Tool Scores

• get_balanceA
  3.8/5.0
  Behavior3/5

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

  No annotations are present, so the description carries the responsibility for behavioral disclosure. It clearly conveys that this is a read-only operation returning only the native token balance and its unit format. It does not describe possible error/revert behaviors or block scope, but these are relatively minor for a simple balance getter.

  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?

  A single, compact sentence that is front-loaded with the most important facts: the resource, the token type, and the return format. There is no filler, repetition, or ambiguous phrasing.

  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 read-only tool with only two parameters and no output schema, the description provides the essential invocation context and return unit. The schema fully documents the address and network parameters, so the description's only real gap is not describing failure or formatting edge cases, which is unlikely to block correct usage.

  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 baseline is 3. The description repeats 'address' and 'balance' but adds little beyond what the schema already says; it also doesn't discuss the network parameter beyond what the schema documents.

  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 and resource: it returns the native token (BERG) balance of an address. It also specifies the output format in wei and formatted, which distinguishes it from related token or address tools.

  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 intended use is implied: call this tool when you need the native token balance for a given address, optionally specifying a network. The description does not mention when to choose alternative siblings such as get_token_info or get_address_transactions.

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

• get_blockA
  3.8/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 the read-like nature with 'fetch' and describes the return structure, including the optional full-transaction behavior. However, it does not mention any potential nuances such as how the 'latest' is resolved, whether cached data may be returned, rate limits, or error behavior for invalid block identifiers. The behavioral transparency is adequate but not detailed.

  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, front-loaded sentence that states the action, identifiers, and return payload with no filler or repetition. It is minimal but informative, earning every word.

  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 a straightforward block-fetch operation with no required parameters and a strong schema. The description accurately summarizes the return types ('header fields and transaction hashes'), which is sufficient for a typical call. A full output schema is absent, but the description gives enough about what to expect. It could improve by noting potential error conditions or the meaning of the default 'latest', but given the simplicity of the tool, it is largely 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%, with detailed descriptions for all three parameters. The description adds some contextual phrasing like 'full transactions if requested', which lightly reinforces the includeTransactions parameter, but it mostly paraphrases the schema rather than adding new semantics. 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 states a specific verb, resource, and scope: 'Fetch a block'. It also names the identifier forms (number, hash, 'latest') and the return content (header fields, transaction hashes or full transactions), which clearly distinguishes this tool from siblings like get_transaction and get_balance. No other sibling fetches a block by these selectors, so it is uniquely identifiable.

  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 makes it clear that this tool is for retrieving a block, which is a sufficient usage context, but it does not explicitly say when to prefer this over alternatives or when not to use it. There is no mention of related tools like get_transaction for individual transaction details, so the differentiation is inferred rather than stated.

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

• get_contract_sourceA
  3.8/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 behavioral burden. It discloses the main edge case: an empty result for an unverified contract. It does not describe error behavior, data-source limitations, or other side effects besides returning source/compiler/ABI data.

  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 sentence with no filler. It front-loads the concrete return contents and immediately follows with the most important uniqueness condition: empty result if not verified.

  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 two-parameter lookup, the description is mostly sufficient: it names the expected artifacts and the key edge case. It would be slightly more complete if it described the return structure or explicitly stated that it does not create or modify data, but the overall behavior is clear.

  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 documents both parameters and has 100% coverage. The description adds no parameter-level nuance beyond saying the output comes from Blockscout, so the by-default 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 names a specific artifact domain: “Verified source code, compiler settings, and ABI of a contract” from Blockscout. This is a clear verb + resource statement and distinguishes the tool from general account or contract-metadata lookups. The empty-result note further defines what the tool returns.

  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: when someone needs verified contract source code or compile settings from Blockscout. However, it does not explicitly contrast it with alternatives, state when not to use it, or mention any conditions beyond the unverified-contract empty case.

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

• get_network_infoA
  3.8/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 of contextual disposition. The verbs 'Overview' and 'lists' imply a read-only operation, but there is no explicit statement that no side effects occur or that no authentication or rate considerations apply. The description is adequate but underest-ulaed in disclosing edge behaviors.

  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—two sentences—and each adds useful info: the first lists the network fields returned; the second notes it also enumerates all known networks. No irrelevant details or fluff are present.

  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 info-generation with no required params and no output schema, the description lists enough return contents (chain id, latest block, gas, client version, endpoints, all networks) to convey the output. It does not specify error behavior or a formal return shape, which are not needed and lightly interrupts completeness.

  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 fully documents the only parameter, including enum values and default, so the baseline is 3. The tool description adds no additional meaning beyond what the schema already states about the network parameter. This is acceptable because the schema coverage is high.

  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 returns a network overview with specific fields: chain id, latest block number, gas price, node client version, and public endpoints. It also adds the all-networks behavior. However, it does not start with an explicit verb; the phrase 'Overview of a...' is more noun-like than a direct command such as 'Get the network.' This keeps it just short of a top-score.

  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 clear context that this tool is for network metadata rather than blob or transaction information, and the listed fields make the intended use obvious. It does not explicitly direct the agent to alternatives when off cases arise, so it falls slightly short of full usage guidance.

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

• get_token_infoA
  3.9/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 disclose burden. It tells the agent exactly what kind of data is returned and the supported token standards, which is strong transparency for a read-only metadata getter. It could add explicit error/unsupported-contract behavior, but nothing about the description misleads about 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?

  A single precise sentence contains the resource, standards, output fields, and data source with no filler. Its information is front-loaded: the main subject appears first.

  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 simple token-metadata lookup, the description plus fully documented schema covers every required input and key output fields. No output schema exists, but the description itself enumerates the metadata returned, so the definition is contextually self-sufficient.

  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 the schema already documents that address is required and network has l1/l2-testnet enum with l1 as default. The description does not need to add parameter details, so it starts at the baseline 3.

  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 names the resource (ERC-20/721/1155 token contract) and the metadata fields returned (name, symbol, decimals, supply, type). It is specific and distinguishes its purpose from sibling transaction/balance/contract-read tools, but does not explicitly name an alternative.

  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 use case is clearly implied: use this when token metadata is needed from Blockscout. Yet the description does not explicitly state when to prefer this over read_contract, get_balance, or related sibling tools, so guidance remains implicit rather than direct.

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

• get_address_transactionsA
  4/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral burden. It discloses that results are newest-first and paginated, while making the read-only nature clear. It doesn't mention error cases or rate limits, but for a straightforward read/list tool, the key behavioral traits are 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?

  Two compact sentences state the resource, ordering, and persistence/modality in a front-loaded way. There is no repetitive restatement of the tool name or unrelated details.

  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 input schema is fully documented and the resource is clearly stated; an agent can select and invoke this tool with confidence. The only weakness is that the description does not confirm the shape of the returned transaction objects, which is typically useful because there is no 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%, and each parameter has a clear textual description in the JSON Schema (address, page, pageSize, network). The tool description adds no unique parameter-level meaning, but with full schema coverage the description does not need to compensate.

  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 definition clearly identifies the resource being accessed (transaction history of an address), the source system (Blockscout explorer), and the ordering (newest first). This is easily distinguished from the sibling get_transaction, which targets a single transaction rather than an address's history.

  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 use when an address's transaction history is needed, and 'Paginated' hints at paging through multiple results. However, it doesn't explicitly contrast with sibling tools such as get_transaction or state when this tool is not appropriate, so guidance is mainly implicit rather than explicit.

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

• get_transactionA
  4/5.0
  Behavior4/5

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

  There are no annotations, so the description carries the burden of behavior. It clearly indicates a read-only fetch and adds useful knowledge about the return, namely that the receipt contains status, gas used, and logs. It stops short of describing error behavior, but mutation risk is absent and the main behavior is disclosed.

  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?

  It is two short sentences with no filler: the first defines what the tool does and the second adds a concise but meaningful feature of the receipt. Every word contributes.

  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 small read-only tool with only two parameters and no output schema, this description gives enough about the transaction plus a valuable receipt detail. It does not delve into selection between siblings or network errors, but the calling context is sufficiently sketched by the schema and the one-sentence purpose.

  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 coveres 100% of the parameters with descriptions, including the hash format and network enum with defaults. The description only restates 'by hash,' adding no meaningful parameter semantics beyond what the schema already provides.

  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 starts with a specific verb 'fetch' and names the exact resource ('a transaction and its receipt') plus the lookup key ('by hash'). This distinguishes it from sibling tools like get_block and get_address_transactions without opening their schemas.

  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 tool is for calls where a transaction hash is already known, but it doesn't explicitly contrast it with get_address_transactions or other retrieval tools. No when-not-to-use conditions or alternative tool names are mentioned.

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

• inspect_certificateA
  4.2/5.0
  Behavior3/5

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

  No annotations exist, so the description carries the portfolio. It discloses important boundaries: 'WITHOUT verifying it' and 'Purely local — no network calls'. However, the claim 'no network calls' sits in tension with the schema's description of the url parameter ('a URL to fetch the certificate JSON from'), which implies a network fetch. This interior contradiction undermines the transparency significantly, and there is no mention of error behavior for malformed certificates.

  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 dense sentences with no fluff. The action lands first, the scope ('WITHOUT verifying it') is flagged immediately, and the sibling embargo closes the description. Every clause 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 tool with two optional parameters and no output schema, the description covers the obvious readiness needs: what it parses, what fields it produces, and when to pick the sibling instead. The only gap is the unresolved URL/'no network calls' contradiction, which leaves the agent uncertain about whether passing a URL triggers a fetch.

  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?

  Both parameters are fully described in the schema (a JSON string for certificate, an alternative URL for fetching), giving high schema description coverage, so baseline 3 applies. The description adds little about the parameters themselves (e.g., conflicts between providing both, which one to prefer, or the URL fetching behavior), so it doesn't exceed the 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 uses a specific verb ('Parse'), names the exact resource (bloxberg Research Object Certificate / W3C Verifiable Credential), and enumerates what it returns (issuer, subject, dates, proof type, anchoring hints). It also immediately draws the distinction from the sibling verify_certificate by saying it does NOT verify, so an agent can differentiate the tool without opening the schema.

  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?

  Explicitly routes to the alternative with the predicate that selects it: 'Use verify_certificate for cryptographic verification against the chain.' The 'Purely local — no network calls' statement also gives the agent contextual expectations for latency and side effects. This satisfies the when-to-use and alternative-guidance bar fully.

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

• read_contractA
  4.4/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the behavioral disclosure burden, and it does identify the operation as read-only and view/pure, which prevents misuse. It also discloses that arguments are coerced by type, which is a useful behavioral detail beyond the schema. It does not mention revert handling or exact return value formatting, but the safety-critical read-only trait is well 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?

  The description is concise and immediately states the tool's purpose in the first sentence. It uses two direct sentences with valuable examples and avoids redundant wording.

  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 description plus the fully documented schema gives an agent everything needed to construct a valid call: address, function signature, string arguments, and network selection. It does not explicitly describe what happens on reverts or how return values are presented, but the core calling pattern is well covered.

  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 schema already describes all parameters at 100% coverage, so the baseline is 3. The description adds value by giving concrete signature examples, clarifying the optional 'function' prefix, and explaining that arguments are provided as strings and coerced by type.

  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 calls a read-only view/pure contract function and explains the function is passed as a human-readable ABI signature. It distinguishes itself from sibling read tools by focusing on arbitrary contract function calls rather than pre-defined operations like balance or token info.

  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 makes it evident that this is for read-only view/pure functions and gives concrete signature examples, which implies when it should be used. It does not explicitly name alternative sibling tools such as get_balance or get_token_info, but the read-only function-call context is clear enough for an agent to make reasonable routing decisions.

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

• verify_certificateA
  4.6/5.0
  Behavior5/5

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

  No annotations are provided, so the description carries the burden, and it does so thoroughly: it enumerates the full verification pathway, states the output is a final verdict plus intermediate steps, and discloses a practical limitation about bare hashesthesheshesheshesheshesheshesheshesheshes, so an agent has a realistic model of behavior.

  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 purposeful sentences: the first front-loads the tool's exact behavior and result, the second adds the most important constraint. The mention of the library name and Blockcerts/W3C context is somewhat detailed but relevant, and there is no fill or repetition.

  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 certificiate verifier with no output schema, the description tells the agent what the output will include, the chain and formats accepted, and the key prerequisite/limitation. Input semantics are already fallly covered by the schema, so nothing essential for correct invocation is missing.

  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%, so the baseline is 3. The description adds meaningful value by explaining that the certificate parameter must carry the full credential document, not merely a hash, and that the alternative `url` serves as a way to fetch that certificate JSON. This goes beyond the raw schema descriptions.

  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 an exact verb and resource: 'Cryptographically verify a bloxberg Research Object Certificate against the blockchain.' It also explains what verification entails and what is returned, so the tool is clearly differentiated from siblings like `inspect_certificate` or generic chain-reading tools.

  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 clear operational guidance by explicitly ruling out bare file hashes and requiring the full credential document, which tells when the tool can be validly used. It does not name sibling alternatives, but the boundary is clear enough for selection.

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