DERO MCP Server

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

Beyond the `readOnlyHint: true` annotation, the description discloses parallel execution, registry joining, null behavior for chain_facts and proof_decode, and error throwing for missing inputs. It fully explains internal logic and output conditions, adding significant behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with a one-sentence summary, followed by targeted usage guidance, structured input requirements, and clear output explanation. Every section serves a distinct purpose without redundancy, earning its length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity and absence of an output schema, the description thoroughly explains the output structure, field conditions (when null), and even advises on how to use returned fields like `related_docs` and `context_note`. It leaves no important aspect undocumented.

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

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

Despite 100% schema coverage, the description adds crucial meaning: it specifies regex patterns, minimum lengths, human-readable formats (e.g., 'deroproof… bech32'), and the conditional behavior of `include_forge_demo` with auto-selection logic. This goes well beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Composite: audit a chain artifact end-to-end' with a specific verb and resource. It distinguishes itself from sibling tools by explicitly mentioning it is a composite that runs multiple calls in parallel and joins against a registry, which sets it apart from individual get_block/get_transaction tools.

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

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

The description provides explicit 'When to call' guidance with example user queries and indicates preference over chaining simpler tools. It also gives detailed conditions for the `include_forge_demo` parameter, including when to set it true, offering clear alternatives and context.

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

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

Annotations already declare readOnlyHint=true, so description's disclosure of output (concatenated string) and input requirement (non-empty array) adds useful context beyond annotations. Lacks error handling details but acceptable for this simple tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Efficiently structured: purpose, usage guidance, input requirements, output. Every sentence adds value with no redundancy. Front-loaded with key info.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Complete for tool complexity. Covers purpose, when-to-use, input constraints, output format, and sibling differentiation. No output schema exists but output is described.

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

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

Despite 100% schema coverage, description adds critical constraint that 'words' must be a non-empty array, which is absent from schema. This prevents common agent errors.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool echos strings via DERO.Echo for round-trip sanity checks. Differentiates from sibling dero_daemon_ping by specifying it's for heavier payload testing.

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

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

Explicitly states when to call (confirm string payload integrity) and when to prefer alternative (use dero_daemon_ping for lighter liveness probe). Provides clear decision guidance.

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

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

Beyond annotations (readOnlyHint, destructiveHint false), the description adds that the tool returns 'Pong' on success and an error with code RPC_UNREACHABLE and retry hint on failure, covering all relevant behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact, using two short paragraphs to convey purpose, usage, input, and output without redundancy. Every sentence serves a clear purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no params, no output schema), the description thoroughly covers all aspects: purpose, when to use, input, output, and error behavior. No gaps remain.

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

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

No parameters exist (0 params, 100% schema coverage), so the description correctly states 'Input Requirements: none.' A score of 4 is appropriate as baseline given zero parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('connectivity check') and resource ('DERO daemon'), and the tool name 'ping' coupled with the description distinguishes it from siblings like 'dero_daemon_echo' which also tests connectivity but presumably with different semantics.

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

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

Explicitly instructs to call as the first step in chain investigations and before get_info if unsure about configuration, providing clear context for when to use this tool versus alternatives.

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

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

Discloses important behavioral details beyond annotations: for deroproof strings the public key is a blinder, surfaces is_proof flag, notes when value_interpretation exists, and mentions error handling. Annotations only indicate read-only.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with front-loaded main action, then when to call, requirements, and output. Somewhat lengthy but every section is informative; could be slightly more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Comprehensive: explains output structure, includes edge case (value_interpretation presence), mentions error handling, and provides a concrete test case. Without output schema, the description fully compensates.

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

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

Schema coverage is 100%, so baseline is 3. The description adds the list of allowed HRPs and case consistency requirement, which provides additional value beyond the schema description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool decodes DERO bech32 strings into components, with a specific verb and resource. It distinguishes from siblings as there is no other decode tool.

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

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

Explicitly states when to call (user pastes a deroproof or integrated-address string) and recommends this over alternatives like chaining decoders. Provides clear guidance and context.

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

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

Annotations indicate readOnlyHint=true and destructiveHint=false, so the tool is a safe read operation. The description adds valuable behavioral context: long pages are chunked at 60k characters, and agents should paginate when content_truncated is true. This goes beyond what annotations provide but does not contradict them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized with three clear sections: purpose, when to call, and input requirements. Every sentence provides essential information without repetition or fluff. Front-loaded with the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of pagination and optional disambiguation via product, the description covers usage flow, input constraints, and output fields (listed out). No output schema exists, but the description enumerates all return fields, making it complete for agent decision-making.

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

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

