Dogecoin blockchain lookups: transactions explained, addresses, blocks, fees, supply and charts.
Scored across 9 tools
Most tools target clearly distinct resources: address, block, transaction, chart, rich list, supply. However, get_network is a composite overview that overlaps with get_fees (next-block fees), get_block (latest blocks), and get_transaction (biggest transfers), creating minor potential confusion despite the descriptions.
Eight of nine tools use a predictable get_<resource> snake_case pattern, which is easy to follow. The lone helper find breaks the pattern intentionally but is still a clear verb, so this is only a minor deviation.
Nine tools is well-scoped for a Dogecoin blockchain explorer/analytics server. Each tool covers a distinct data area and none feels redundant or excessive.
The surface covers the core read-only blockchain explorer domain: addresses, blocks, transactions, network status, fees, charts, rich list, and supply. The find helper also handles query routing, leaving no obvious dead ends for typical Dogecoin data queries.
Works out whether a string is a Dogecoin block height, block hash, transaction id or address, and which tool to call next. Use it when unsure.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | A block height, block hash, transaction id or address. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the description only needs to add behavior beyond that. It does add meaningful context: the tool's output is a classification plus a recommended next tool, which is the key behavioral trait for a router. It does not describe output shape or ambiguity handling, keeping it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero filler: the first explains what it resolves and returns, the second front-loads the usage trigger. Nothing is redundant with the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining returns, and it does say the tool determines the type and which tool to call next. It could be slightly more explicit about what the response looks like or what happens on ambiguous input, but it is adequate for a one-parameter router.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter is fully documented, so the baseline is 3. The description's enumeration of accepted string kinds mirrors the schema rather than adding syntax, length limits, or format guidance beyond it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (classify/resolve) and resource (a string against Dogecoin types: block height, block hash, transaction id, address) plus the follow-on action of naming the next tool. It is clearly distinguishable from the get_* siblings, which fetch a specific entity rather than routing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Use it when unsure" gives an explicit trigger condition, and the classifier framing implies that when you already know the type you should call get_block/get_transaction/get_address directly. The inverse condition is implied rather than spelled out, so it falls short of a full when/when-not statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A Dogecoin address: balance (with its dollar value), totals received and sent, transaction count, its mining-pool name if any, rank among the largest holders, lookalike warnings, and its history newest first, 10 a page.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page, from 1 (default 1). | |
| address | Yes | A Dogecoin address, e.g. D8AXXiGEZeZnMKTKnC9AWB3YUU4jfMAmYU. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered. The description usefully adds that history is returned newest-first in pages of 10, which is genuine pagination behavior beyond the annotations. It does not say what happens for an unknown or invalid address, so this stays at an adequate-but-not-rich 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the resource, and every listed item maps to real output content. It is a dense enumeration rather than a sprawling description, though the comma-run list is slightly heavy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must carry the burden of describing returns, and it does so thoroughly — balance, dollar value, sent/received totals, tx count, pool, rank, warnings, and paginated history. The main gap is error/edge-case behavior for unknown addresses, which is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented in the schema. The description only adds the incidental '10 a page' detail, which loosely informs the page parameter but provides no format or edge-case guidance. Baseline 3 is correct when the schema carries the load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a precise resource (a Dogecoin address) and enumerates exactly what the record contains: balance with dollar value, sent/received totals, tx count, pool name, holder rank, lookalike warnings, and history. Its scope is clearly distinct from siblings like get_transaction, get_block, and get_rich_list. It never states an explicit retrieval verb, but the attribute list makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no statement of when NOT to use it, and no pointer to an alternative such as get_rich_list for rankings or find for address lookup. The agent must infer that this is the per-address detail tool entirely from the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A Dogecoin block: when it was found, who mined it (pool name and payout address), reward and fees, size, confirmations, and its transactions as one-line stories, 25 a page.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page, from 1 (default 1). | |
| block | Yes | A height, a 64-hex block hash, or "latest". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds one genuinely behavioral fact — transactions are paginated at '25 a page' — but stays silent on auth needs, rate limits, and how a missing block is handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that lists the payload without padding. It is dense but every clause carries a distinct field, so nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must convey return shape, and it does so thoroughly — identify, mining, economics, size, confirmations, and paginated transactions. Combined with annotations covering safety and the complete input schema, only troubleshooting details (invalid block, page overflow) are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both 'block' (height, 64-hex hash, or 'latest') and 'page'. The description's only supplemental parameter meaning is the 25-per-page page size, which is the baseline 3 for a schema that does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description makes clear this returns a Dogecoin block and enumerates the fields (when found, miner/pool, payout address, reward, fees, size, confirmations, transactions) — enough to separate it from get_transaction or get_address. It never states the verb outright ('retrieve/fetch a block by height, hash, or latest'), relying on the name for that, so it falls just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as find or get_transaction. The agent gets an inventory of returned fields but nothing that routes it to this tool over its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A Dogecoin chart series over time, oldest first: e.g. tx_count, fees_median, hashrate, difficulty, supply, price_usd, block_interval, active_addresses, pool_share, holder_share.
| Name | Required | Description | Default |
|---|---|---|---|
| last | No | How many of the latest points (default 30). | |
| series | Yes | ||
| interval | No | Default day. minute is for tx_per_min only; pool_share, transfers and holder_share come by day or hour. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact not in the structured data: results are returned oldest-first.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that leads with what the tool returns. The ten-item series list is somewhat redundant against the schema enum, but it is compact and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining the return value; it says 'chart series over time, oldest first' but never describes the shape of a point (timestamp plus value). For a required-series, enum-driven chart tool this is adequate but leaves a real gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%; the schema already documents 'last' (default 30) and 'interval' constraints. The description's series list gives semantic meaning to enum values the schema only names, but it is an incomplete 'e.g.' subset of the 18-value enum and adds no format or syntax detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (a Dogecoin chart series over time) and enumerates concrete series names, so the agent knows exactly what data comes back. It does not, however, distinguish this generic time-series tool from focused siblings like get_supply, get_fees or get_network, which return overlapping data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance and no mention of alternatives, even though get_supply and get_fees clearly overlap with the supply and fees_median series listed here. The agent is left to infer the routing decision on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What it costs to send DOGE right now: the least a payment can pay, what people actually paid lately, next-block fee rates and how many transactions are waiting.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly=true, idempotent=true, destructive=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: this is a real-time estimate, it includes empirical recent payment data, and it quantifies mempool congestion. It does not state the freshness/staleness window or units, but it meaningfully enriches the picture.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with a front-loaded definition of the tool's subject, followed by a tight colon-separated list of the returned data. Zero filler; every clause names a distinct piece of information the caller receives.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no input schema and no output schema, the description is the only source of return-value information, and it does enumerate the four content categories. It omits units/formatting and the recency basis of 'lately,' so it is good but not exhaustive for a tool whose entire contract lives in prose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate. The baseline of 4 applies; no parameter-level detail is needed or expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific resource — current DOGE fee conditions — and enumerates the four concrete data points returned (minimum relayable payment, recent paid fees, next-block rates, pending transaction count). It is clearly distinct from siblings like get_block, get_transaction, and get_network, which cover different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'right now' implies this is a live-snapshot lookup, so the agent can infer it answers 'what will it cost to send DOGE at this moment.' There is no explicit when-to-use statement, no exclusions, and no named alternatives, so usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The Dogecoin network now: the newest block, the mempool and next-block fees, hashrate, difficulty, the latest blocks and the biggest recent transfers.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered structurally. The description's contribution is the enumeration of returned data, which is mildly useful but does not disclose anything about freshness windows, caching, or data staleness for a 'right now' snapshot.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the subject ('The Dogecoin network now') and then lists payload contents compactly. No filler, no restatement of the title, nothing to trim.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must convey what comes back, and the content list does that adequately for a zero-parameter snapshot tool. It falls short only on freshness/refresh semantics and on routing guidance against the heavily overlapping get_fees and get_block siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, which is the baseline-4 case; there is nothing for the description to disambiguate. No parameter text is needed and none is missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (the Dogecoin network state right now) and enumerates the concrete payload: newest block, mempool/next-block fees, hashrate, difficulty, latest blocks, biggest recent transfers. This distinguishes it reasonably well from point-lookup siblings like get_block or get_transaction, though it does not explicitly contrast with the overlapping get_fees or get_chart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance at all: nothing says to prefer this over get_fees for fee questions or over separate get_block calls for block data, and no exclusions are given. The agent must infer that this is a bundled snapshot tool purely from the content list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The 1,000 addresses holding the most DOGE, 100 a page, with how concentrated holdings are. Big holders are often exchanges.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page 1 to 10 (default 1). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered. The description adds real behavioral context the annotations lack: the fixed 1,000-address universe, a 100-rows-per-page chunking, and that a concentration measure comes back with the list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the resource and size, followed by the return-content note. Every clause carries information; nothing is padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-param, read-only tool with annotations covering safety and no output schema, the description supplies the universe size, pagination granularity and a result-field hint. Only the exact response shape is left unspecified, which is acceptable here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the page parameter is documented with its 1-10 range, so the baseline is 3. The description adds meaning beyond the schema by tying page size to 100 rows and the list to 1,000 addresses, explaining why the page ceiling is 10.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource and scope: the top 1,000 DOGE-holding addresses plus a concentration metric. An agent can tell this apart from get_address or get_chart without opening the schema, though the description never explicitly names a sibling it is not.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use, when-not-to-use, or alternative routing is given. 'Big holders are often exchanges' is interpretive context about the data, not guidance on selecting this tool over its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How many DOGE exist, how many are added each day and year (10,000 per block, no maximum), and inflation now and ahead.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorldHint=false, so the safety profile is fully covered by structured fields. The description adds content-level detail (10,000 per block, no maximum) but says nothing about freshness, block-height dependency, or format — appropriate for a no-side-effect read, but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that covers the three returned quantities with no padding. Slightly informal phrasing ('inflation now and ahead') costs a little precision but wastes no space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool with no output schema, the description does the necessary work of telling the agent what the response will contain. Missing only minor details such as units or the block height the figures are relative to.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; the schema is empty and consistent with the no-input nature of the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (DOGE supply) and enumerates exactly what it returns: current supply, per-block issuance, and inflation figures. It is clear and specific, though it never states a verb or explicitly differentiates itself from siblings — differentiation isn't needed here since no sibling overlaps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to call this tool, when not to, or what alternative to prefer. The agent must infer usage purely from the name and the returned data described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A Dogecoin transaction in plain English: who paid whom, how much, the likely change, the fee, its confirmations, every input and output, and any address-poisoning (lookalike) warning.
| Name | Required | Description | Default |
|---|---|---|---|
| txid | Yes | The transaction id: 64 hex characters. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so safety is covered. The description adds genuinely new behavioral context: it discloses the decoded semantic fields returned (likely change, address-poisoning warning), which an agent cannot infer from the annotations or a one-string schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the core idea ('A Dogecoin transaction in plain English') followed by an enumeration of what is returned. The list is somewhat long but each item is a real output field, so little is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden and does so by enumerating the decoded fields, including the non-obvious address-poisoning warning. For a single-parameter read tool it is essentially complete, lacking only edge-case behavior for unknown txids.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single parameter with 100% schema description coverage including a regex pattern, so the schema fully carries parameter meaning. The description adds nothing about the txid beyond implying it identifies a transaction, matching the baseline for fully documented params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names the resource (a Dogecoin transaction) and specifies exactly what is produced: payer/payee, amount, change, fee, confirmations, inputs/outputs, plus a poisoning warning. It is clearly the single-transaction explainer among siblings, though it does not explicitly contrast itself with find or get_block.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the required txid parameter — call it when you already have a 64-hex transaction id. There is no explicit when-to-use or when-to-use-something-else guidance, and no mention of the sibling 'find' as the alternative for looking a txid up.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
findget_addressget_blockget_chartget_feesget_networkget_rich_listget_supplyget_transactionExplore blockchain data across addresses, tokens, blocks, and transactions. Investigate any transa…
Blockchain intelligence for tracing funds, screening addresses, and investigating on-chain activity.
Read-only Solana and crypto reserve-recovery scans, pricing, chain facts, and methodology.
Wanchain explorer and analytics. Premium data: prepaid credit or standard x402 (0.01 USDC/request).
Add one secure layer between your agents and this server.