RealCryptoCap: market cap without the stablecoins.
MCP tools for real crypto market cap, native Top 500, coin lookup, and market briefs.
API / CLI / MCP are Pro and Ultra only (paid). This is not a free MCP.
Plan | Price |
Pro | $25/mo or $250/yr |
Ultra | $59/mo or $588/yr |
You need a RealCryptoCap API key (rci_...) from realcryptocap.com/account.
Unauthenticated calls fail. Pro/Ultra subscription required.
Separate limited free surface: WebMCP on the site pages except Market Data (index / search / open page / ask AI). That is not these MCP data tools.
Docs: https://realcryptocap.com/api
Get access: https://realcryptocap.com/pro
Related MCP server: mcp-market-data
npx -y github:node0datasystems-lgtm/realcryptocap-mcpPackage name on npm is not reserved. Use the GitHub install form above, or clone and run
node server.mjs.
Or add to Claude Desktop / Cursor / any MCP client:
{
"mcpServers": {
"realcryptocap": {
"command": "npx",
"args": ["-y", "github:node0datasystems-lgtm/realcryptocap-mcp"],
"env": {
"RCI_API_KEY": "rci_your_paid_pro_or_ultra_key",
"RCI_BASE": "https://realcryptocap.com"
}
}
}
}get_real_market_cap — Real crypto market cap, excluded buckets, BTC dominance
list_top_coins — Top N native cryptocurrencies (stables/wrapped/tokenized excluded)
get_coin — Single coin snapshot by CoinGecko id
market_brief — Machine-readable market brief
Stablecoins, wrapped/staked receipts, tokenized stocks, bonds, treasuries, RWAs, commodities, and other non-native assets.
contact@realcryptocap.com · https://realcryptocap.com
Dockerfile runs node server.mjs as CMD (non-root). It answers MCP introspection (initialize, tools/list) without a key; data tools require a paid Pro/Ultra RCI_API_KEY.
Get a single coin snapshot (price, market cap, 24h/7d change) by CoinGecko id, e.g. "ethereum".
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | CoinGecko coin id, e.g. bitcoin |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. 'Get' and 'snapshot' imply a safe read operation, and the returned fields are named, but it does not mention freshness, rate limits, auth requirements, or behavior for invalid ids.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no wasted text. It packs the resource, returned fields, input format, and example into one concise statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter lookup tool, the description sufficiently explains the input identity and the snapshot contents returned. It lacks some operational context such as error handling or data freshness, but no output schema exists and the returned fields are at least listed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already documents the id parameter as a CoinGecko coin id with an example. The description adds an example ('ethereum') but does not add meaning beyond the structured schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: getting a single coin snapshot, and names the returned fields (price, market cap, 24h/7d change). It distinguishes this from sibling list tools through 'single coin', though it does not explicitly contrast with get_real_market_cap or market_brief.
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 'by CoinGecko id' and 'single coin', suggesting this is the lookup tool for one known coin. However, it does not explicitly say when to use it versus get_real_market_cap, list_top_coins, or market_brief.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the REAL total crypto market cap — stablecoins/fiat pegs, wrapped/staked assets, tokenized stocks/funds/treasuries/RWA, commodities and other non-native assets excluded — plus headline sample cap, excluded market-cap breakdown, real BTC dominance and native coin count.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose genuinely important behavior: the exact eligibility rules (what is excluded) and the full composition of the return (headline sample cap, excluded breakdown, real BTC dominance, native coin count). It omits any statement about read-only nature, auth, or rate limits, but for a public metric fetch the omission is minor.
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 dense sentence, but it is front-loaded with the verb and the headline metric before piling on the qualifiers, so an agent gets the gist immediately. Every clause (the exclusion list, the returned sub-fields) adds information rather than restating the name.
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 and no annotations, the description does the heavy lifting by enumerating the returned fields and the counting rules, which is enough for an agent to call a zero-parameter tool correctly. It stops short of explaining units, update cadence, or freshness of the metric.
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. No parameter behavior is misdescribed.
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 and a very precisely scoped resource ('REAL total crypto market cap') with an explicit exclusion list, so an agent knows exactly what metric is produced. It does not, however, differentiate itself from siblings like market_brief, which could plausibly also return market aggregates.
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 methodology: this is the tool to call when you need a stablecoin/wrapped/RWA-free market cap rather than a headline figure. There is no explicit when-to-use vs. when-not guidance and no sibling is named as an alternative, so the agent must infer the routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the top N native cryptocurrencies by real market cap (stablecoins, wrapped/staked receipts, tokenized securities/RWA and commodities removed).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many coins (1-500, default 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden alone. It usefully discloses the inclusion methodology (stablecoins, wrapped/staked receipts, tokenized securities/RWA and commodities excluded), which is real behavioral context beyond the schema. However, it says nothing about ordering, tie-breaking, pagination, or how results are returned for a list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the verb and resource, with the exclusion criteria compactly placed in a parenthetical. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool with no output schema, the description supplies the essential ranking and filtering semantics. It is close to complete, though ordering behavior and what each entry contains are left unstated.
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 'limit' parameter is fully documented with its range and default in the schema. The description's 'top N' only restates the parameter's meaning, adding no syntax or format detail beyond what the schema already provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('top N native cryptocurrencies') and even defines the ranking basis ('real market cap'). It does not explicitly name its siblings (get_coin, get_real_market_cap, market_brief), but the ranked-list framing makes it distinguishable from the single-coin lookup tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: call this when you need a ranked list of top coins rather than data on one coin. There is no explicit when-to-use/when-not-to-use guidance and no reference to the sibling tools that would clarify the boundary, so it remains inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A machine-readable market brief: real cap, excluded-cap/category breakdown, breadth, top 5, biggest 24h gainers.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It describes the data returned but does not state that the operation is read-only, has no side effects, or has any freshness/rate-limit characteristics. For a zero-parameter aggregation tool, these omissions are not critical but remain gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently lists the brief's components. Every word earns its place, and there is no redundant or filler text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity, empty input schema, and absence of an output schema, the description adequately lists what the brief contains. However, it does not describe the output structure or format beyond 'machine-readable', leaving some ambiguity about how the data is organized.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter semantics to document. Baseline score of 4 applies because the empty schema is fully consistent with the tool's nature.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a 'machine-readable market brief' and enumerates its contents (real cap, excluded-cap/category breakdown, breadth, top 5, biggest 24h gainers). This is a specific resource with scope, but it does not explicitly distinguish itself from siblings like get_real_market_cap or list_top_coins.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the sibling tools. There is no mention of alternatives, prerequisites, or exclusions. An agent must infer usage context entirely from the tool name and contents list.
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.
v0.1.0get_coinget_real_market_caplist_top_coinsmarket_briefScored across 4 tools
The four tools are mostly distinct, but get_real_market_cap and market_brief overlap significantly because market_brief also returns real cap and excluded-cap breakdowns. list_top_coins also overlaps with market_brief's fixed top-5 section, so an agent could reasonably choose either for top-coin summaries.
Three tools follow a clear verb_noun snake_case pattern (get_real_market_cap, list_top_coins, get_coin), while market_brief is a noun phrase without a verb. The deviation is minor and the names remain readable and consistent in casing.
Four tools are well-scoped for a focused crypto market-cap server: one aggregate metric, one ranked list, one single-coin lookup, and one summary brief. Each tool has a plausible role without excessive surface area.
The set covers the core market-cap workflows: total real cap, top native coins, individual coin snapshots, and a market brief with gainers. Minor gaps exist around historical data or coin search, but agents can work around them for the stated purpose.
Paid market-data MCP: crypto, equities, smart-money, macro, wallet PnL. x402 per call on Base.
Free read-only crypto whale-tracking & market-data MCP tools across 14 chains. No auth.
Crypto MCP with 21 tools for market data, DeFi, analytics, and sentiment. Post-paid USDC billing.
Pay-per-call DeFi and macro intel for AI agents. x402 USDC tools via streamable HTTP /api/mcp.