Schema description coverage is 100% for all three parameters. The description adds meaningful context beyond the schema: slug must be non-empty relative to pages/, product is optional but recommended to disambiguate, and offset usage is explained with pagination details. This helps agents use parameters correctly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Get a single bundled docs page by slug, with plain-text content and headings.' It specifies the resource (docs page), action (get), and output format (plain-text content and headings). Distinct from siblings like dero_docs_search (which returns candidate slugs) and dero_docs_list (which lists pages).

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

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

Explicitly states when to call: 'AFTER dero_docs_search has returned a candidate slug, OR when you have a known slug from a prior citation. PREFER dero_docs_search first when you only have a topic in mind.' Also provides critical input requirements and explains pagination via offset and content_truncated.

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

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

Annotations already indicate read-only and non-destructive behavior. The description adds output schema details (fields returned) and notes default limit/max, providing extra context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (three short paragraphs) and front-loaded with the main purpose. Every sentence adds value, with no redundant or irrelevant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple tool with full schema coverage, the description fully covers behavior, constraints, and output structure. No gaps remain for an agent to invoke correctly.

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

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

Schema coverage is 100%, so the schema already documents both parameters. The description repeats the product enum and limit defaults but adds no new semantic meaning beyond what's in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists indexed docs pages with specific fields (slugs, titles, canonical URLs) across four products, distinguishing it from related tools like dero_docs_search and dero_docs_get_page.

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

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

Explicitly provides when to call (surveying docs, needing slug catalog for get_page) and when to prefer alternative (search for specific question), naming dero_docs_search directly.

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

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

Adds behavioral context beyond annotations: states 'In-process — no network round trip' indicating performance characteristics. Annotations already mark readOnlyHint=true and destructiveHint=false; description reinforces safety and adds detail on output format (ranked matches with fields). No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with sections (when to call, input requirements, output), but slightly lengthy. However, every sentence serves a purpose and adds value. Could be more concise but still effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a search tool with 4 parameters and no output schema, the description is thorough: covers purpose, usage, input requirements with examples, and output fields. The lack of output schema is compensated by listing return fields (title, slug, etc.). No gaps.

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

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

With 100% schema coverage, baseline is 3, but description significantly enhances each parameter: provides examples for query, explains when to use product filter to reduce noise, clarifies section as slug prefix, and states limit default and max. All parameter meaning is fully elaborated.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool searches the bundled DERO documentation index across four products (145+ pages), distinguishing it from sibling tools like dero_docs_get_page (single page retrieval) and dero_docs_list (listing). The verb 'search' and resource 'documentation index' are specific and unambiguous.

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

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

Provides explicit when-to-call guidance: before answering DERO questions or constructing citations, and before explaining specific topics. It also tells when to prefer returning canonical_url and slug as citations. This clearly distinguishes from alternatives.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds significant behavioral context: first call triggers a ~10s one-time discovery scan (cached), dURLs are not unique and the newest is returned with collision flag, and other candidates are disclosed. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (purpose, when to call, input requirements, output). Every sentence adds value; no fluff. It is detailed yet efficient, front-loading the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (composite, caching, collision handling, multiple contracts), the description covers all necessary context: behavior on first call, collision resolution, output shape, and integration with sibling tool tela_inspect. No output schema is present, but the description compensates fully.

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

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

Schema coverage is 100% and the parameter description is present, so baseline is 3. The description adds extra semantic value: case- and prefix-insensitivity, examples, and the distinction from DERO names. This goes beyond what the schema alone provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool resolves a TELA dURL to its on-chain SCID(s). It explicitly distinguishes from sibling 'dero_name_to_address' by noting that for DERO names (no dot), that tool should be used instead. The verb 'resolve' and resource 'TELA dURL' are specific and unambiguous.

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

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

Provides explicit when-to-call scenarios ('when a user asks...'), an important routing note distinguishing from DERO name lookup, and input requirements. It also explains output format and behavior on hit and miss, giving clear guidance on when to use this tool.

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

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

