Which integrations are available for this server?

Provides tools for querying live indexed data from the Dogecoin ecosystem, including Doginals, Dunes, DRC-20, and other metaprotocols.

How do I use doge-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@doge-mcp get details for inscription dogecoin:12345" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

doge-mcp

by jonheaven

Overview Schema Source Related Servers Score Discussions Admin

JavaScript

Hybrid

doge-mcp

Paid Model Context Protocol server for the Dogecoin / Dogenals ecosystem.

AI agents and developers query live indexed Doginals, Dunes, DRC-20, ÐMP, Treats, ÐLotto, etc. through a clean MCP interface. Indexer operators running dogex get paid for serving the data.

Part of the Dogenals + dogex stack.

Why this exists

dogex is the deterministic chain-truth + metaprotocol indexer.
Multiple independent operators can run dogex and stay in sync (federation fingerprint).
AI agents should not get high-value index data for free.
MCP + micropayments (x402) is the cleanest way to charge agents per tool call in 2026.

This server is the first public surface that turns “running a dogex indexer” into a revenue activity while keeping the open standards free.

Related MCP server: thegraph-mcp

Quick start (local / free tier)

git clone https://github.com/jonheaven/doge-mcp.git
cd doge-mcp
npm install
npm run build

# Point at a running dogex instance
export DOGEX_URL=http://127.0.0.1:8080   # or https://dogex.command.dog etc.

npm start

Add to Claude Desktop / Cursor MCP config:

{
  "mcpServers": {
    "doge-mcp": {
      "command": "node",
      "args": ["/absolute/path/to/doge-mcp/dist/index.js"],
      "env": {
        "DOGEX_URL": "https://your-dogex-instance.example.com"
      }
    }
  }
}

Or run via npx once published.

Current tools (v0.1)

Tool	Description	Intended pricing
`dogex_health`	Federation health + tip + fingerprint	Free
`get_inscription`	Fetch inscription by ID	Free / low
`list_protocols`	Supported metaprotocols	Free
`get_collection_stats`	Collection floor / volume / supply	Paid (soon)
`get_address_holdings`	Holdings for an address	Paid (soon)
`decode_inscription`	Decode + content-hash / schema check	Free → paid

More tools (PSBT helpers, range queries, proofs, analytics) will be added as dogex endpoints solidify.

Paid model (roadmap)

v0.1 (now) — Working MCP that talks to any dogex instance. Free for basic tools.
v0.2 — Wrap high-value tools with x402 (paidTool). Agents pay in USDC (Base) or later DOGE-native rails. Operators set their own recipient address.
v0.3+ — Multi-operator discovery + federation-aware routing. Agents prefer healthy, matching-fingerprint indexers. Revenue stays with the runner who served the query (optional small protocol fee).

Standards (dogenals/spec) stay free and public. You are selling live indexed state + computation, not the rules.

Environment

Variable	Description	Default
`DOGEX_URL`	Base URL of a dogex HTTP API	`http://127.0.0.1:8080`
`DOGEX_API_KEY`	Optional bearer token if the indexer is gated	—
`RECIPIENT_ADDRESS`	(future) x402 payment recipient	—

Development

npm run dev          # tsx watch
npm run typecheck
npm run build

dogenals — normative standards & docs
dogex — Rust node + deterministic indexer (chain truth)
x402 — open micropayment protocol for agents

Much paid. Very index. Wow.

Available Tools

6 tools

decode_inscriptionB

Decode raw inscription content / OP_RETURN and check content-type + content-hash consistency against Dogenals rules

ParametersJSON Schema

Name	Required	Description	Default
`raw`	Yes	Hex or base64 of the inscription payload / witness

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description must reveal behavioral traits. It only states what the tool does, not side effects, error behaviors, rate limits, or return format. For a non-read-only tool (assumed), this is insufficient.

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

Conciseness4/5

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

Single sentence, front-loaded with the action, no redundancy. However, the use of slashes and plus signs slightly reduces readability, but overall efficient.

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

Completeness2/5

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

No output schema exists, so the description should explain the return value. It does not mention what the decoded output looks like or how consistency results are reported. Lacks completeness for a decoding tool.

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

Parameters3/5

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

Schema coverage is 100% with a description for the only parameter 'raw' specifying format (hex or base64) and context (payload/witness). The tool description does not add additional parameter semantics beyond what is already in the schema.

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

Purpose5/5

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

