dero-mcp-server
Server Quality Checklist
Latest release: v0.6.0
- Disambiguation5/5
Each tool has a clearly distinct purpose. The raw RPC tools (e.g., dero_get_block, dero_get_transaction) are individually scoped, composite tools (diagnose_chain_health, estimate_deploy_cost) provide higher-level operations, and docs tools serve search and retrieval. No two tools overlap in function.
Naming Consistency5/5Tools follow a consistent 'dero_' prefix pattern. Raw RPC tools use 'dero_<verb>_<noun>' (e.g., dero_get_block, dero_get_height). Composite tools have descriptive names (diagnose_chain_health, estimate_deploy_cost). Docs tools use 'dero_docs_<verb>'. Naming is uniform and predictable.
Tool Count4/5With 25 tools, the set is somewhat large but still well-scoped for a comprehensive blockchain server. It covers raw RPC, composite operations, and documentation utilities. The number is justified by the domain's needs, though it borders on heavy.
Completeness5/5The tool set provides thorough coverage of DERO daemon RPC operations: chain info, blocks, transactions, smart contracts, mining template, gas estimation, name resolution, encrypted balance, and more. Composite tools fill gaps for health checking, cost estimation, and transaction tracing. Documentation tools complete the surface. No critical gaps.
Average 4.7/5 across 25 of 25 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 28 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
This server has been verified by its author.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only and non-destructive behavior. The description adds useful behavioral context beyond that: 'In-process — no network round trip,' ranked output with a specific field list, and a recommendation to use canonical_url/slug as citations. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The main purpose is front-loaded, followed by clearly-labeled usage, input requirements, and output sections. The prose is efficient, though the input requirements section partially duplicates schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description appropriately documents return fields, ranking behavior, and in-process execution. It covers invocation constraints and citation guidance. It does not mention no-result behavior or explicitly route to sibling doc tools, but the essential information for calling the tool correctly is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, so the schema already documents every parameter. The description adds minor context such as using product to 'reduce noise' and section to 'scope further,' but largely restates the schema's own descriptions without adding substantial new semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a precise action and resource: 'Search the bundled DERO documentation index across derod, tela, hologram, and deropay (145+ pages).' This clearly distinguishes search from sibling tools like dero_docs_get_page or dero_docs_list, which retrieve or enumerate rather than search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When to call' section explicitly states when to use the tool: when authoritative docs are needed, before constructing citations, and before explaining DVM, RPC methods, TELA contracts, Hologram simulator, or DeroPay webhooks. It gives clear context but does not explicitly identify when to use sibling alternatives instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavioral detail: each transaction returns confirmation status, block hash, and optionally decoded JSON fields, and it clarifies the difference between raw blobs and decoded payloads. This goes beyond the annotations while remaining consistent with them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized into summary, when-to-call, critical input requirements, and output format. It is front-loaded with the core purpose, and each section earns its place with actionable guidance. No fluff or redundant prose beyond useful emphasis.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, but the description explains the return shape clearly: `{ txs: [...], txs_as_hex: [...] }` with per-transaction confirmation, block hash, and decoded fields when requested. It also covers required input format, optional parameter behavior, and related tools, making it complete enough 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.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters well. The description adds a modest clarification that decode_as_json should preferably be 1 and that it switches from raw blobs to JSON-decoded fields, but much of the input requirement text repeats schema constraints such as non-empty and 64-char hex. This is above baseline but not a major semantic addition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: "Fetch one or more transactions by hash via DERO.GetTransaction." It also mentions when to call and how to pair with dero_get_sc, but it does not explicitly distinguish this tool from the sibling trace_transaction_with_context, which could also be used for hash-based tracing. Thus it is clear but lacks full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit context: "When to call: when tracing a tx by hash," and advises pairing with dero_get_sc for contract invocations and citing dero_docs_search. It provides clear usage context and alternatives, but it does not explicitly state when not to use this tool or when to prefer trace_transaction_with_context instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe read-only nature is covered. The description adds important behavioral context: the strict exactly-one input constraint and the INVALID_INPUT error condition, plus the exact output shape with topo position. This goes beyond the schema's basic type/pattern info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear first sentence, a 'When to call' section, a labeled critical input section, and an output summary. Every sentence is functional and no filler exists. The most important usage rule is prominently highlighted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter, read-only lookup tool with full schema coverage, the description covers the purpose, invocation conditions, required input combination, parameter constraints, and output contents. It even suggests a docs-search path for deeper field semantics. There is no output schema, so the description appropriately enumerates the returned block components.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both params and the hash pattern. The description adds the critical rule that exactly one of hash or height must be supplied and states the height must be non-negative, which is already in the schema but reinforced. It does not add new param-level meaning beyond the exclusive-or requirement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Fetch'), a precise resource ('full block ... by height OR hash'), and names the RPC method (DERO.GetBlock). It clearly distinguishes this from sibling tools like dero_get_block_header_by_hash by specifying that the full block includes header, miner_tx, transactions, and topo position.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to call it ('when investigating a specific block or verifying a transaction's inclusion') and tells the agent to call dero_get_height first if no height is known. It does not explicitly exclude alternative sibling block-header tools, but the 'full block' scope and output field list imply when the lighter header tools should be used instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, and the description is consistent with that. The description adds valuable behavioral context beyond annotations: default values for code and variables, the meaning of topoheight (-1 for latest), the critical 64-hex scid requirement, and an outline of the output structure. This gives the agent a clear mental model of what happens when parameters are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average but well-structured with clear sections: purpose, when-to-call, input requirements, and output. The most important information is front-loaded (what the tool does, then when to call). Some redundancy exists with the schema (defaults are repeated), but each line adds or reinforces useful context, so the length is justified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, one-required-parameter tool with 100% schema coverage, the description covers everything needed: input validation, optional parameter behavior, output shape, and guidance on how to interpret results via docs. The presence of an output description compensates for the lack of an output schema. No significant information is missing for an agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description reinforces the schema's defaults but also adds extra meaning for parameters: 'Set false to skip the source blob when you only need stored variables' and 'Set false to skip variables when you only need the source.' These usage-oriented explanations go beyond the schema's simple 'Include ...' descriptions, justifying a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read smart contract state') and the resource (code and/or stored variables by SCID). It also frames the tool as 'the primary entry point for any contract inspection on DERO', which gives a sense of scope. However, it does not explicitly name sibling tools like explain_smart_contract to differentiate itself, so the distinction is implied rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit 'When to call' section: 'as the first step in any DVM contract investigation.' It also recommends pairing with dero_docs_search and tells the agent to prefer citing docs pages for user interpretation. It does not explicitly mention when NOT to use this tool or how it contrasts with explain_smart_contract, so it lacks exclusions for alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds the important behavioral fact that this tool returns a template payload without submitting a block. It could disclose a bit more about response structure or failure behavior, but the non-submission clarification is valuable 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: purpose, when to call, critical input requirements, and output. It front-loads the most important usage guidance and each sentence supports tool selection or invocation without unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and moderate parameter complexity, the description covers when to use it, the required parameters, the optional parameters, and the high-level output. It stops short of describing the exact block template fields, but it gives enough context for an agent to call the tool correctly for mining purposes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description repeats most parameter meanings from the schema, such as 'block' including the raw block blob and 'miner' as an optional label. It adds only minor emphasis that wallet_address must be valid and receive the reward, but does not substantially expand parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Get a mining block template for a miner payout address via DERO.GetBlockTemplate.' It also distinguishes itself from the sibling tool dero_get_last_block_header, making the tool's unique purpose immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When to call' section explicitly restricts this tool to actual mining and names dero_get_last_block_header as the preferred alternative for general chain-tip inspection. It also clarifies that the tool does NOT submit a block, which helps the agent avoid misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by explaining the output format and the edge case of null/empty array, which 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with clear sections: purpose, usage note, input, output. Every sentence adds value. Front-loads the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description adequately covers the output and edge cases. Could mention mempool state implications, but sufficient for the simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description states 'Input Requirements: none' which adds clarity. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists pending mempool transaction hashes. The verb 'List' and resource 'pending mempool transaction hashes' are specific. The tool name and description distinguish it from siblings like dero_get_transaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance on when to call: checking unconfirmed activity, watching for a specific tx, estimating mempool pressure. Includes a note about handling null/empty. Does not explicitly mention when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal read-only and non-destructive behavior, and the description adds the output contract including the returned shape and the 'bundled' aspect of the docs pages. It also documents limit defaults and max, covering important behavioral details 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well organized: a one-line summary, a usage section, input requirements, and an output shape. Every sentence earns its place, and the most important guidance is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only two optional parameters and no output schema, so the description carries the burden of explaining behavior and return values. It fully covers what the tool lists, when to call it, how to filter, and what the response looks like, and also names relevant sibling alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both product and limit are already fully described in the schema. The description mostly restates the same information, though it usefully frames product as an optional scoping parameter and repeats the limit default/max. This meets the baseline but adds little new semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a specific verb ('list') and resource ('indexed bundled docs pages across all four products') and names the key output fields (slugs, titles, canonical URLs). It also distinguishes itself from sibling tools by explicitly contrasting with 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.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit 'When to call' guidance with concrete examples and a clear preference rule: use dero_docs_search for specific questions, use this tool for surveying or obtaining a slug catalog. This fully routes the agent to the correct sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only and non-destructive. The description adds meaningful behavioral context by noting the response omits the block body and showing the output shape { block_header: {...} }. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four short labeled sections—purpose, when-to-call, input requirement, output—with no filler. Every sentence earns its place and the key scoping is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-required-parameter read tool, the description covers purpose, invocation condition, alternative tool, strict input format, and output shape. Nothing an agent needs to select and call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers the only parameter fully (pattern, type, required, description), so the baseline is 3. The description restates the 64-hex requirement and gives example source context ('from a tx confirmation'), adding emphasis but little new semantic information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with a specific verb and resource: 'Get a block header by its 64-char hex hash', and clarifies it returns the header without the full block body. This distinguishes it from dero_get_block and the topo-height variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does 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 ... need its header without the full block body') and names dero_get_block as the alternative when txs or miner_tx are also needed. This gives an agent clear routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds that this is a pre-flight check with nothing submitted, complementing the readOnlyHint annotation. It also discloses the output contract ({ gascompute, gasstorage, status }) in the absence of an output schema. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Organized with scannable bold sections and bullets; every sentence contributes. Slightly longer than necessary, but the one-of constraint and output detail justify the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-output-schema tool with a non-obvious one-of parameter constraint, the description covers action, trigger conditions, parameter semantics, and return shape. It is complete enough for an agent to invoke correctly without opening additional references.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema descriptions cover 100% of parameters, the prose adds a critical one-of requirement for transfers/sc/sc_rpc that the schema (all optional) would otherwise hide. It also clarifies sc's role as DVM-BASIC source, sc_rpc's {name,datatype,value} shape, and the preference for passing signer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
States a precise action—estimate gas for transfers, SC deploys, or SC invokes—and names the underlying DERO.GetGasEstimate endpoint. It clearly distinguishes from pure read/chain tools, but does not contrast with the sibling estimate_deploy_cost, which overlaps in the deploy-cost use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit 'When to call' section: before wallet-side transfers/SC invokes to size fees, or when explaining deploy costs, and prefers dero_docs_search for user education. It lacks a 'when not to use' or explicit alternative tool mention (e.g., estimate_deploy_cost), so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal readOnlyHint=true and destructiveHint=false, and the description adds useful behavior beyond that: it samples chain-registered addresses and can be restricted to holders of a specific asset via scid. It also discloses the output shape, which is helpful since no output schema is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, with the main verb and resource front-loaded in the first sentence followed by short labeled sections for usage, input requirements, and output. Every sentence carries useful information; there is no filler or redundant restatement of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with one optional parameter and no output schema, the description fully covers purpose, when to call, parameter constraints and effect, and the return shape. An agent has everything needed to invoke and interpret the result correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers scid's type and pattern, so the baseline is 3. The description adds behavioral meaning: scid is optional, must be exactly 64 hex characters, and limits sampling to holders of that asset. This goes beyond the schema's minimal 'Optional asset smart-contract id (hex)' label.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Get random registered addresses from the chain', and names the underlying RPC method, DERO.GetRandomAddress. It is clearly distinct from sibling tools like dero_name_to_address or dero_get_transaction, so an agent can identify when this tool applies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an explicit 'When to call' section with concrete use cases: building a transfer ring in external wallet tooling or sampling chain participants. It does not mention when not to call it or name alternative tools, but the provided context is clear enough for appropriate selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only and non-destructive. The description adds the important runtime constraint that topoheight must not exceed the current topoheight and suggests calling dero_get_info first if unsure. It also includes an output shape, adding value beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well organized with clear sections: purpose, when to call, input requirements, and output. Every sentence adds useful information, and the critical constraint is highlighted. No filler or redundant restatement of the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only RPC call, this description is complete. The schema documents the parameter, annotations document the safety profile, and the description covers the dynamic input constraint and expected response shape. An agent has everything needed to decide to call it and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only says 'Topological height' with static min/max bounds. The description adds the crucial dynamic constraint that the value must be no greater than the current topoheight, explains the conceptual difference between topoheight and height, and provides practical guidance for verifying the value. This goes well beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific operation and resource: 'Get a block header by topological height.' It also clearly distinguishes the topoheight key from consensus block height, which separates this from header lookup by hash or height without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides a 'When to call' condition: use it when you need a header keyed by topo position rather than chain height. It does not name specific sibling tools as alternatives, but the contextual contrast between topoheight and height gives clear guidance for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavioral context: it is a round-trip sanity check, requires a non-empty array, and returns the concatenated echoed strings. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured with clear sections: purpose, when to call, input requirements, and output. Every sentence earns its place, and the most important guidance is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter echo tool with no output schema, the description is complete: it explains the purpose, when to use and not use it, the critical input requirement, and the output format. An agent has everything needed to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaning by specifying the non-empty constraint and clarifying that the daemon concatenates the returned string, which is not evident from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Echo strings through the daemon via DERO.Echo.' It clearly distinguishes the tool from dero_daemon_ping, making its purpose unambiguous even among many siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to call ('when you need to confirm that string payloads reach the daemon intact') and provides an alternative ('PREFER dero_daemon_ping for a lighter-weight liveness probe'), giving an agent clear decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and no destructiveness. The description adds concrete behavioral details: returns 'Pong' on success, structured _meta.error with RPC_UNREACHABLE on failure, and a retry hint. This adds value 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise, structured into clear sections (When to call, Input Requirements, Output). Every sentence is necessary and front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and annotations present, the description fully covers purpose, usage, input, and output behavior. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema is empty and schema description coverage is 100%. The description states 'Input Requirements: none,' which is sufficient. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a connectivity check via DERO.Ping, specifying the action and resource. It distinguishes from siblings by positioning it as the first step before other operations like dero_get_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to call (first step in chain investigation) and when to use an alternative (call before dero_get_info if unsure about configuration).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=true), it clarifies that the count is a tip count, not topoheight, and shows the output format. Slightly more detail about edge cases could elevate to 5, but it effectively communicates behavioral nuance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences plus output example. No unnecessary words, information is front-loaded, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given 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 fully covers purpose, usage context, output format, and alternative recommendations. Nothing missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist in the schema; baseline is 4. Description states 'Input Requirements: none', which is sufficient and adds no confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states 'Get the total block count' via a specific RPC method, distinguishes it from topoheight, and differentiates from sibling tool dero_get_height, making the purpose very clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'When to call' section with a use case (delta math), and directly recommends preferring dero_get_height for combined tip/stable heights, offering clear guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses essential behavioral context: the returned bytes are encrypted and not a cleartext balance, only a wallet holding the spend key can decrypt, and the tool should never present encrypted bytes as a balance to the user. It also explains the meaning of topoheight=-1 and scid handling, adding significant value 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear section labels (CRITICAL, When to call, Input Requirements, Output) and front-loads the most important caution about encrypted bytes. Every section contributes necessary operational guidance, and the length is justified given the tool's cryptographic sensitivity and domain complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for most invocation needs: it explains input constraints, output shape, and the critical caveat about encryption. Since there is no output schema, the explicit output summary helps. It could be slightly more complete by describing the registration field or providing an example, but the current level is sufficient for correct tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the tool description adds crucial semantic details: address must start with dero1 or deto1, topoheight -1 means latest chain tip, and scid should be omitted for native DERO while 64-hex SCID is for assets. These are not fully expressed in the schema and materially improve correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Get the ENCRYPTED balance blob for a DERO address at a topo height via DERO.GetEncryptedBalance.' It immediately disambiguates the result as an opaque encrypted blob rather than a cleartext balance, which clearly distinguishes this tool from any balance-returning sibling. The mention of the RPC method adds precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides 'When to call' guidance, including verifying on-chain encrypted state, use before transfers, and as a sub-step in another tool. It also recommends citing dero_docs_search for user understanding. However, it does not explicitly specify when not to call it or name a direct alternative, so it lacks a full when-not/exclusion statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds that it returns a specific output and is a 'quick snapshot' with less payload, which is useful but not extensive. It 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with three short sections (purpose, when to use, input/output). No wasted words; each sentence serves a purpose. It is front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and clear annotations, the description covers all necessary information: what it does, when to use it, and what it returns. It is fully complete for a simple read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The description explicitly states 'Input Requirements: none,' which adds clarity beyond the empty schema. No further information needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Get the current block heights' and specifies the three types (tip, stable, topoheight), providing a specific verb and resource. It explicitly distinguishes from sibling dero_get_info, making it easy for an agent to select.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit 'When to call' section and recommends preferring dero_get_info for additional data, giving clear context and alternatives for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by specifying the tool returns only the header (not full block body) and outlines the output structure. It does not contradict annotations and provides context beyond what annotations alone offer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of three short sentences. It front-loads the core action ('Get the header of the current tip block') and provides structured guidance on usage and output. Every sentence serves a purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description fully covers purpose, usage context, and expected output format. It mentions the output structure ({ block_header: { hash, height, ... } }) which compensates for the lack of an output schema. No further information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters. With schema coverage at 100% (empty schema), the description correctly provides no parameter details. Per guidelines, the baseline for 0 param tools is 4, and the description meets this standard by not requiring additional parameter explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the header of the current tip block, specifying 'no full block body'. It uses specific verbs ('Get the header') and resource ('current tip block'). This distinguishes it from siblings like dero_get_block which return full block data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to call: 'when you need tip block metadata without the transactions or miner_tx payload'. It also names an alternative: 'PREFER dero_get_block when you need transactions or the miner_tx'. This provides 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavior beyond annotations: case-sensitivity on the daemon side, the meaning of topoheight=-1 for latest registry state, and the NOT_FOUND error surfacing as _meta.error. This is richer than typical read-only descriptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear labels ('When to call', 'Input Requirements', 'Output'), front-loads the core purpose, and every sentence carries essential information. No filler or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read-only lookup with no output schema, the description is complete. It specifies input requirements, output shape ({ name, address }), and error behavior, so an agent has everything needed to invoke and interpret results correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, which sets a baseline of 3. The description adds value by emphasizing name non-emptiness as CRITICAL, clarifying case-sensitive resolution, and explaining the daemon-side behavior. These details supplement the schema's basic type and description fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Resolve') and names the exact resource (DERO on-chain registered name to address) plus the underlying RPC method (DERO.NameToAddress). This clearly distinguishes it from sibling tools like dero_decode_proof_string or address-fetching tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to call: when a user supplies a human-readable name instead of a dero1.../deto1... address. This gives the agent a clear decision rule with concrete examples and leaves no ambiguity about applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=true, destructiveHint=false), the description discloses important behavioral traits: it is a 'Composite' operation, triggered by an 'in-process scan of the newest chain contracts', and the 'first call triggers a ~10s one-time discovery scan (cached afterward)'. It also explains that index_meta discloses scan coverage, making result limitations transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: purpose, when to call, input requirements, and output shape. It front-loads the core answer, includes only necessary detail, and the output code block is compact and informative. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given 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 provides a full output shape and key behavioral caveats (first-call latency, caching, index_meta coverage transparency). It also clearly situates the tool relative to siblings, so an agent has everything needed to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both the schema and description document query as an optional case-insensitive filter and limit with default 50/max 200. The description adds usage context and examples but does not materially expand parameter semantics beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'list/browse the TELA apps discovered on-chain' and explicitly answers the question 'what TELA apps exist?'. It also differentiates itself from siblings by naming dero_durl_to_scid and tela_inspect as the tools for exact dURL or SCID lookup, so an agent can immediately tell this tool apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is an explicit 'When to call' section with concrete user intents ('what TELA apps are there', 'show me TELA games', 'is there a TELA app about X'), and clear exclusions: 'For an exact dURL use dero_durl_to_scid; to inspect a specific SCID use tela_inspect.' This leaves no ambiguity about when to choose 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds meaningful behavioral context: partial-failure modes, lag-depth classification, null behavior for chain and mempool, structured error code RPC_UNREACHABLE, and automatic docs citations. This goes beyond what the annotations alone communicate, though it does not cover every edge case like rate limiting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized for the composite tool's complexity and uses clear labeled sections: composite purpose, when to call, input requirements, and output. It front-loads the most important information and every section contributes necessary details without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description thoroughly documents the return shape including status enum values, null handling, and error behavior. It covers invocation context, parameter semantics, and failure modes, making it complete for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents include_tx_pool with type, description, and default, so the baseline is 3. The description adds decision guidance by explaining when to set it to false ('when you only need chain-tip status'), which is genuinely useful semantic context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific composite operation—running a four-step RPC chain (DERO.Ping → DERO.GetInfo → DERO.GetHeight → DERO.GetTxPool)—and names the output as a narrative health report. It clearly distinguishes itself from sibling primitive tools like dero_daemon_ping and dero_get_info by emphasizing it is the composite that should be used for health investigations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to call' section lists concrete user intents ('is the node healthy', 'is it synced', 'what is the current state of the chain'). It also tells agents to PREFER this over manually chaining the four primitives, giving a clear alternative and rationale.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=true, destructiveHint=false) already establish safety; the description adds rich behavior: the composite DERO.GetSC fetch, base64-decode + gunzip decompression, 60000-char chunking with next_offset, null content for DocShard/STATIC/external, and the explicit caveat that signature presence is not cryptographically verified. It also discloses INVALID_INPUT behavior for non-DOC SCIDs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bolded sections: purpose, when to call, input requirements, output. The most important scoping and alternative routing are front-loaded, and the detailed output explanation is justified because there is no output schema. No filler sentences, despite the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description thoroughly explains return fields like content, compressed, decompressed, stored_filename, next_offset, and the signature caveat. It covers pagination, compression, invalid-input behavior, and the relationship to tela_inspect and dero_get_sc. The tool's complexity is matched by the description's completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% — each parameter is documented with type, constraints, and purpose. The description echoes the schema for scid/offset/topoheight and adds only one extra semantic detail: that an INDEX or non-TELA SCID returns INVALID_INPUT with guidance. Per the high-coverage baseline, a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: fetches and extracts the actual file content from a TELA-DOC-1 contract. Explains the internal mechanism (scraping a DVM-BASIC comment block) and explicitly distinguishes itself from dero_get_sc, which returns the raw wrapper. This leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes an explicit 'When to call' section: read/inspect actual code/markup of a TELA app file, with concrete example queries. Tells the agent to get DOC SCIDs from tela_inspect first, and instructs to prefer this tool over dero_get_sc with the reason why. This is model guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal read-only and non-destructive behavior, and the description adds substantial context beyond that: it reads raw stringkeys, auto-detects the standard, returns not_tela as a normal result rather than an error, and honestly reports updateability as unknown. This gives the agent a clear model of the tool's behavior and edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but tightly organized: purpose, when to call, input requirements, and output shape. Every sentence adds useful information, and the critical usage guidance is front-loaded before the detailed output contract.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given 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 the discriminated union result shapes, the not_tela fallback, and the known limitation about updateability. Combined with the rich annotations and complete param schema, an agent has everything needed to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description repeats the scid and topoheight requirements but adds minimal extra meaning beyond the schema, such as clarifying that the SCID refers to a TELA contract. No meaningful parameter behavior is undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description defines a composite fetch-and-parse action with a specific verb and resource, and names the exact TELA standards it detects. It distinguishes itself from generic tools like explain_smart_contract and dero_get_sc by explaining its specialized parsing behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does 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 for TELA-related queries, and explicitly says to prefer it over dero_get_sc plus manual parsing or explain_smart_contract. It also explains the limitation of the alternative, making the selection criterion actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true, but the description adds substantial context: the computation is offline, the optional cross-check behavior, the halving undercount display quirk, the exact error conditions if daemon is unreachable without a height, and the limited scope to schedule CalcSupply. This goes well beyond the annotation safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with clear sections: purpose, when to call, input requirements, and output. It front-loads the most decision-relevant information and every sentence adds value—such as the preference over GetInfo and the error condition. Length is justified by the tool's composite nature.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description fully explains the return shape, including the meaning of 'match', and provides related_docs. It covers error behavior, defaults, scope limitations, and the offline recompute approach. An agent has all the context needed to invoke and interpret this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and already explains height's default and the requirement when the daemon is unreachable. The description mostly repeats that information, adding only the concrete error outcome. Since the schema carries the parameter semantics, no additional meaning is needed, so the baseline of 3 holds.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'recompute DERO total supply offline via CalcSupply' and 'cross-check against DERO.GetInfo.total_supply.' It clearly distinguishes itself from GetInfo by stating 'PREFER this over reading GetInfo alone,' so an agent can identify this tool's unique role among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When to call' section explicitly lists trigger queries, then gives a concrete comparison to the alternative: GetInfo can undercount after halvings on older builds. It also excludes a non-goal ('NOT a UTXO census') and specifies the required height condition for unreachable daemons. This leaves no ambiguity about when to choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only annotation, the description discloses important behaviors: whitespace trimming, case consistency requirements, conditional presence of `value_interpretation`, silent attachment of `context_note`/`related_docs` for flagged artifacts, and `INVALID_BECH32` error codes. It also clarifies that a decode result is a display-layer fact, not a consensus statement. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured into labeled sections: purpose, when to call, critical input requirements, output shape, and documentation-citation guidance. It front-loads the core purpose before the detailed output contract. Each section earns its place given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description carries the full burden of explaining return values. It provides a detailed output contract, conditional fields, error behavior, and contextual caveats. It is complete enough for an agent to call the tool and interpret the result correctly without further documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaningful input semantics beyond the schema: the full string must include HRP and separator, the example format is reinforced, and BIP-0173 case consistency is explicitly required. This is genuinely useful for constructing valid calls.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Decode any DERO bech32 string... into its constituent parts'. It enumerates the supported HRPs and distinguishes the special `deroproof…` case where the public key is a derived blinder point, not a wallet pubkey. This clearly separates it from the sibling tools, none of which are decoders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
An explicit 'When to call' section states the triggering user request (pasting a `deroproof…` / integrated-address string to learn what it encodes). It also gives an explicit alternative to avoid: chaining bech32 decoders + CBOR libraries yourself. This is actionable guidance for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as readOnly and non-destructive, but the description adds substantive behavioral context: the first call triggers a ~10s one-time discovery scan, results are cached, dURLs are not unique, the newest match is returned as primary, collisions are disclosed, and exact output shapes on hit and miss are described. This goes well beyond what annotations reveal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear sections and front-loaded core purpose. It is dense with valuable detail, but it slightly repeats the dero_name_to_address routing instruction in both the 'When to call' section and the Input Requirements list, making it marginally less concise than ideal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, yet the description fully compensates by enumerating the exact output fields for both hit and miss cases, explaining collision behavior, first-call latency, caching, and how to follow up with tela_inspect. Nothing an agent needs to correctly invoke and interpret this tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema documents the durl parameter fully. The description adds useful semantics beyond the schema: case- and prefix-insensitivity, acceptance of 'dero://' prefixed inputs, and reinforcement that DERO names should not be passed here. This is a meaningful but not massive addition above the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('resolve'), a specific resource ('TELA dURL'), and the target ('on-chain SCID(s)'). It clearly distinguishes itself from dero_name_to_address by explaining that DERO names without dots are not TELA dURLs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit 'When to call' section with concrete user-phrase examples, and it names the alternative tool (dero_name_to_address) with the exact routing condition. It also explicitly states what this tool is NOT for.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses that the tool never broadcasts, never touches a wallet, never mutates chain state, constructs the string locally from public data, self-verifies before returning, and throws on self-check failure. This is rich behavioral context that annotations alone do not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but densely structured with sections for purpose, when to call, math, input requirements, output, and read-only behavior. Every section earns its place, and the most important scoping and safety information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four interdependent parameters and no output schema, yet the description compensates fully by enumerating all returned fields, explaining when ring_receiver_address is null, describing the self-check, listing related_docs, and noting diagnostics. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds critical semantics: exactly one of tx_hash or tx_hex must be provided despite no required schema fields, including the daemon-fetch vs raw-hex tradeoff. It also explains defaults, ring_slot bounds, fractional decimal format, and the negative-amount uint64 wraparound behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: forge a deroproof display object for an arbitrary transaction, ring slot, and amount. It clearly distinguishes itself from chain-inspection siblings by framing the result as a display-layer object and noting 'on the chain, nothing has changed.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When to call' section is explicit: use it when a user pastes a deroproof string and asks whether Verified means the chain minted coins, and forge a side-by-side refutation. It also names the docs reproduction use case. It does not enumerate when not to call or name alternatives, but the trigger context is specific enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive. The description adds context by detailing the output fields and emphasizing that no input is needed. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is brief, well-structured with clear sections, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and clear annotations, the description is complete. It lists output fields and usage context, making it self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, baseline is 4. The description adds value by listing output fields and usage context, exceeding baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves DERO daemon and chain metadata, listing specific fields. It distinguishes from siblings by recommending this before other chain-state tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to call (first in chain-state investigation) and recommends citing docs for verification. While strong, it could more directly mention alternative simpler tools like dero_get_height.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/non-destructive, and the description adds substantial behavior beyond that: the TX_NOT_FOUND structured error on unknown hashes, the 'empty record' failure mode it protects against, the explicit non-performance of SC invocation arg decoding with the reason (codec not bundled), the conditional sc_install nullability, and the raw_tx_hex_length hint that routes agents to dero_get_transaction for the binary. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Long but every sentence earns its place — this is a composite tool with no output schema, so the density is justified. The structure is optimally ordered: What → When → Input requirements → Output shape → Limitations → Error behavior. The summary is front-loaded so an agent can decide whether to read the details without scanning the whole block.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 params, no output schema, and complex conditional behavior, the description is nearly complete: it documents the full output shape, the sc_install null condition, error semantics, and the known limitation on arg decoding. One small blemish: the error section says the composite returns 'a structured _meta.error' while the output shape lists only _diagnostics, leaving the relationship between the two fields slightly ambiguous for an agent parsing the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 on top: it marks tx_hash REQUIRED with the 64-hex constraint front and center, explains the practical effect of decode=false (raw hex still comes back), and gives a use-case trigger for include_sc_context=false ('when you only need confirmation / ring info'). This exceeds the schema's mechanical definitions but is not a huge leap beyond them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence names a specific composite operation with concrete verbs — look up, classify, extract, stitch — and enumerates exact outputs: confirmation status (confirmed | mempool | unknown), kind (sc_install | transfer_or_invocation | coinbase | unknown), and inline SC surface for contract installs. It explicitly distinguishes itself from chaining dero_get_transaction with dero_get_sc, so an agent can tell it apart from siblings without opening their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit 'When to call' section listing concrete user intents ('what is this tx', 'is this confirmed', 'what contract did this deploy'), states it should be the FIRST step, and names the alternative pattern (chaining dero_get_transaction with dero_get_sc) with reasons to prefer the composite. It also explains why the alternative is unnecessary for SC installs (source is embedded in the tx record).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the annotations' readOnlyHint=true: it explains the composite nature, deterministic key sorting, TELA-first detection, heuristic docs page selection, and important edge behavior like has_code=false for unknown SCIDs. It also tells the agent when to fall back to dero_get_sc based on raw_code_length. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Although the description is long, it is tightly structured into purpose, when-to-call, input requirements, and output sections. Every sentence carries actionable information, and the most important usage guidance is front-loaded before parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates thoroughly by detailing the exact return shape, the kind enum values, the shape of surface.functions, and the fallback semantics of has_code and raw_code_length. Combined with clear input requirements and alternative routing, an agent has everything needed to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so a baseline of 3 applies, but the description adds real value by explicitly marking scid as REQUIRED with the 64-hex constraint, suggesting a known-good example, and clarifying that topoheight is optional and that omitting it uses the latest tip. This enriches the schema's terse descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair ('fetch a DERO smart contract ... and return its function surface, classification ... narrative, and curated DVM docs citations') and clearly differentiates itself from raw retrieval tools like dero_get_sc and deeper tools like tela_inspect. An agent can confidently understand what this tool does and why it exists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to call ('when the user wants to UNDERSTAND a smart contract'), tells the agent to PREFER this over chaining dero_get_sc with a docs lookup, and names tela_inspect as the alternative for deep TELA parsing. It even provides a known-good example SCID, leaving no ambiguity about invocation context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond annotations: it discloses that the tool throws INVALID_INPUT when no identifying input is provided, that chain_facts is null when daemon calls fail, that proof_decode and forge_demo are conditionally null, and that it joins against a flagged false-claim registry. It also reveals the demo amount auto-selection logic, which is valuable behavioral context not in the schema. No contradiction with readOnlyHint/destructiveHint/idempotentHint is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Although lengthy, the description is well-structured with clear sections (Composite, When to call, Input Requirements, Output, PREFER directives) and front-loads the core purpose. Each sentence carries operational value, and the critical at-least-one rule is not present in the schema, so the repetition in Input Requirements is justified rather than redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, the description provides a thorough output map: top-level fields, verdict semantics, null-condition behavior for chain_facts/proof_decode/forge_demo, and the slim forge_demo shape. It also covers error conditions, parallel execution, registry lookup, and documented citations, making the tool safely callable by an agent without prior context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 100%, but the description adds essential semantics: at least one of topoheight/block_hash/tx_hash/proof_string MUST be provided despite zero declared required params, and it adds format constraints (64 hex, full deroproof bech32 with HRP). For include_forge_demo it explains the default, the tx_hash precondition, and the intended rebuttal use case beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'audit a chain artifact... end-to-end' and clearly states the outputs (verdict, chain facts, proof decode, narrative, citations). It also differentiates itself from siblings by naming the exact composite operation and explicitly saying to prefer it over chaining 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.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit 'When to call' section with concrete user intents ('what's going on with DERO block X?', 'is this transaction the inflation-claim TX?', 'does this proof string come from a known false claim?'). It also states when NOT to chain manually, when to set include_forge_demo=true, and instructs the agent to cite related_docs verbatim.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral detail beyond the readOnly annotation, including pagination behavior with 60000-char chunks, the content_truncated and next_offset signals, and the meaning of content_length. This tells the agent exactly how to handle long pages and what to expect across repeated calls.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a one-line summary, a 'When to call' section, critical input requirements, and an output explanation. Every section carries necessary information, and the most important decision guidance appears near the top.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema present, the description compensates by specifying the exact output fields and explaining pagination-related fields. It also covers practical details like example slugs and product options, making the tool fully usable without external documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema covers 100% of parameters, the description adds critical semantic value: slug must be non-empty and relative to pages/, product is recommended to disambiguate duplicate slugs across docs sites, and offset has detailed chunking semantics with a clear retry instruction (pass next_offset when content_truncated is true).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Get a single bundled docs page by slug, with plain-text content and headings.' It clearly distinguishes this tool from sibling dero_docs_search and dero_docs_list by focusing on fetching one page by an exact slug rather than searching or listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: call it AFTER dero_docs_search returns a candidate slug, or when you already have a known slug from a prior citation. It also explicitly prefers dero_docs_search when only a topic is known, making the decision boundary unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this read-only and non-destructive, and the description adds meaningful behavioral detail: it never fabricates a breakdown when the daemon returns 0/0 with non-OK status, and it returns structured errors on DVM compile failure. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every section earns its place: purpose, when-to-use, input requirements, and output shape. It is well-organized with clear labels and no redundant repetition of schema-only details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description fully specifies the return shape, conditional null behavior, error behavior, and input constraints. For a composite tool with multiple moving parts, nothing critical is left unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds important semantics beyond schemas: sc must contain complete Function blocks or it fails with INVALID_INPUT, signer gives the daemon fee context but is optional, and include_breakdown defaults to true with a defined effect on output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific composite action: sending DVM-BASIC source to the daemon's gas estimator and returning the estimate, breakdown, contract surface, and docs. It clearly distinguishes itself from the sibling dero_get_gas_estimate by saying this composite should be preferred.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to call (before broadcasting a deploy tx or when explaining contract cost) and when to prefer it over dero_get_gas_estimate. Also gives concrete conditions for setting include_breakdown to false.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds substantial behavioral detail beyond annotations: 1.5x boost for product_hint matches, deduping across products, top-heading rationale, pre-built top-2 citations, and the NO_DOCS_MATCH error behavior. This is exactly the kind of context that helps an agent predict execution semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but appropriately structured: core behavior first, then when-to-call, input requirements, and output shape. Every section earns its place given the composite nature of the tool and the lack of an output schema. No filler or tautological content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully documents the return shape, including the recommended array, by_product summary, related_docs citations, and the zero-match error structure. It also covers when to use it, input constraints, and the ranking boost behavior, making it complete enough for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description meaningfully exceeds it. It explains the intent style recommendation ('Drop verbs and use product nouns'), the effect of product_hint as a 1.5x score multiplier, and the merging cap behavior of limit_per_product. This adds practical semantics beyond the raw schema field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: it fans out parallel scoped searches across all four DERO product docs and returns a ranked recommendation list with rationale and related_docs. It clearly differentiates itself from dero_docs_search by describing the composite behavior and the pre-built citations, so an agent can distinguish it from siblings without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When to call' section is explicit: call at the start of a docs-discovery investigation and BEFORE calling dero_docs_search directly. It also explicitly prefers this over guessing the product and explains when to pass product_hint, giving clear 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.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/DHEBP/dero-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server