The description elaborates on behavior beyond annotations: it confirms read-only nature, explains local construction, self-verification, and error behavior (throws on self-check failure). It also describes output format and side effects (no chain mutation).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections but is moderately lengthy. It earns its length by covering both high-level purpose and detailed technical instructions without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description fully covers input, output, behavior, and use cases. It references related documentation, explains the math, and provides diagnostic fields. No output schema exists, so the detailed output description compensates effectively.

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

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

Despite 100% schema coverage, the description adds crucial semantics: explains mutual exclusivity of tx_hash/tx_hex, default values, negative amount wraparound effect, and range constraints. This significantly aids understanding and correct invocation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool forges a deroproof display object for any transaction, ring slot, and amount. It explicitly distinguishes itself by focusing on forging rather than decoding or other operations, and the purpose is immediately clear from the first sentence.

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

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

The description provides a specific 'When to call' section with a concrete use case (refuting 'Verified ✓' claims) and additional context for reproducing demonstrations. It lacks explicit 'when not to call' guidance but still offers strong directional advice.

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

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

Annotations declare readOnlyHint=true, and the description adds behavioral details: returns full block with specific fields, requires exactly one parameter, and describes error behavior for invalid input. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with a clear first sentence stating purpose, followed by usage guidelines and bulleted input requirements. Every sentence adds value and there is no redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (2 parameters, no output schema), the description covers purpose, usage guidelines, parameter constraints, and output fields. It also directs users to documentation for field semantics, making it complete for effective use.

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

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

Schema coverage is 100% with pattern and minimum constraints. The description adds critical usage constraints: 'MUST provide exactly ONE of hash or height', 'hash MUST be exactly 64 hex characters', 'height MUST be non-negative integer'. This provides clearer semantics beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description explicitly states 'Fetch a full block (header + miner_tx + transactions + topo position) by height OR hash'. The verb is specific ('Fetch') and the resource is clearly defined as a full block, distinguishing it from sibling tools like dero_get_block_header_by_hash which return only headers.

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

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

Contains an explicit 'When to call' section advising to investigate specific blocks or verify transaction inclusion. Recommends calling dero_get_height first if no target height is known, and suggests using dero_docs_search for field semantics. Also provides critical input requirements (exactly one of hash/height).

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

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

The description discloses that the tool returns a tip count (not topoheight) and the output format. Annotations already indicate readOnlyHint=true, so no contradiction. It adds behavioral context beyond annotations but could mention it's a safe read operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with 5 short sentences, each serving a purpose: definition, distinguishing info, usage guidance, input clarity, and output format. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with no parameters and no output schema, the description provides all necessary context: what it returns, how it differs from a sibling, and when to use it. It is fully complete.

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

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

With zero parameters and 100% schema coverage, the description adds value by stating 'Input Requirements: none,' confirming no inputs needed. This is clear and helpful, earning a baseline 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Get the total block count' with a specific verb and resource, and distinguishes itself from the related sibling dero_get_height by indicating that it returns a tip count, not a topoheight. This provides clear differentiation.

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

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

The description explicitly provides when to call ('when you need just the block count') and when not to ('PREFER dero_get_height when you need tip and stable heights together'), offering a direct alternative sibling.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds critical input constraints (hash must be exactly 64 hex chars) and output shape ({ block_header: {...} }). This provides contextual behavior beyond annotations without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with no wasted words. It front-loads the core functionality in the first sentence and then provides targeted usage guidance and input requirements. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter, no output schema, and clear annotations, the description fully covers purpose, usage context, input constraints, and output shape. No gaps remain for agent decision-making.

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

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

Schema coverage is 100% with pattern and description. The description reinforces the exact length requirement ('MUST be exactly 64 hex characters') but does not add new semantic meaning beyond the schema. Baseline 3 is appropriate for high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Get a block header by its 64-char hex hash' and distinguishes from dero_get_block which includes transactions. The verb 'Get' and resource 'block header' are specific, and the differentiation from sibling tools is explicit.

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

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

Provides explicit when-to-use: 'when you have a block hash and need its header without the full block body,' and when-not: 'PREFER dero_get_block when you also need the txs or miner_tx.' This directly guides agent decision-making.

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

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