Description specifies the action (decode and check), the resource (raw inscription content/OP_RETURN), and the specific checks (content-type, content-hash consistency). It clearly distinguishes from siblings like get_inscription which fetch inscription data rather than decode raw content.

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

Usage Guidelines3/5

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

The description implies usage when one has raw inscription payload to decode and validate, but does not explicitly state when to avoid or provide alternatives. No guidance on prerequisites or context.

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

dogex_healthA

Check whether the connected dogex indexer is healthy and return federation fingerprint + tip

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.6/5.0

Behavior2/5

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

With no annotations provided, the description must disclose behavioral traits. It only mentions the return values but not side effects, authentication needs, or rate limits. The tool is likely read-only, but this is not stated.

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

Conciseness5/5

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

Single sentence with no unnecessary words. The main action is front-loaded. Perfectly concise for a simple health check tool.

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

Completeness4/5

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

For a tool with no parameters and no output schema, the description gives sufficient context about its purpose and return values. However, it could specify the data types of federation fingerprint and tip.

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

Parameters4/5

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

The input schema has no parameters, so the baseline is 4. The description adds value by explaining the purpose and output, compensating for the empty schema.

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

Purpose5/5

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

The description clearly states the tool checks indexer health and returns specific data (federation fingerprint + tip). It uniquely distinguishes itself from sibling tools like list_protocols and get_inscription.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives, nor any prerequisites or conditions. The description only states what it does without context.

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

get_address_holdingsA

List Doginals / Dunes / Treats holdings for a Dogecoin address. Higher-value query — good candidate for micropayment.

ParametersJSON Schema

Name	Required	Description	Default
`address`	Yes	Dogecoin address (D... or legacy)

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description carries the burden. It hints at resource cost ('higher-value query') but does not disclose other behavioral traits like rate limits or error conditions.

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

Conciseness5/5

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

Two concise sentences with no unnecessary words, front-loaded with purpose then usage hint.

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

Completeness4/5

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

For a simple tool with one parameter and no output schema, the description adequately covers purpose and cost implications, though it could mention response format.

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

Parameters3/5

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

Schema coverage is 100% and the parameter description in the schema already explains the address format. The tool description adds no additional meaning beyond the schema.

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

Purpose5/5

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

The description clearly states it lists Doginals, Dunes, and Treats holdings for a Dogecoin address, which is a specific verb and resource, and it distinguishes from sibling tools like list_protocols or decode_inscription.

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

Usage Guidelines3/5

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

The description includes 'Higher-value query — good candidate for micropayment' which implies usage guidance about cost, but it does not explicitly state when to use or not use this tool versus alternatives.

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

get_collection_statsB

Get collection-level stats (floor, volume, supply, holders) for a Doginals collection. Intended to become a paid tool.

ParametersJSON Schema

Name	Required	Description	Default
`collection`	Yes	Collection ticker or ID

TDQS

B3.4/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It does not state whether the tool is read-only, requires authentication, or any other behavioral traits. Only mentions a future pricing change.

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

Conciseness5/5

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

Two concise sentences front-load the purpose and add a single additional note. No unnecessary words or redundancy.

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

Completeness2/5

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

Lacks details on return format, error handling, or behavior when a collection is not found. Since no output schema exists, the description should compensate but does not.

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

Parameters3/5

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

The single parameter 'collection' has a description in the schema that is identical to the description's mention. Schema coverage is 100%, so the description adds no extra meaning beyond what the schema already provides.

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

Purpose5/5

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

Clearly states the verb 'Get', the resource 'collection-level stats', and specifies the data (floor, volume, supply, holders) for Doginals collections. Distinct from siblings like get_inscription (individual) and get_address_holdings.

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

Usage Guidelines3/5

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

Provides no explicit guidance on when to use this tool vs. alternatives. The note about becoming a paid tool implies future cost but does not clarify current usage context or exclusions.

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

get_inscriptionA

Fetch a Doginals / Dogenals inscription by ID (txid:i or content hash). Free for basic metadata; heavy content may later be paid.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Inscription ID (e.g. txid:0) or content hash

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations, the description discloses a behavioral trait: free for basic metadata but may later be paid. However, it does not state read-only nature, authentication requirements, or error handling, leaving gaps.

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

Conciseness5/5

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

The description is concise: one sentence that directly conveys the purpose and key behavioral note. No superfluous words.

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

Completeness3/5

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

For a simple 1-parameter tool with no output schema, the description covers the input and behavioral note. It lacks return value details and examples, which would improve completeness.

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

Parameters3/5

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

