DERO MCP Server

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

Beyond annotations, the description explains that calls run in parallel, join against a false-claim registry, and return a unified verdict. It also describes fallback behavior: chain_facts is null on failure, proof_decode null without proof_string, forge_demo null unless include_forge_demo true. No contradiction with readOnlyHint.

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 long but well-structured with sections, front-loading purpose and usage. Every sentence adds value, though some details could be streamlined slightly. It earns a 4 for being thorough without being excessively 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?

Despite having no output schema, the description fully documents all output fields, their null conditions, and how to use related_docs and context_note. It covers error states and provides comprehensive guidance 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?

The description adds precise format constraints (e.g., '64 hex characters' for tx_hash and block_hash, 'deroproof…' for proof_string) and auto-selection logic for include_forge_demo. Schema coverage is 100%, but description still adds significant meaning.

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 that audits a chain artifact end-to-end, returns a verdict, on-chain facts, proof decode, narrative, and citations. It distinguishes from siblings by explicitly recommending this over chaining individual RPC calls like dero_get_block_header_by_topo_height + dero_get_transaction + dero_decode_proof_string.

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 lists 'When to call' scenarios (e.g., 'what's going on with DERO block X?') and provides a strong preference statement. It also details input requirements, including the critical 'at least one of four parameters' rule and conditions for include_forge_demo.

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. Description adds that it echoes and concatenates strings, which is transparent. 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?

Very concise: one sentence for purpose, one for when to call, one for input requirement, one for output. No wasted words, front-loaded with most important 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?

For a simple echo tool with one parameter and no output schema, the description fully covers purpose, usage context, input constraints, and output. 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?

Schema coverage is 100% for the single parameter 'words', so baseline is 3. Description adds critical constraint: 'MUST be a non-empty array of strings', which goes beyond the schema's type and 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?

Clearly states it echoes strings through the daemon for round-trip sanity checks. Distinguishes from sibling dero_daemon_ping by noting it is for string payloads, while ping is a lighter-weight liveness probe.

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 (confirm string payload reach daemon, before debugging malformed calls) and when not to (prefer dero_daemon_ping for lighter liveness check). Provides clear 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 readOnlyHint=true and destructiveHint=false. The description adds value by detailing the output ('Pong' string on success) and failure behavior (structured error with code RPC_UNREACHABLE and retry hint), providing useful behavioral 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 and well-structured, with a first sentence stating the purpose, followed by usage guidance, input requirements, and output description. Every sentence is information-dense and earns its place.

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 ping tool with no output schema, the description fully covers inputs (none), outputs ('Pong' or structured error), and failure behavior. It is complete for its complexity and 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?

There are no parameters (input schema is empty) and schema description coverage is 100%. The description states 'Input Requirements: none', which is clear but adds no additional meaning beyond the schema. Baseline score 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 the tool performs a DERo daemon connectivity check via DERO.Ping, with a specific verb and resource. It distinguishes usage from siblings like dero_get_info by recommending it as the first step in any chain investigation.

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: 'as the first step in any chain investigation' and before dero_get_info. It also states input requirements are none. While it doesn't cover all sibling alternatives, it gives clear context for primary usage.

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: that for deroproof... strings the public key is a blinder point (not a wallet pubkey), that value_interpretation is conditionally present, and that the decoder is verified against a specific proof string. Annotations already indicate readOnlyHint=true, so the description adds meaningful 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 with sections for purpose, when to call, input requirements, and output. However, it is quite verbose, including detailed output examples and recommendations for citing documents. While informative, some redundancy could be trimmed for conciseness.

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 thoroughly covers output structure, conditional fields, error handling, and special cases. It also references related documents. The tool is complex (bech32, CBOR, proof interpretation), and the description leaves 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?

Schema description coverage is 100%, so baseline is 3. The description adds meaningful constraints beyond the schema, such as requiring case consistency (all lower or all upper per BIP-0173) and providing an example input. This elevates the score to 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 the tool decodes DERO bech32 strings (dero..., deto..., etc.) into HRP, network, public key, and CBOR arguments. It distinguishes itself from siblings by being the dedicated decoder for these specific string types, with no sibling tool offering similar 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?

The description provides explicit 'when to call' guidance: when the user pastes a deroproof... or integrated-address string and wants to decode it. It also recommends using this tool over manual chaining of libraries. However, it does not explicitly state when not to call the tool, though the context implies it is only for DERO bech32 strings.

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, idempotentHint=false, destructiveHint=false. The description adds behavioral context beyond annotations, such as pagination via 60000-char chunks and signaling via content_truncated. This is useful but not extraordinary.

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 fairly long but well-structured with clear sections. It could be slightly more concise, but it is organized and informative.

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 3 parameters, no output schema, the description covers all output fields, pagination, and input constraints thoroughly. It is complete for an agent to use 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?

Schema description coverage is 100%, but the description adds details like slug must be non-empty relative to pages/, product is recommended for disambiguation, and offset is explained with chunking. This adds 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 it gets a single bundled docs page by slug, returning plain-text content and headings. It distinguishes from siblings like dero_docs_search (search) and dero_docs_list (list).

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: AFTER dero_docs_search returns a candidate slug, or when you have a known slug. It recommends preferring search first when only a topic is known. It provides critical input requirements and explains pagination for long pages.

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 output structure (fields like slug, title, canonical_url) and confirms no destructive behavior, providing useful 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?

Description is concise, well-structured with purpose, usage guidance, input requirements, and output format front-loaded. 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?

Given no output schema, the description fully specifies the output shape. Sibling tools are mentioned for alternative. Parameters are well-documented. The tool is simple and the description covers all needed 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%, so baseline is 3. The description repeats parameter details (optional, defaults, enums) but adds no new semantic information 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 lists indexed bundled docs pages across all four products with specific fields, and differentiates from siblings 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 specifies when to call (surveying available docs, getting slug catalog) and when to prefer dero_docs_search. Also covers optional parameters and defaults.

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 that the operation is 'In-process — no network round trip', which is valuable behavioral context 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 well-structured with clear sections (When to call, Input Requirements, Output). It is concise yet comprehensive, with no redundant sentences. The 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 moderate complexity (4 params, no output schema), the description provides complete context: input requirements, output fields (title, slug, headings, excerpt, canonical_url, score), and operational notes (in-process). It covers all necessary information for an agent to use the tool 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?

Schema coverage is 100% (baseline 3). The description adds defaults (limit default 8), clarifies query must be non-empty, and provides usage examples for product and section parameters (e.g., 'tela for TELA-DOC-1 questions'). This adds meaningful guidance 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 searches a bundled DERO documentation index across specified products (derod, tela, hologram, deropay). The verb 'search' and resource 'documentation index' are explicit, and it distinguishes from sibling tools like dero_docs_get_page and dero_docs_list.

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 includes a 'When to call' section that explains when to use the tool (e.g., before explaining DVM, RPC methods) and advises returning citation information. It lacks explicit alternatives comparison, but provides clear context for invocation.

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 one-time ~10s scan on first call, caching, non-unique dURLs, collision handling, and output shape. Annotations already declare readOnlyHint=true, and description adds valuable behavioral 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?

Description is well-structured with purpose, when-to-call, input, output sections. It is somewhat lengthy but every sentence adds value; minor improvement possible by tightening phrasing.

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 one parameter and no output schema, description covers discovery process, collision behavior, and related tools (tela_inspect). Fully adequate for the tool's 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 durl parameter description. Description adds beyond schema: case- and prefix-insensitivity, examples, and clarification that it's not for DERO names.

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 TELA dURL to on-chain SCID(s). It uses specific verbs and resources, and distinguishes from siblings like dero_name_to_address and dero_tela_list_apps.

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 (e.g., user asks for SCID of a dURL) and when not to call (for DERO names, use dero_name_to_address). Provides routing 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 explicitly states the tool is read-only, never broadcasts, never touches a wallet, and never mutates chain state, adding to the annotations. It also details the math, self-verification, and that failure throws, providing full behavioral transparency 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 long but well-structured into sections (purpose, when to call, math, input requirements, output, read-only). Every sentence contributes value for a complex tool, but it could be slightly more concise without losing clarity.

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 tool with no output schema, the description thoroughly details the output structure, input constraints, and behavior (including self-verification and failure modes). It covers all necessary context for correct invocation and interpretation of 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% with good descriptions, but the tool description adds crucial context like mutual exclusivity of tx_hash and tx_hex, the effect of negative amount_dero on uint64 wraparound, and the meaning of output fields. This adds value beyond the schema, so slightly above baseline 3.

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 builds a deroproof display object for any transaction, ring slot, and amount, including negative wraparounds. It distinguishes from siblings like dero_decode_proof_string by emphasizing forging over decoding, and specifies it's for demonstration/integrity refutation.

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 describes the exact scenario: when a user asks if 'Verified ✓' means chain-minted coins. It also mentions reproducing the inflation-claim demonstration. This provides clear context and appropriate use cases, though it doesn't list exclusions or 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, but description adds critical input constraints (exactly one of hash/height, format rules) and output details (fields like block_header, miner_tx, txs). It also mentions error handling. This exceeds what annotations provide.

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 and efficiently structured: purpose first, then usage guidelines, then critical input rules, then 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?

Despite lack of output schema, description covers input requirements, output fields, error conditions, and usage context. It is fully 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 coverage is 100% with descriptions, but description adds the mutual exclusivity constraint, hash length requirement, and height non-negative integer. This significantly elaborates 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 states 'Fetch a full block (header + miner_tx + transactions + topo position) by height OR hash' which is a specific verb+resource+scope. This clearly distinguishes it from siblings like dero_get_block_header_by_hash or dero_get_block_count.

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 ('when investigating a specific block or verifying a transaction's inclusion'), suggests calling dero_get_height first if no target height, and recommends citing dero_docs_search for field semantics. This 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds useful context about it being a tip count not topoheight, enhancing transparency 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 only 4 sentences, each serving a distinct purpose: stating what it does, clarifying a nuance, providing usage guidance, and documenting output. No waste.

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 is complete: it explains the purpose, clarifies the distinction from topoheight, gives usage guidance, and specifies the output format.

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, so schema coverage is 100%. The description explicitly states 'Input Requirements: none', which is sufficient for a parameterless tool. Baseline 4 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 gets the total block count via DERO.GetBlockCount and distinguishes it from topoheight. It is specific about the verb and resource, and contrasts with the sibling tool dero_get_height.

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 (for just the block count, e.g., delta math) and recommends an alternative (dero_get_height) when both tip and stable heights are needed.

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, confirming safe read-only operation. Description adds input validation requirement (exactly 64 hex) but does not discuss error handling (e.g., invalid hash), idempotency (idempotentHint false), or rate limits. Adequate but could be improved with more 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?

Three concise paragraphs: purpose, usage guidelines, input/output requirements. Every sentence adds value. Front-loaded with purpose. 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 one parameter, no output schema, and clear annotations, the description covers purpose, usage, input validation, and output format. Could include an example output but not necessary for completeness.

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. Description reinforces that hash MUST be exactly 64 hex characters, adding emphasis beyond the schema's pattern. This adds clear, critical guidance for the agent.

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 'Get a block header by its 64-char hex hash', specifying the verb (get) and resource (block header by hash). Differentiates from sibling tools like dero_get_block (which includes txs and miner_tx) and dero_get_block_header_by_topo_height (which uses topo height instead).

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: when you have a block hash and need the header without the full block body. Advises to use dero_get_block when txs or miner_tx are also needed. Provides clear 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 and non-destructive behavior. The description adds input constraints (non-negative, bounded by current topoheight) and outlines the output structure, which goes beyond annotations. Minor room for more detail on potential errors.

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 sentences plus bullet), well-organized with separate sections for usage, input requirements, and output format. 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 simple tool (one parameter, no output schema), the description fully covers purpose, usage context, input constraints, and output structure. No gaps remain 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?

The schema covers 100% of parameters with description 'Topological height' and minimum 0. The tool description adds context: must be non-negative and no greater than current topoheight, which is not in the schema. This provides added value for 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 retrieves a block header by topological height, using the specific DERO API method. It distinguishes from sibling tools like dero_get_block_header_by_hash by focusing on topoheight vs height.

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 (when needing header by topo position) and provides a prerequisite (call dero_get_info if unsure about current topoheight). This helps the agent choose correctly among siblings.

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. The description aligns by stating it's a 'Get' operation. It also discloses important behaviors: it does NOT submit a block, and explains output is a block template. No contradictions and adds 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: 4 sentences covering purpose, usage, input requirements, and output limitations. Every sentence is informative with no redundancy. Well-structured and 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 specialized nature and absence of an output schema, the description adequately covers input requirements, output purpose, and critical usage notes. However, it could elaborate on the returned payload structure, but it is sufficient for an agent to use 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 covers all parameters with descriptions (100% coverage). Description reiterates and adds emphasis on critical requirements (valid address pattern) but does not introduce new semantic details beyond the schema. Thus, it provides marginal added value, scoring a 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 the tool's function: 'Get a mining block template for a miner payout address'. It also distinguishes itself from siblings, explicitly recommending 'dero_get_last_block_header' for general chain-tip inspection, so the purpose is specific and well-differentiated.

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 usage guidance: 'When to call: ONLY when you are actually mining. PREFER dero_get_last_block_header for general chain-tip inspection.' It clearly states the scenario and alternative, earning a 5.

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 adds critical behavioral context beyond annotations: output is an opaque encrypted blob not cleartext, only decrypted by wallet with spend key, and warns against presenting encrypted bytes as balance. This complements the readOnlyHint annotation 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 efficiently structured with bold warnings, a clear use-case section, and bullet-style input requirements. Every sentence adds value, with no redundancy or filler.

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 provides output format outline ({status, registration, balance, ...}) and covers parameter details. However, it omits explanation of the status field and registration component, which could be important for agents. Still, it is largely complete given the tool's simplicity and other rich fields.

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 essential guidance: address must start with dero1/deto1, topoheight must be integer (-1 for latest), scid is optional and format specified. These imperative instructions go beyond the schema's descriptive text.

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 an encrypted balance blob for a DERO address at a specific topo height, distinguishing it from other DERO tools that return cleartext balances or block data. 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 'When to call' section explicitly describes use cases (verifying on-chain encrypted state, sub-step) and recommends dero_docs_search as an alternative for understanding opacity, providing clear guidance on when and when not 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?

Description aligns with readOnlyHint annotation, confirming no side effects. It adds context that nothing is submitted and outputs gas estimates, going beyond the annotation's binary hint.

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 (purpose, usage, input requirements, output). However, slightly verbose with bullet points; could be trimmed but still efficient and 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?

Fully describes tool purpose, pre-flight nature, input constraints, and output structure. Given no output schema, it provides the necessary fields. No gaps for an estimation tool with moderate 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?

Input schema covers 100% of parameters with descriptions, and the description adds critical usage rules: at least one of transfers/sc/sc_rpc must be provided, explains sc_rpc format, and notes signer is optional but preferred. This significantly enhances schema details.

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 DERO.GetGasEstimate API. It emphasizes this is a pre-flight check with no submission, distinguishing it from sibling tools like estimate_deploy_cost.

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: before wallet-side transfers/scinvoke to size fees, or when explaining deploy costs. It also suggests preferring dero_docs_search for deeper understanding, providing clear alternative usage.

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 value by specifying the output fields and the underlying RPC method (DERO.GetHeight), which is not in 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?

Three concise sentences: first defines purpose, second gives usage guidance, third details output. No wasted words, front-loaded with essential 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?

For a read-only tool with no parameters, the description fully covers behavior, output format, and usage context. Output schema is absent, but description explicitly lists output fields, 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?

No parameters, so schema coverage is 100% and description adds no param info. Baseline 4 is appropriate; the description doesn't need to elaborate on absent 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 verb 'Get' and the resource 'block heights', specifying three specific fields (tip height, stable height, topoheight). It distinguishes from siblings like dero_get_info and dero_get_block_count by highlighting the quick snapshot purpose.

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 (quick height snapshot without full chain-info) and recommends preferring dero_get_info when more data is needed. Provides clear context and 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, so the description correctly aligns (no contradiction). The description adds output field details (height, difficulty, etc.) which goes beyond annotations. However, it doesn't discuss error cases or rate limits, but given the tool simplicity and annotation coverage, this is adequate.

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

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

Three focused sentences plus one-line sections for input/output. Front-loaded with purpose and usage context. Every sentence adds value with 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?

Despite no output schema, the description lists key output fields (topoheight, stableheight, etc.). The tool is simple (zero parameters, no side effects), and the description covers purpose, when to use, and output format sufficiently.

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?

There are 0 parameters, so baseline 4 applies. The description correctly states 'Input Requirements: none.' No further parameter guidance 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 explicitly states 'Get DERO daemon and chain metadata' and lists specific fields (height, topoheight, stableheight, etc.). It clearly identifies the resource and verb, and distinguishes from sibling tools like dero_get_height and dero_get_block which have narrower scope.

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 ('first thing in any chain-state investigation or sync-health check'), ordering relative to other tools ('BEFORE dero_get_sc, dero_get_transaction, or dero_get_block'), and recommends using dero_docs_search for user verification. This is excellent usage 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. The description adds that it returns only header without full block body and mentions the underlying API call. 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?

Three short paragraphs, well-structured with bold headers. No unnecessary words. Front-loaded with 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 zero parameters, read-only annotations, and no output schema, the description complete: explains output structure and use cases. No missing information.

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 has no properties (100% coverage). Description explicitly states 'Input Requirements: none', reinforcing the schema, which is helpful for the agent.

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?

Describes specific verb 'Get' and resource 'header of the current tip block', distinguishes from dero_get_block which returns transactions. No ambiguity.

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 (need tip block metadata without transactions) and when not to (prefer dero_get_block for transactions). Also lists input requirements as none.

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 context about the use case and output format but doesn't reveal additional behavioral traits beyond what annotations provide.

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?

Three concise sentences with a bullet for input requirements, front-loaded with purpose. 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?

Given the tool's simplicity (one optional param, read-only), the description adequately covers purpose, usage, parameter requirements, and output format. Annotations cover safety profile.

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% for the only parameter (scid), and the description re-emphasizes that it's optional and must be 64 hex characters, adding clarity 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 gets random registered addresses for ring construction, and distinguishes it from siblings by specifying the use case (private transfers via DERO.GetRandomAddress).

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 (building transfer ring, sampling chain participants) and mentions optional SCID limits sampling. Lacks explicit when-not-to-use or alternatives among siblings, but provides good 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 and destructiveHint=false, so description confirms it's a read operation. Beyond annotations, it adds critical behavioral details: input format requirements (64 hex SCID), optional parameters with defaults, and output shape. Does not contradict 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 sections, bullet points for input requirements, and concise without redundancy. Every sentence adds value. Efficient use of whitespace and formatting.

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, description provides the return shape (`{ code, balances, variables: { stringkeys, uint64keys }, ... }`). Covers all input constraints, recommended usage patterns, and alternatives. A complete and self-contained definition for a 4-param 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?

Schema coverage is 100%, providing baseline 3. Description adds substantial value by explaining each parameter beyond the schema: scid must be exactly 64 hex, code defaults true, variables defaults true, topoheight omit or -1. This semantic detail helps 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?

Clearly states it reads smart contract state by SCID, and positions itself as the primary entry point for DERO contract inspection. The verb 'Read' and resource 'smart contract state' are specific. It distinguishes itself from sibling tools by being the first step in investigations.

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.' Provides clear alternatives: pair with dero_docs_search for interpretation, prefer citing dero_docs_search or dero_docs_get_page. This gives both when-to-use and when-not-to-use 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 already declare readOnlyHint=true, and the description adds that each transaction is returned with confirmation status, block hash, and optionally decoded JSON fields. It also outlines the output structure. While annotations cover safety, the description adds valuable details about what the agent can expect, though not exhaustive.

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 front-loaded purpose, followed by usage guidelines, input requirements, and output description. Every sentence serves a purpose with no redundancy. It is concise yet comprehensive 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?

Given the tool's simplicity (2 parameters, read-only) and the presence of annotations, the description provides sufficient context: purpose, when to call, input requirements, and output summary. However, the lack of an output schema means the description must convey return structure, which it does adequately but not with full detail per field.

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 emphasizes that txs_hashes must be a non-empty array of 64-char hex strings (already in schema) and that decode_as_json is optional with a preference for 1. This adds marginal guidance beyond the schema but does not substantially enhance understanding.

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 'Fetch one or more transactions by hash via DERO.GetTransaction', providing a specific verb and resource. It distinguishes from siblings by recommending pairing with dero_get_sc when the transaction invokes a contract and differentiating from trace_transaction_with_context. Purpose is unambiguous and well-differentiated.

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: when tracing a tx by hash' and provides pairing guidance with dero_get_sc. It also advises to prefer citing dero_docs_search for transaction structure interpretation. This gives clear context for when to use this tool vs 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 readOnlyHint=true. Description adds that the output is `tx_hashes: string[] | null` and explains null/empty array means no pending. 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?

Extremely concise: one-liner, then 'When to call:', 'Input Requirements:', 'Output:'. Every sentence adds value. Front-loaded with the main 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 no parameters, simple output, and annotations covering safety, the description fully explains behavior and output format, including null handling. 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?

No parameters in input schema; description correctly states 'Input Requirements: none'. With 0 params, baseline is 4, and no additional semantics 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?

Clearly states the verb 'list' and resource 'pending mempool transaction hashes' via 'DERO.GetTxPool'. No confusion with siblings, as no other tool lists mempool transactions.

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: checking unconfirmed activity, watching for specific tx, estimating mempool pressure. Also includes a note on handling null/empty array. Does not specify alternatives, but none are obvious.

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, making idempotent and destructive hints less relevant. Description adds that resolution is case-sensitive and that NOT_FOUND surfaces a structured error via _meta.error. 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?

Description is concise, uses clear headings, and every sentence provides necessary information. 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?

No output schema, but description explains output format and error handling. For a simple read-only tool with two parameters, this 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%, but description adds critical detail: name must be non-empty, case-sensitive at daemon level; topoheight must be integer and -1 for latest. This adds 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?

Description clearly states 'Resolve a DERO on-chain registered name to its address via DERO.NameToAddress', specifying verb (resolve), resource (name to address), and method. No sibling tool performs name resolution, so it is well-differentiated.

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: 'when a user supplies a human-readable name instead of a dero1... address'. Provides critical input requirements but does not mention when not to call or alternatives, which is acceptable given the narrow scope.

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 valuable context: the tool is powered by an in-process scan, first call triggers a ~10s delay (cached afterward), and index_meta discloses scan coverage. Nothing contradicts 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 front-loaded with purpose, then usage guidelines, input requirements, and output structure. Every sentence adds value without redundancy. Length is appropriate 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?

No output schema exists, but the description fully explains the output fields (query, total_matched, returned, truncated, apps array with fields, index_meta, narrative, related_docs). It also covers the one-time scan delay and caching behavior. For a two-parameter list tool, this 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%, so baseline is 3. The description confirms that query is optional, case-insensitive, and limit defaults to 50 max 200, matching the schema. It adds no new parameter details beyond the schema, so a 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 lists/browses TELA apps discovered on-chain, specifying each app's dURL, name, SCID, and doc count. It distinguishes itself from siblings like dero_durl_to_scid and tela_inspect by mentioning exact dURL or SCID lookup alternatives.

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: 'when a user wants to explore or search the TELA ecosystem' and provides alternatives for exact dURL (dero_durl_to_scid) or specific SCID (tela_inspect). This gives clear guidance on tool selection.

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 partial-failure modes, output status values (healthy, lagging, partial, unreachable), null conditions for chain and mempool fields, and structured error on total unreachability with code RPC_UNREACHABLE. Adds value beyond readOnlyHint annotation.

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-organized with sections for purpose, when to call, input requirements, and output description. Each sentence serves a purpose, no repetition. Efficiently conveys complex behavior.

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, description sufficiently details output structure (status, narrative, signals, chain, mempool, related_docs, _diagnostics) and edge cases. Covers all necessary behavioral aspects for a 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% for single boolean parameter. Description adds context: optional, default true, and explains when to set false (skip mempool snapshot for chain-tip only). Baseline 3 plus extra value.

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 is a composite tool running a four-step chain (DERO.Ping → DERO.GetInfo → DERO.GetHeight → DERO.GetTxPool) and returning a narrative health report. Distinguishes itself from sibling primitive tools by being a higher-level composite.

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 specifies when to call: as first step in chain-state investigation for health/sync/state queries. Provides clear preference over chaining primitives due to consistent partial-failure handling and lag-depth classification.

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. The description adds valuable behavioral context: it protects against fabricating a breakdown when the daemon reports 0/0 with non-OK status, and returns structured errors on DVM compile failure. This 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 for when to call, input requirements, and output format. It is concise for the amount of information conveyed, though slightly lengthy. 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?

Given the complexity of this composite tool, the description covers all necessary aspects: input requirements, edge cases (breakdown null conditions, error handling), and a detailed output schema. No output schema exists, so 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%, but the description adds meaning: 'sc' must be the full contract with Function blocks; 'signer' is optional and used for fee context; 'include_breakdown' defaults true. These explanations help the agent 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 it is a composite tool that sends a DVM-BASIC contract source to the gas estimator, returning a raw estimate, plain-text breakdown, parsed contract surface, and curated docs. It distinguishes itself from the sibling tool 'dero_get_gas_estimate' by explicitly advising to prefer this composite over chaining that call.

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 usage guidance: 'When to call: BEFORE asking a wallet to broadcast a deploy transaction, OR when explaining the cost of a contract to a user.' It also provides a clear alternative ('PREFER this over chaining dero_get_gas_estimate yourself') and mentions when not to expect a breakdown (non-OK status with 0/0).

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 composite nature: fetches code+variables+balances, parses source, classifies, generates narrative, reorders docs. Notes edge cases: has_code false for unknown SCID, raw_code_length present for fallback. No contradiction with readOnlyHint=true.

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: starts with composite nature, then output, then when to call, then input requirements, then output details. Some sentences could be tightened but 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?

No output schema but description details output fields and types, including surface.functions items, has_code behavior, raw_code_length. Covers edge cases, though could be slightly more explicit about return 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% and description adds context: scid required with hex length, example given; topoheight optional for specific height. Adds 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 it is a composite that fetches a DERO smart contract and returns function surface, classification, narrative, and docs citations. It distinguishes from siblings like dero_get_sc and tela_inspect with specific verbs and details.

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 user wants to understand a smart contract. Prefers over chaining dero_get_sc with docs lookup. Provides a known-good example (0000...0001) and explains agent does not need to learn DVM-BASIC syntax.

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 show readOnlyHint=true; description details the fan-out, boosting, deduplication, 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?

Front-loaded with purpose and usage. While lengthy, every part adds value, including input requirements and output format. Could be slightly trimmed but highly informative.

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 description fully defines the output structure including related_docs and error handling. Covers behavioral details, edge cases (zero matches), and input constraints. Very 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%, but description adds valuable context: how to phrase intent, effect of product_hint (1.5x boost), and default/max for limit_per_product. Exceeds baseline of 3.

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 natural-language intent, fans out parallel searches across four DERO products, boosts product_hint matches, and returns ranked recommendations with rationale and citations. It distinguishes itself from dero_docs_search by instructing to call this first.

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: at the start of documentation investigations, before dero_docs_search. Also advises to prefer this over guessing the product, and gives input best practices.

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. The description adds substantial behavioral context: extraction from comment block, gzip decompression, pagination via offset, and notes that author signature presence is reported but not verified. 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 and front-loaded with the core function. It uses bullet points for input requirements and output fields, making it easy to parse. Every sentence adds value, and the length is appropriate 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?

Since there is no output schema, the description thoroughly explains all output fields and their meanings, including handling of compressed files, pagination, and edge cases like non-embedded content. It provides complete guidance for an agent to use the tool 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 description coverage is 100%, but the description adds significant meaning: for scid, it explains the 64-hex requirement and behavior for invalid inputs; for offset, it clarifies pagination with next_offset; for topoheight, it advises omission for latest state. This exceeds the baseline of 3.

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 fetches actual file content from TELA-DOC-1 contracts, extracting from DVM-BASIC comment blocks. It uses specific verbs like 'fetch' and 'extract', and distinguishes from sibling tools like dero_get_sc (raw contract wrapper) and tela_inspect (gets SCIDs).

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' guidance and recommends preferring this tool over dero_get_sc. It also advises getting SCIDs from tela_inspect first. However, it does not explicitly state when not to call, though it implies via the input requirements.

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, and the description adds significant behavioral context: it reads raw stringkeys directly, returns a discriminated union with three possible kinds (tela_index, tela_doc, not_tela), and explains what happens when the SCID is unknown (not an error). It also truthfully reports updateability as 'unknown' since it cannot derive it from chain state. No contradictions with annotations. This highly transparent disclosure goes well beyond 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 verbose but well-structured: it begins with a high-level 'Composite:' summary, then explains when to call and input requirements. It uses clear section breaks and bullet-style lists. While it could be slightly trimmed (e.g., the output details are lengthy), every sentence serves a purpose and is logically organized. The front-loading of the core purpose aids quick understanding. Score 4, as it is not perfectly concise but still effectively structured.

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 tool is complex (composite, auto-detects, multiple output types) and has no output schema, yet the description fully details the returned structure for each kind (tela_index, tela_doc, not_tela). It also covers edge cases (e.g., unknown SCID returns not_tela, not an error) and contrasts with sibling tools. Given the tool's complexity and lack of output schema, the description leaves no significant gaps. Score 5.

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 input schema provides descriptions for both parameters (scid and topoheight) with 100% coverage, so the baseline is 3. However, the description adds meaningful context: it clarifies that scid must be 64 hex chars (though schema pattern already enforces it) and explains the purpose of topoheight ('inspect at a specific topo height; omit for the latest committed state'). This adds value by connecting parameters to the tool's domain (TELA contract inspection) without redundancy. A score of 4 reflects this modest but useful enrichment.

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 and parses a TELA contract by SCID, auto-detecting whether it's an INDEX or DOC contract. It uses a specific verb ('fetch and parse') and resource ('TELA contract by SCID'), and distinguishes itself from sibling tools like explain_smart_contract and dero_get_sc by highlighting its ability to enumerate all DOC references and decode TELA-specific headers. This aligns with the highest rating.

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: 'as the FIRST step whenever a user references a TELA SCID, a `.tela` dURL app, or asks...'. It provides clear guidance on when not to use alternatives, such as avoid explain_smart_contract because it treats TELA contracts generically and drops DOCn entries. It also lists specific input requirements and optional parameters. This meets the highest standard for usage 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 already declare readOnlyHint=true, so no contradiction. Description adds behavioral context: it is a composite, handles TX_NOT_FOUND, does not perform SC invocation arg decoding, and surfaces raw_tx_hex_length. This provides significant additional understanding 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 sections and front-loaded purpose. While somewhat lengthy, each sentence provides useful information without redundancy. It is appropriately concise for the complexity of the 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?

Despite no output schema, the description thoroughly explains the output fields (tx_hash, confirmation, kind, ring, etc.), covers limitations (no SC arg decoding), and describes failure modes (TX_NOT_FOUND). This is complete for an agent to understand the tool's behavior and outputs.

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 meaning: explains the decode parameter's effect, the include_sc_context parameter's function, and the tx_hash format requirement. It also mentions defaults and implications, adding value 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 it is a composite tool for looking up a DERO transaction by hash, classifying confirmation status and kind, extracting SC surface for contract installs, and stitching citations. It distinguishes from sibling tools like dero_get_transaction by explicitly stating preference over chaining.

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 when investigating any tx by hash' and lists specific user queries. It also says 'PREFER this over chaining dero_get_transaction with dero_get_sc yourself' and provides reasons, giving clear guidance on when to use this tool over alternatives.

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