Annotations already indicate read-only and non-destructive behavior. The description adds that the output contains a block_header object with specific fields, and that topoheight must be within current range. No contradictions, but doesn't mention error behavior or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Very concise: three short paragraphs covering purpose, usage, and output. Every sentence adds value. No redundancy or extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description includes the output structure. It also suggests a prerequisite call (dero_get_info). Slightly incomplete in not explaining error states, but adequate for a simple read endpoint with annotations.

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

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

The description adds critical constraints to the 'topoheight' parameter that go beyond the schema: it must be non-negative and not exceed current topoheight. This provides semantic meaning that helps the agent form valid requests.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves a block header using topological height, distinguishing it from other methods like block header by hash. It explains the difference between topoheight and consensus height, making the purpose unmistakable.

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

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

Explicit guidance on when to call (need header by topo position) and critical input requirements (topoheight must be non-negative and no greater than current topoheight). Suggests calling dero_get_info first for safety, and provides output format.

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

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

Annotations already declare readOnlyHint=true; description adds critical detail that it does NOT submit a block, citing the excluded method. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise, front-loaded purpose, then usage guidelines, then input requirements. Every sentence adds value; no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers all critical aspects: when to call, parameter requirements, behavior (no submission), and output description despite lacking output schema. Sufficient for correct invocation.

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

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

Schema coverage is 100% (baseline 3). Description adds concrete format requirements for wallet_address and optional semantics for block/miner, exceeding schema detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it gets a mining block template for a payout address, distinguishing from sibling dero_get_last_block_header for general chain-tip inspection.

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

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

Explicit guidance: 'ONLY when you are actually mining' and 'PREFER dero_get_last_block_header for general chain-tip inspection.'

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds critical behavioral context: the output is an opaque encrypted blob that only the wallet holder can decrypt. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with sections, critical warnings, input requirements, and output summary. Every sentence adds value; no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description summarizes the output structure. It covers all aspects: purpose, when to call, parameter requirements, behavioral caveats, and output shape. For a tool with 3 parameters and clear semantics, this is fully adequate.

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

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

All three parameters have schema descriptions (100% coverage). The description reinforces critical formats: address must start with dero1/deto1, topoheight -1 for latest, scid optional. This adds meaning beyond the schema, though schema already describes patterns.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool gets the ENCRYPTED balance blob for a DERO address at a topo height via DERO.GetEncryptedBalance. It emphasizes that the output is not a cleartext balance, distinguishing it from balance-related tools. The verb 'get' and resource 'encrypted balance blob' are specific.

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

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

The description explicitly states when to call: for verifying on-chain encrypted state or as a sub-step. It also advises against presenting the encrypted bytes as a balance and prefers citing dero_docs_search. This provides clear usage boundaries and alternatives.

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

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

Annotations indicate readOnlyHint=true, and the description reinforces this by stating 'PRE-FLIGHT check; nothing is submitted.' It adds context about compute vs storage gas and output format, which goes beyond 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections, front-loading the purpose. It is not overly verbose, though it could be slightly more concise. No wasted sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of an output schema, the description provides the output format. It covers input requirements, purpose, and usage context. The annotations and schema are well complemented.

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

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

Schema coverage is 100%, but the description adds critical constraint: 'At least ONE of transfers, sc, or sc_rpc MUST be provided.' It also explains sc, sc_rpc, and signer in more detail, adding meaning beyond the schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool estimates gas for transfers, SC deploys, or SC invokes, using the verb 'Estimate' and specifying the resource. However, it does not explicitly differentiate from the sibling tool 'estimate_deploy_cost', which may have overlapping functionality.

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

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

Explicit guidelines for when to call: 'BEFORE any wallet-side transfer/scinvoke' and 'when explaining deploy costs to a user.' It also advises preferring dero_docs_search for understanding fee structure, providing clear when-not-to-use guidance and an alternative.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it's safe. The description adds that it's a 'quick' snapshot and specifies the output fields, providing useful but not critical context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four concise sentences with no fluff: purpose, usage guidance, input requirements, and output format. Highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and a simple output, the description fully covers what the tool does, how to use it, and what to expect. It even references the sibling tool. No major gaps.

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

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

No parameters exist, and the description states 'Input Requirements: none', which is clear. Schema coverage is 100% so no additional information is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it retrieves current block heights (tip, stable, topoheight) via DERO.GetHeight. It uses a specific verb 'get' and resource 'block heights', and distinguishes itself from the sibling 'dero_get_info' which provides more data.

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

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