Schema coverage is 100% with a clear description for the single parameter 'id'. The description adds no extra parameter semantics beyond payment context, but the baseline of 3 is appropriate.

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

Purpose5/5

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

The description clearly states the tool fetches a Doginals/Dogenals inscription by ID or content hash. The verb 'Fetch' and resource 'inscription' are specific, and the distinction from sibling tools (e.g., list_protocols, decode_inscription) is implicit.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. The description does not mention prerequisites, when not to use it, or how it compares to sibling tools like decode_inscription.

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

list_protocolsA

List supported Dogenals / Doginals metaprotocols known to this dogex instance

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It states the tool lists protocols but does not disclose additional behavioral traits like response format, the meaning of 'supported', or any prerequisites. Basic transparency is present but minimal.

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

Conciseness5/5

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

Single sentence that is front-loaded with the action and resource. No extraneous information.

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

Completeness4/5

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

Given zero parameters and no output schema, the description is nearly complete for a simple list tool. It could briefly mention that it returns names of protocols, but the current description is adequate for its simplicity.

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

Parameters4/5

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

No parameters exist in the schema (100% coverage trivially). Baseline score for zero parameters is 4; description does not need to add parameter details.

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

Purpose5/5

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

Description clearly states the action ('List') and the resource ('supported Dogenals / Doginals metaprotocols known to this dogex instance'). It distinguishes from sibling tools like get_inscription or get_collection_stats, which have different purposes.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. The description does not provide any context for selecting it among siblings, such as when to list protocols before using other tools.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv0.1.0Jul 28, 2026
- First observeddecode_inscription
- First observeddogex_health
- First observedget_address_holdings
- First observedget_collection_stats
- First observedget_inscription
- First observedlist_protocols

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0

Scored 2026-07-28 16:45 across 6 tools

Disambiguation5/5

Each tool targets a distinct function: listing protocols, health check, fetching inscription, collection stats, address holdings, and decoding. No two tools have overlapping purposes, making it clear which to use.

Naming Consistency4/5

Most tools follow a verb_noun pattern (e.g., get_inscription, list_protocols), but 'dogex_health' deviates slightly as it lacks a verb. Still, all are snake_case and readable.

Tool Count5/5

With 6 tools, the server is well-scoped for a Doginals indexer. Each tool serves a necessary function without bloat or deficiency.

Completeness4/5

Core operations like fetching inscriptions, querying holdings, and decoding are covered. Missing a tool to list all collections or search, but the set handles essential workflows.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp A
com.everstake
MCP server connecting AI agents to non-custodial staking data across 130+ networks.
Blockchain Cryptocurrency
1111
UnifAPIOAuth
com.unifapi
Hosted MCP server for live public-data APIs and Skills for AI agents.
Open Data Search AI & Machine Learning
2
crypto-defi-mcpOAuth
com.thenextgennexus
MCP server giving AI agents one-connection access to crypto & DeFi data: DeFi protocol TVL, stableco
Cryptocurrency Finance Blockchain
2
FindAgent AOAuth
cloud.findagent
The vetted, cross-LLM marketplace of doer agents — itself an MCP server.
Autonomous Agents Agent Orchestration
532

Related MCP Servers

crypto-projects-mcp
Cryptocurrency Blockchain
kukapay
A
license
B
quality
F
maintenance
An MCP server that provides cryptocurrency project data to AI agents
Updated a year ago (2025-05-11 12:57 UTC)
1
1
MIT
thegraph-mcp
Blockchain Web3 & Decentralized Tech Search
Data-Nexus-Web3
A
license
A
quality
D
maintenance
An MCP server that powers AI agents with indexed blockchain data from The Graph.
Updated 7 months ago (2026-02-21 06:37 UTC)
3
MIT
GenTech Agent Kit
Cryptocurrency Finance Blockchain
ProtoJay4789
A
license
C
quality
A
maintenance
An MCP server that gives AI agents real-time market data, DeFi intelligence, and automatic tool discovery via plugins. Supports x402 micropayments and is always updated.
Updated 2 months ago (2026-07-15 17:27 UTC)
23
MIT
dgb-chain-mcp
Blockchain Cryptocurrency
dgb-tools
A
license
Not graded
quality
B
maintenance
MCP server that lets AI agents query live DigiByte blockchain data: network health, DigiDollar stats, oracle status, prices, address balances, transactions, and blocks.
Updated 2 months ago (2026-07-15 14:30 UTC)
16
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/jonheaven/doge-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server