Explicitly tells when to call ('when you need a quick height snapshot without the full chain-info payload') and when not to ('PREFER dero_get_info when you also need network, version, or difficulty'). This is excellent guidance with alternative naming.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds value by specifying the output fields and confirming no input requirements. It does not contradict annotations and provides additional context about the tool's behavior beyond the structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (about 6 sentences) and well-structured with clear sections: purpose, when to call, input, output. Every sentence adds useful information without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters and no output schema, the description fully covers the output fields and usage context. It includes guidance on when to use and what data to expect, making it complete for an agent to invoke correctly.

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

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

The tool has zero parameters, and schema coverage is 100%. The description states 'Input Requirements: none,' which is sufficient. No additional parameter documentation is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns DERO daemon and chain metadata, listing specific fields (height, topoheight, etc.), which distinguishes it from siblings that operate on blocks, transactions, or smart contracts.

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

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

Explicitly says when to call: 'first thing in any chain-state investigation or sync-health check' and instructs to call before other chain-related tools like dero_get_sc, dero_get_transaction, or dero_get_block. Also suggests citing dero_docs_search for verification, providing clear guidance on usage context and alternatives.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds value by specifying the scope (block header only) and output fields (hash, height, etc.), which is clear and non-contradictory.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with clear sections (purpose, when to call, input, output). Each sentence adds value, no superfluous content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no required inputs and no output schema, the description provides a representative output snippet and covers all relevant context for a simple read-only tool.

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

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

No parameters exist, and the description explicitly states 'Input Requirements: none'. Since schema coverage is 100%, and the description adds no redundant info, baseline 4 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states it retrieves the header of the current tip block via DERO.GetLastBlockHeader and clearly distinguishes it from dero_get_block by noting it returns no full block body.

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

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

Provides explicit guidance: 'When to call' describes scenarios for tip block metadata without transactions, and recommends dero_get_block when transactions are needed, differentiating from a sibling tool.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the description does not need to restate safety. However, it adds useful context about the random nature of the result and its use in ring construction, which goes beyond annotations. No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with no wasted words. It is well-structured: purpose, when to call, input requirements, and output format, all in a few clear sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description specifies the output format as '{ address: string[] }'. It covers purpose, usage context, input requirements, and return value, making it fully informative for a single-optional-parameter tool.

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

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

Schema coverage is 100% with the 'scid' parameter fully described via pattern and description in the input schema. The description redundantly states it is optional and must be 64 hex characters, adding no new meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves random registered addresses from the chain, used for ring construction in private transfers. This is specific and distinct from sibling tools like dero_get_block, dero_get_height, etc., 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.

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

The description explicitly provides when to call: when building a transfer ring in external wallet tooling or sampling chain participants. It also explains how the optional scid parameter limits sampling to holders of a specific asset, giving clear contextual guidance.

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

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

Annotations indicate readOnlyHint=true. Description adds behavioral details: critical input requirements (scid format), optional parameters and their defaults, and output shape. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured: high-level purpose, when to call, critical input requirements, output shape. Each sentence serves a purpose; no fluff. Front-loaded with key information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Comprehensive for a read-only contract inspection tool: covers purpose, usage guidance, parameter details, output format, and follow-up actions. No output schema, but description provides enough context.

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

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

Schema coverage is 100%, but description adds meaning: explains defaults and usage for 'code' and 'variables' (e.g., 'Set false to skip the source blob when you only need stored variables'), and clarifies topoheight usage. Adds value beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Read smart contract state (code and/or stored variables) by SCID via DERO.GetSC.' Identifies itself as 'the primary entry point for any contract inspection on DERO,' distinguishing it from siblings like 'explain_smart_contract' which likely interpret the state.

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

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

Explicitly says 'When to call: as the first step in any DVM contract investigation.' Advises pairing with dero_docs_search and prefers citing docs for interpretation, giving clear context and alternatives.

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

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

The description discloses behavioral traits beyond annotations: it returns transaction data with confirmation status and block hash, optionally decodes JSON. It also provides critical input requirements and output format, ensuring the agent knows what to expect and how to invoke it safely.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured, with clear sections for purpose, when to call, input requirements, and output. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of fetching transactions and the lack of an output schema, the description provides a full output structure ({ txs: [...], txs_as_hex: [...] } with per-tx fields). It also covers input validation, optional parameter, and cross-tool references, making it complete.

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

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

The schema coverage is 100%, but the description adds extra guidance: for 'txs_hashes', it explicitly states 'MUST be a non-empty array of 64-char hex strings', and for 'decode_as_json', it recommends preferring a non-zero value for JSON decoding. This adds practical usage context beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool fetches transactions by hash and specifies what is returned (confirmation status, block hash, optionally decoded JSON). It differentiates itself from sibling tools like dero_get_tx_pool and dero_get_sc by explicitly mentioning when to use and what to pair with.

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

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

The description explicitly says 'When to call: when tracing a tx by hash' and recommends pairing with dero_get_sc for contract invocations. It also suggests using dero_docs_search to interpret fields, providing clear guidance on when and how to use the tool.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral detail about possible null/empty tx_hashes, but doesn't disclose other traits like rate limits or pagination, which are not needed for this simple tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise: three short paragraphs covering purpose, when to call, input/output. Every sentence adds value. Front-loaded with the core action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters, existing annotations, and no output schema, the description fully covers the tool's behavior, output format, and edge cases. Nothing missing.

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

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

No parameters exist, so baseline is 4. The description correctly notes 'Input Requirements: none' and schema coverage is 100% (vacuous). No further parameter info needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List pending mempool transaction hashes' using a specific verb and resource, distinguishing it from sibling tools that deal with blocks, transactions, or other data.

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

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

Provides explicit when-to-use scenarios: 'when checking unconfirmed activity, watching for a specific tx to land, or estimating mempool pressure.' Also explains how to handle null/empty response.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral details beyond annotations, such as case-sensitivity, output format { name, address }, and error handling for NOT_FOUND. This provides valuable context without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured in three paragraphs: purpose, usage guidelines, and input/output details. It is concise with no wasteful sentences, and the most critical information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (2 parameters, no output schema, and annotations present), the description covers all necessary aspects: when to use, input requirements, output shape, and error handling. It is complete and provides sufficient context for correct invocation.

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

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

Schema coverage is 100% with both parameters described. The description adds meaning beyond the schema by specifying that 'name' must be non-empty (though schema already has minLength:1), noting case-sensitivity, and clarifying that topoheight uses -1 for latest. This enhances the schema's information.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it resolves a DERO on-chain registered name to its address, using a specific verb and resource. It distinguishes this tool from siblings by focusing on name resolution, which is unique among the listed tools.

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

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

Explicitly says 'When to call: when a user supplies a human-readable name instead of a dero1.../deto1... address.' This provides clear context for when the tool should be used, effectively guiding the agent away from alternatives.

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

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

Annotations already indicate read-only operation. The description adds important behavioral context: first call triggers a ~10s scan that is cached, and index_meta reveals coverage transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with clear sections: summary, when-to-call, input requirements, output. Every sentence adds value, though slightly verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, description adequately explains return fields and important behavior (scan delay, caching, coverage). Could mention more about narrative structure.

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

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

Schema coverage is 100%, so baseline is 3. The description adds examples for query but does not add significant meaning beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists/browses TELA apps discovered on-chain, with specific fields. It distinguishes from sibling tools like dero_durl_to_scid and tela_inspect.

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

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

The 'When to call' section explicitly provides usage scenarios and directs when to use alternatives, e.g., for exact dURL use dero_durl_to_scid.

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

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

Annotations already indicate readOnly and non-destructive. The description adds significant detail: handles partial-failure modes, lag-depth classification, and cites docs. Also describes output structure and error handling. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: purpose, when to use, input requirements, output summary. Every sentence adds value without redundancy. Efficient use of words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having no output schema, the description fully explains the output structure, status enum, null cases for chain and mempool, and error format. Comprehensive for a complex composite tool.

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

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

Schema coverage is 100% with a single boolean parameter. The description adds context on when to set include_tx_pool to false (for chain-tip only), which is helpful beyond the schema's description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states it runs a four-step chain and returns a single narrative health report. It clearly distinguishes from sibling tools by specifying it composites multiple primitives (DERO.Ping, DERO.GetInfo, etc.) and provides a coherent output.

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

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

Explicitly says 'When to call: as the first step in any chain-state investigation' and advises to prefer this composite over chaining primitives. Provides clear context and alternatives.

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

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

Beyond annotations (readOnlyHint=true), the description discloses that it is a composite tool, uses 'extractScSurface' from another tool, and protects against fabricating a breakdown when the daemon returns 0/0 with non-OK status. It also details error handling with structured errors and codes. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a first-sentence purpose, then usage, input, and output sections. It is thorough but slightly verbose; every sentence adds value, but it could be tightened marginally.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (composite, no output schema), the description fully compensates by detailing the output structure, breakdown conditions, error handling, and source parsing. It covers all necessary context for correct usage.

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

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

Although the schema covers all three parameters (100% coverage), the description adds crucial context: 'sc must contain at least one Function ... End Function block', 'signer is OPTIONAL with address format', and 'include_breakdown defaults true'. It also explains the output structure, which is missing from the input schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with 'Composite: send a DVM-BASIC contract source to the daemon's gas estimator, then return...', clearly stating the verb (estimate, send, return) and resource (deploy cost, gas estimate). It distinguishes from sibling 'dero_get_gas_estimate' by explicitly preferring this composite tool.

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

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

The description provides explicit when-to-call scenarios: 'BEFORE asking a wallet to broadcast a deploy transaction, OR when explaining the cost of a contract to a user.' It also advises preferring this over chaining 'dero_get_gas_estimate' and explains benefits like plain-language breakdown and protection against fabricated results.

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

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

Annotations declare readOnlyHint=true and destructiveHint=false, so safety is clear. The description adds behavioral details: it parses DVM-BASIC source for function declarations, sorts stringkeys/uint64keys deterministically, picks the right docs page via heuristic, and returns a classification. It also explains that has_code=false indicates unknown SCID and raw_code_length is always present. This goes beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded: first the composite output, then when-to-call, then input requirements, then output details. Every sentence adds value, no redundancy. Appropriate length for the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Without an output schema, the description fully explains the output structure: fields like scid, topoheight, kind, surface (with subfields functions, stringkeys, uint64keys, balances), narrative, raw_code_length, has_code, related_docs. It covers special cases like when has_code is false. This is complete for a tool of this complexity.

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

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

Schema coverage is 100% with both parameters described (pattern and optional). The description reiterates the pattern and adds a known-good example, but adds no new semantic meaning beyond the schema. Given high coverage, baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it is a composite tool that fetches a DERO smart contract and returns a function surface, classification, narrative, and curated docs citations. It distinguishes itself from siblings like dero_get_sc (raw code) and tela_inspect (deep TELA parse). The purpose is specific: to help the user understand a smart contract.

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

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

Explicit instructions: 'PREFER this over chaining dero_get_sc with a docs lookup yourself' and 'When to call: when the user wants to UNDERSTAND a smart contract'. Input requirements provide a known-good example (0000...0001) and specify optional topoheight. Also mentions fallback: use dero_get_sc when has_code is false.

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

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

Discloses behavioral traits: composite operation, fan-out parallelism, 1.5x boost for product_hint, deduplication, and structured output including error handling. Annotations already declare readOnlyHint=true, and the description adds complementary detail without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with headings for 'When to call', 'Input Requirements', and output format. Slightly verbose but every sentence adds useful information. Could be trimmed slightly, but effectively front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, but the description thoroughly details the output structure including recommended array, by_product summary, and related_docs citations, as well as error case. For a composite tool with 3 parameters, this is comprehensive.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining intent should drop verbs and use product nouns, product_hint multiplies scores by 1.5×, and limit_per_product defaults to 2 with max 5. This goes beyond the schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it is a composite tool that takes a natural-language intent, fans out searches across four DERO products, boosts product_hint matches, and returns a ranked recommendation list with rationale and related_docs. It explicitly distinguishes itself from sibling tool dero_docs_search by stating when to call it.

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

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

Provides explicit guidance: 'When to call: at the START of any 'where do I read about X?' investigation, BEFORE calling dero_docs_search directly.' Also advises to prefer this over guessing the right product and gives input requirements with best practices (e.g., 'drop verbs and use product nouns').

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

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

Annotations indicate readOnlyHint=true, but description adds critical details: gzip decompression, pagination, output fields, and that files are stored in DVM-BASIC comments. No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with purpose, mechanism, usage, inputs, output. Each sentence adds value. Front-loaded and appropriate length for a complex tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Comprehensive: explains file extraction from contract, gzip handling, pagination, output fields, error cases, and prerequisite tela_inspect. No output schema, but description covers return values.

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

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

Schema coverage is 100%, but description adds context: scid must be TELA-DOC-1, offset for pagination with next_offset, topoheight for state. Input requirements section adds clarity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'fetch the actual file content stored in a TELA-DOC-1 contract' and explains the mechanism (file inside DVM-BASIC comment). Distinguishes from dero_get_sc by specifying it extracts embedded content.

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

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

Explicitly says when to call (user wants to read TELA app markup), provides examples, and recommends over dero_get_sc. Also gives prerequisites and error handling guidance.

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

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

The description discloses key behavioral traits beyond the readOnlyHint annotation: it reads raw stringkeys, enumerates all DOC references, decodes TELA header/mods/commit schema, and honestly reports updateability as 'unknown' due to chain state limitations. The output is described in detail as a discriminated union, adding transparency about error handling (returning 'not_tela' kind). No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections: purpose, when to call, input requirements, output details. It is slightly lengthy but every part adds value. Front-loading the composite nature and auto-detection is helpful. Could be more concise, but it's still effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity and the absence of an output schema, the description is remarkably complete. It covers input constraints, output structure for all three kinds (tela_index, tela_doc, not_tela), behavioral details, and limitations. No gaps remain for an agent to successfully invoke and interpret results.

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

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

Schema coverage is 100%, so the description's param info adds limited value beyond the schema. However, it reinforces that scid is required and must be 64 hex chars, and explains that topoheight is optional for inspecting at a specific state. The output description also indirectly clarifies the purpose of the parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly defines the tool's purpose: fetching a TELA contract by SCID and parsing it as either an INDEX or DOC, auto-detecting the type. It also explains what TELA is, making the context clear. It distinguishes from siblings like explain_smart_contract and dero_get_sc, explicitly stating that this tool is preferred.

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

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

The description provides explicit guidance on when to call: 'as the FIRST step whenever a user references a TELA SCID, a .tela dURL app, or asks what is this TELA contract/app'. It also explains when not to use alternatives, detailing why explain_smart_contract is inadequate for TELA contracts. This gives clear context and exclusions.

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

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

Adds significant behavioral context beyond annotations: failure mode handling (TX_NOT_FOUND), classification of status and kind, inline extraction of SC surface, and clear limitation about arg decoding. Annotations only provide readOnlyHint and destructiveHint, so description adds value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with clear sections but slightly verbose. Every sentence adds value, but some details (e.g., raw_tx_hex_length purpose) could be integrated. Front-loaded with main purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Comprehensive: explains output structure, error handling, limitations, and alternatives. No output schema, but the description fully compensates. Given complexity and annotations, it is complete.

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

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

Schema coverage is 100% and the description further clarifies each parameter: tx_hash is required 64 hex, decode optional with default true, include_sc_context optional with default true and explanation of effect. Adds meaning beyond schema by explaining purpose and defaults.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it is a composite tool that looks up a DERO transaction, classifies confirmation status and kind, extracts SC surface for contract installs, and provides citations. It distinguishes from sibling tools like dero_get_transaction and dero_get_sc by noting that the composite already extracts inline data.

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

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

Explicitly states when to call: first step for any tx-by-hash investigation. Prefers this over chaining dero_get_transaction and dero_get_sc. Also specifies when not to use it: for SC invocation arg decoding, which is not performed.

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

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

The description discloses read-only behavior, error conditions (RPC_UNREACHABLE/INVALID_INPUT), and scope limitations (schedule CalcSupply only, not UTXO census). Annotations confirm readOnlyHint and non-destructive, and the description adds valuable context beyond those annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (summary, when to call, input requirements, output). It is moderately concise; some repetition could be trimmed but remains efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description fully documents output fields, match logic, and scope. It covers error scenarios and provides a complete contextual picture for a composite tool of this complexity.

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

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

Schema coverage is 100% and the schema already provides detailed description for the single parameter (default, required when daemon unreachable). The tool description reiterates this but does not add new semantic meaning beyond what the schema already conveys.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it is a composite tool to recompute DERO total supply via CalcSupply and optionally cross-check with GetInfo. It distinguishes from siblings like dero_get_info by emphasizing independent verification.

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

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

It explicitly says 'When to call' with specific user queries and prefers this over reading GetInfo alone. It also provides input requirements, including when height is mandatory (daemon unreachable), guiding appropriate use.

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