This server is a read-only, keyless CoinMarketCap MCP server exposing narrow, typed tools that return the provider's raw status/data envelope for market research — no credentials, no writes, no trading.
Resolve asset identity: cmc_crypto_map turns symbols/names into canonical CMC IDs and identifiers (sort by id or cmc_rank, listing status filter, up to 500 records).
Read static metadata: cmc_crypto_info returns metadata for known coins by CMC IDs, slugs, or symbols.
Get current market prices: cmc_quotes_latest fetches latest quotes for a known asset set (IDs/slugs/symbols), converting to up to 3 currencies.
Scan the market broadly: cmc_listings_latest gives a ranked, paginated market list with many sort fields (market cap, volume, percent changes) and asc/desc direction.
Read aggregate market state: cmc_global_metrics_latest returns total market cap, volume, and dominance.
Gauge sentiment: cmc_fear_greed_latest and cmc_fear_greed_historical (paginated daily series) expose the Crypto Fear & Greed Index.
Track altcoin rotation: cmc_altcoin_season_latest and cmc_altcoin_season_historical (7d/30d/90d timeframes) expose the Altcoin Season Index.
Read index data: cmc_cmc100_latest/cmc_cmc100_historical and cmc_cmc20_latest/cmc_cmc20_historical return index values, constituents, and weights, with bounded history (max 10 points, 5m/15m/daily intervals, explicit time window).
Operate safely: every tool is a fixed allowlisted GET route over https://pro-api.coinmarketcap.com/public-api, rejects unknown arguments, enforces bounded limits/pagination, uses no API key or auth header, and passes provider text through verbatim (treat as untrusted).
Note: this schema lists 13 tools; the project documents 20 total, with the remaining 7 (simple price, categories, price conversion, exchange map, and two DEX tools) not present here.
Provides read-only access to selected CoinMarketCap Keyless Public API routes for cryptocurrency data, including asset mapping and metadata, latest quotes and ranked listings, global market metrics, Fear & Greed and Altcoin Season indices, and CMC100/CMC20 index values and history.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@coinmarketcap-keyless-mcp what's the current price of bitcoin and ethereum?"
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.
coinmarketcap-keyless-mcp is a bounded, read-only Model Context Protocol (MCP) server for selected CoinMarketCap Keyless Public API routes. It requires no CoinMarketCap account, API key, secret, wallet, or authentication header. Upstream access is fixed to https://pro-api.coinmarketcap.com/public-api and uses GET only.
The surface is deliberately narrow: exactly 20 typed tools, each mapped to one allowlisted route. These are the 13 v1 tools, plus five Standard tools and two read-only DEX identity tools added in v1.1 (see V1_1_PLAN.md). It does not expose a generic URL/path proxy, authenticated fallback, or any other DEX route.
Tool | Route | Purpose |
|
| Resolve canonical CoinMarketCap IDs and identifiers. |
|
| Read static metadata for known assets. |
|
| Read current quotes for known assets. |
|
| Read a ranked, paginated current market list. |
|
| Read aggregate market capitalization, volume, and dominance metrics. |
|
| Read the current Fear & Greed value and classification. |
|
| Read paginated historical Fear & Greed values. |
|
| Read the current Altcoin Season Index snapshot. |
|
| Read Altcoin Season Index history for a supported timeframe. |
|
| Read the current CMC100 value, constituents, and weights. |
|
| Read bounded CMC100 historical values. |
|
| Read the current CMC20 value, constituents, and weights. |
|
| Read bounded CMC20 historical values. |
|
| Read the latest simple price for known assets. |
|
| List cryptocurrency categories and their IDs. |
|
| Read one category and a page of its coins. |
|
| Convert an amount of one cryptocurrency into one target currency. |
|
| Resolve exchange IDs and slugs. |
|
| List the blockchain platforms supported by CoinMarketCap DEX data. |
|
| Read the current DEX price of one token by platform name and contract address. |
Numeric CMC IDs are preferred over ticker symbols where practical because symbols can be ambiguous. Tool schemas reject unknown arguments, enforce bounded list/pagination inputs, and validate cross-field constraints locally. cmc_dex_token_price passes the platform name and token address through with their case unchanged; use cmc_dex_platform_list to find accepted platform names.
Related MCP server: EODHD MCP Server
Python 3.11 or newer is required. The documented workflow uses uv:
uv sync
uv run pytest -qThe package reports the version declared in pyproject.toml. Runtime dependencies are mcp, httpx, and uvicorn (for Streamable HTTP); test dependencies are provided by the dev dependency group.
The canonical local stdio command is:
uv run coinmarketcap-keyless-mcpIt keeps stdout reserved for MCP protocol traffic; diagnostics go to logging/stderr. The same command's help is available with uv run coinmarketcap-keyless-mcp --help.
For Codex CLI, use the tested command directly and provide no secret environment variables:
[mcp_servers.coinmarketcap_keyless]
command = "uv"
args = ["run", "coinmarketcap-keyless-mcp"]The secondary Streamable HTTP transport is intended for local use. It binds to 127.0.0.1:8000 by default and exposes MCP at /mcp:
uv run coinmarketcap-keyless-mcp --transport streamable-httpUse --host and --port to choose the local bind address and port, for example --host 127.0.0.1 --port 8001. This is not an internet-facing hosted service: the HTTP transport has no authentication, so anyone who can reach it can spend this machine's keyless CoinMarketCap rate limit. Binding to a non-loopback host such as 0.0.0.0 logs a warning to stderr. Both transports expose the same 20 tools and schemas.
The server preserves the provider's status and data envelope rather than inventing derived market indicators. Provider text fields (for example project descriptions) are passed through verbatim, so treat them as untrusted input to the model. A successful HTTP 2xx response must also have a valid CMC envelope with normalized status.error_code == 0.
Validation failures are INVALID_ARGUMENT. Exhausted HTTP 429 retries are RATE_LIMITED, never UNSUPPORTED_ROUTE. Timeout, network, and retryable 5xx failures retain transient upstream classifications; malformed successful responses are UPSTREAM_CONTRACT_MISMATCH; provider application errors are UPSTREAM_APPLICATION_ERROR. Unsupported capability is recorded only with positive evidence.
Retries are bounded and apply to 429, 502/503/504, and selected network/timeouts. Valid Retry-After values within the backoff cap are honored; a longer Retry-After ends retrying immediately with the final classification (for example RATE_LIMITED) instead of retrying early; otherwise capped exponential backoff with jitter is used. Each attempt also has a 30-second wall-clock deadline. Deterministic non-429 4xx responses are not retried. Non-retryable 4xx errors include the provider's error message when the body carries one (read up to 4 KiB, sanitized). The client uses a bounded (64-entry) process-local TTL cache for successful responses only, coalesces identical concurrent cold requests into one upstream fetch, with route-specific short TTLs for volatile data and a default maximum of two concurrent upstream requests. Caching is an optimization, not a correctness dependency.
Live verification is opt-in and separate from ordinary offline tests:
uv run python -m coinmarketcap_keyless_mcp.verify_liveIt serially probes one minimal call for each of the 20 routes against the fixed keyless base URL without credentials and writes a timestamped, minimized JSON report under verification/. To rerun one selected ambiguous or transient route:
uv run python -m coinmarketcap_keyless_mcp.verify_live --tool cmc_quotes_latestClassifications are:
SUPPORTED: the keyless response passed the route's minimum shape checks;
RATE_LIMITED: the route exhausted HTTP 429 handling;
TRANSIENT_ERROR: a timeout, network, or retryable upstream failure prevented a conclusion;
CONTRACT_MISMATCH: the response envelope or minimum route shape was not valid;
UNSUPPORTED: positive provider evidence indicates the keyless capability is unavailable.
The command exits 0 only when every probed route is SUPPORTED, 1 otherwise, and 2 if the run or evidence write fails.
The current release evidence is verification/live-capability-20261001T151943758586Z.json, produced by the manual live-release-qualification.yml workflow (run 36883326560) on the exact 1.0.2 release commit b486dec35b0a6849abaa5f0ade8633b08ebafa4a; see verification/release-1.0.2.md. It records all 13 released routes as SUPPORTED with HTTP 200 and provider error code 0, the exact fixed base URL, timestamps, no credentials, and server version 1.0.2; reports intentionally retain no full provider payloads. The status is LIVE_KEYLESS_CORE_VERIFIED. The earlier Phase 5 evidence for pre-release 0.1.0 (verification/live-capability-20261001T015531675887Z.json, with the selected historical-route rerun in verification/live-capability-20261001T015419204714Z.json) is kept for history. CoinMarketCap can change keyless coverage or rate-limit behavior, so rerun the full command or a selected route after provider changes and before a later release qualification. Do not infer unsupported capability from one 429 or transient failure.
That evidence covers the 13 v1 routes only. The seven v1.1 routes have mocked, non-live verification and independent acceptance records (verification/v1.1-e1r-contract-review.md, verification/v1.1-e2a-contract-review.md), but no live evidence yet; the v1.1 live release gate is still pending.
The required non-live qualification commands are:
uv sync
uv run pytest tests/unit -q
uv run pytest tests/contract -q
uv run pytest tests/mcp -q
uv run pytest tests/mcp/test_stdio.py -q
uv run pytest tests/mcp/test_streamable_http.py -q
uv run pytest -q
git diff --checkTests use fixtures, mocks, local subprocesses, and a localhost HTTP server; they do not require live CoinMarketCap access.
This package provides no trading, order placement, wallets, signing, custody, transactions, credentials, API-key configuration, authenticated fallback, DEX surface beyond the two read-only DEX tools above, generic proxy, investment advice, portfolio construction, or locally derived investment-advice logic. It does not silently transform provider values into locally derived indicators.
The exact contract is encoded in src/coinmarketcap_keyless_mcp/contracts.py, and the product boundary is defined in PLAN.md and, for the v1.1 additions, V1_1_PLAN.md.
MIT. See LICENSE.
Get CoinMarketCap Altcoin Season Index history for one provider-supported timeframe.
| Name | Required | Description | Default |
|---|---|---|---|
| timeframe | No | 7d |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| status | Yes |
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 implies read-only via 'Get' but does not explicitly state read-only behavior, side effects, auth requirements, rate limits, or response characteristics beyond what the output schema provides.
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 with no filler; it states the resource and scope immediately.
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 historical-data retrieval with an output schema and an enum-constrained parameter, the description is minimally adequate. It omits selection guidance against the 'latest' sibling and does not elaborate on parameter values, but the structured fields cover enough for correct invocation.
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 0% for the single timeframe parameter. The description mentions 'one provider-supported timeframe' but does not list the allowed values ('7d', '30d', '90d') or the default, leaving the schema's enum as the only source of parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Get') and resource ('CoinMarketCap Altcoin Season Index history'), and the 'historical' scope distinguishes it from the sibling cmc_altcoin_season_latest. However it does not explicitly name an alternative or state exclusions, so it falls short of the top mark.
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 guidance or alternative tools are named. The phrase 'for one provider-supported timeframe' is a parameter constraint, not usage context, so an agent must infer that this is for historical as opposed to latest data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the latest CoinMarketCap Altcoin Season Index snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| status | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether the result is a point-in-time read, how fresh the snapshot is, refresh cadence, rate limits, or what the snapshot contains. 'Snapshot' hints at a read-only point-in-time value but adds little substantive behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler. Every word (latest, snapshot, Altcoin Season Index) carries meaning and 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?
For a zero-parameter tool with a rich output schema already present, the description need not explain return values. It adequately establishes what is fetched; the only missing piece is routing guidance to the historical sibling. Given the output schema exists, this is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4. There is nothing for the description to compensate for, and the absence of any param discussion is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: 'Get the latest CoinMarketCap Altcoin Season Index snapshot'. The 'latest' and 'snapshot' framing distinguishes it from cmc_altcoin_season_historical, though the description does not explicitly name that sibling or contrast it. Sibling differentiation is implied by 'latest' but not made explicit.
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 guidance, no exclusion of alternatives, no mention of when to prefer the historical sibling. The word 'latest' implicitly signals a current-value query, but nothing tells an agent when this rather than cmc_altcoin_season_historical is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get historical CoinMarketCap 100 Index values at a provider-supported interval.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | ||
| interval | No | daily | |
| time_end | No | ||
| time_start | No |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| status | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full behavioral burden. It doesn't state whether time_start/time_end are required for meaningful results, what happens on out-of-range windows, rate limits, or auth needs. 'Provider-supported interval' is the only constraint hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the verb and resource, zero padding. Appropriately sized for a query tool with an output schema.
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 annotations, 0% schema coverage on four params, and no output schema explanation, the description leaves critical gaps: time format, whether time bounds are required, and interval semantics. The output schema existing means return values needn't be explained, but input behavior is under-specified.
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 0% — four undocumented parameters (count, interval, time_end, time_start) with no titles beyond field names. The description only refers vaguely to 'provider-supported interval' and does not explain time format, whether start/end are required, or how count interacts with the window.
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 (Get) and resource (historical CoinMarketCap 100 Index values) with the interval scoping qualifier. Siblings cmc_cmc20_historical and cmc_cmc100_latest make the '100' vs '20' and 'historical' vs 'latest' distinctions inferable from the name, though the description doesn't explicitly contrast them.
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 guidance on when to use this over cmc_cmc100_latest or cmc_cmc20_historical. The 'provider-supported interval' phrase hints at constraints but doesn't name alternatives or conditions for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the latest CoinMarketCap 100 Index value, constituents, and constituent weights.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| status | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the three returned components (value, constituents, weights), which is useful, but says nothing about auth requirements, rate limits, caching/refresh cadence, or whether the snapshot is point-in-time. For a read-only no-param endpoint the gaps are modest but real.
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 with the verb first and the returned payload enumerated, with zero filler. Nothing could be trimmed without losing information.
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 an output schema present, the description need not explain the return structure, and it correctly summarizes the payload. For a zero-param read tool this is essentially complete, though it omits freshness/refresh semantics that a caller of a 'latest' endpoint might want.
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. The description adds no param detail because none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Get') and resource ('CoinMarketCap 100 Index value, constituents, and constituent weights'), so the agent knows exactly what it returns. It doesn't explicitly name the sibling it contrasts with, but 'latest' implicitly separates it from cmc_cmc100_historical.
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 word 'latest' implies the temporal scope and implicitly routes to cmc_cmc100_historical for past data, but there is no explicit when-to-use statement, no exclusions, and no prerequisites mentioned. Usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get historical CoinMarketCap 20 Index values at a provider-supported interval.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | ||
| interval | No | daily | |
| time_end | No | ||
| time_start | No |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| status | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only historical lookup but says nothing about rate limits, whether the index series can be sparse, how far back history goes, or what 'provider-supported' actually restricts — meaningful gaps for a market-data 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?
A single efficient sentence with the resource front-loaded and no padding. It is well-sized, though it is concise at the cost of the detail an agent would need.
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?
An output schema exists, so return values need not be explained, but with zero annotation coverage, zero parameter descriptions, and no usage guidance, the definition is under-specified for a four-parameter historical data tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across four parameters, and the description only gestures at one of them ('interval'). count, time_start, and time_end — including their accepted formats — are entirely undocumented in both the schema and the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('historical CoinMarketCap 20 Index values'), which cleanly separates it from cmc_cmc20_latest and the other *_historical siblings. It stops short of explicitly naming those alternatives, but the 'historical' qualifier plus the tool name make the target 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 mention of prerequisites, and no routing to the sibling tools (e.g. cmc_cmc20_latest for current values). The only contextual hint is 'provider-supported interval', which is a constraint rather than usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the latest CoinMarketCap 20 Index value, constituents, and constituent weights.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| status | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the shape of what is returned (index value plus constituents and weights), which is useful, but says nothing about caching freshness, rate limits, auth requirements, or whether the 'latest' snapshot is real-time vs delayed.
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 zero filler, front-loading the verb and resource and enumerating the returned fields compactly. 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?
An output schema exists, so return-value details need not be restated, and a zero-parameter read tool has a low completeness bar. The definition covers the essentials; only the lack of freshness/rate behavior keeps it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4. There are no parameters to disambiguate and the description correctly avoids inventing any.
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 ('Get'), resource ('CoinMarketCap 20 Index'), and the exact payload ('value, constituents, and constituent weights'). The 'latest' qualifier implicitly distinguishes it from the sibling cmc_cmc20_historical, though the differentiation is by name convention rather than explicit statement.
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 — fetch current CMC20 index data — but the description gives no explicit when-to-use conditions, no mention of the historical sibling as the alternative for past values, and no prerequisites. Adequate but with a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get CoinMarketCap metadata for known cryptocurrencies. Numeric CMC IDs are preferred because symbols are not globally unique.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | No | ||
| slugs | No | ||
| symbols | No | ||
| skip_invalid | No |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| status | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions that IDs are preferred over symbols due to non-uniqueness, which is a useful behavioral note. But it doesn't disclose other critical traits: what happens with skip_invalid, rate limits, authentication needs, or return format details. With no annotations, this is a significant gap.
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 efficient sentence that front-loads the purpose. It avoids waste, though it could be slightly more informative without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, no annotations, 0% schema coverage, but an output schema exists), the description is too sparse. It doesn't explain parameter usage, behavior with skip_invalid, or how results are returned. The output schema may cover return values, but the description still leaves critical gaps for correct invocation.
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 0%, and the description does not explain any of the four parameters (ids, slugs, symbols, skip_invalid). It only implies that ids and symbols are acceptable inputs and hints at preference for ids, but no meaning beyond that. With 0% coverage, the description must compensate but fails to do so adequately.
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?
Clear verb+resource: 'Get CoinMarketCap metadata for known cryptocurrencies.' It distinguishes itself from sibling tools like cmc_quotes_latest or cmc_listings_latest by focusing on metadata lookup, though it doesn't explicitly name alternatives. A 4 is appropriate since the purpose is clear but not fully differentiated from siblings.
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 implies usage by saying 'Numeric CMC IDs are preferred because symbols are not globally unique,' which gives some guidance on identifier choice. However, it doesn't specify when to use this tool versus alternatives like cmc_crypto_map or cmc_quotes_latest. Implied usage only, so a 3.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve CoinMarketCap cryptocurrency IDs and canonical identifiers. Prefer this tool before symbol-based research when an asset's CMC ID is not already known.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | id | |
| limit | No | ||
| start | No | ||
| symbols | No | ||
| listing_status | No |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| status | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It gives some transparency: the tool is a resolver/mapper and hints at ordering by CMC ID vs rank. However, it doesn't disclose whether results are cached, whether it pages over the full asset universe, or what a missing symbol returns — important for a lookup tool with 0% schema description coverage.
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 tight sentences, front-loaded with the tool's purpose followed immediately by the when-to-use guidance. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (so return values are covered) but the description fails to explain any of its 5 parameters, which is the bulk of the tool's surface. For a lookup tool with zero annotations and 0% schema coverage, the description is too thin to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate — and it doesn't. None of the five parameters (sort, limit, start, symbols, listing_status) are explained in the description. The enum for sort and listing_status is only inferable from the schema. The description leaves parameter semantics entirely unspecified.
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 'Resolve' and resource 'CoinMarketCap cryptocurrency IDs and canonical identifiers' — an agent knows it maps symbols/assets to CMC IDs. It doesn't explicitly name a sibling tool it differs from, but the purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: 'Prefer this tool before symbol-based research when an asset's CMC ID is not already known.' This tells the agent exactly when this tool is the right first step, though no alternative sibling is named as a fallback.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get historical CoinMarketCap Crypto Fear and Greed values, paginated from the provider's daily series.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| start | No |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| status | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose useful behavior beyond the schema: results are paginated and drawn from the provider's daily series, which tells the agent about granularity and page-wise delivery. It says nothing about rate limits, ordering of results, or what happens at the pagination boundary.
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 with no filler; the core purpose and the pagination/source qualifier are packed efficiently. Nothing to trim, though it is short enough that it leaves gaps rather than being wasteful.
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?
An output schema exists, so return values need not be explained. However, for a paginated data tool with 0% param coverage and no annotations, the description omits how pagination actually works, leaving the agent to guess at limit/start semantics.
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 0%, so the description must explain 'limit' and 'start', but it only says 'paginated' without defining what limit caps (default 50, max 500) or what start indexes. The two optional integer parameters remain semantically undocumented in both the schema and the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Get') and resource ('historical CoinMarketCap Crypto Fear and Greed values'), and the word 'historical' implicitly distinguishes it from the cmc_fear_greed_latest sibling. It stops short of naming the sibling or the date granularity explicitly, but an agent can identify what the tool returns.
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 only implied by the word 'historical' – the agent can infer this is for past data rather than the current reading, but the description never says when to prefer cmc_fear_greed_latest versus this tool, nor any prerequisites. Adequate but with a clear routing gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the latest CoinMarketCap Crypto Fear and Greed Index value and classification.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| status | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It reveals only that a current index value and classification are returned, with no mention of auth needs, rate limits, or update cadence. For a zero-parameter read of a public index this is low-risk, but the behavioral detail is thin.
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 with no filler, stating the action, the resource, and the temporal scope. Every word 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?
An output schema exists, so return values need not be explained, and the tool has no parameters. The description is complete enough for correct invocation, with only the explicit alternative-tool routing 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?
The tool takes zero parameters, so the baseline is 4 per the rubric. The description correctly implies no inputs are needed, and there is nothing further for it to disambiguate.
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 (Get) and resource (CoinMarketCap Crypto Fear and Greed Index value and classification) with the scope qualifier 'latest'. This clearly separates it in intent from the sibling cmc_fear_greed_historical, though the description never names that sibling explicitly.
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 explicit when-to-use or when-not-to-use statement and no named alternative. However, the 'latest' framing implicitly signals it is the current-value counterpart to the historical sibling, so usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get CoinMarketCap's latest aggregate crypto-market metrics, including market capitalization, volume, and dominance measures.
| Name | Required | Description | Default |
|---|---|---|---|
| convert | No |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| status | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. 'Get' implies read-only behavior and 'latest' implies freshness, but auth requirements, rate limits, and any safety constraints are unstated.
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 with no wasted words. It is appropriately sized for a simple metrics-fetching tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values do not need to be explained. However, for a tool with no annotations and an undocumented 'convert' parameter, the description still leaves clear gaps around how to call it and when to prefer it over sibling endpoints.
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 single 'convert' parameter is entirely absent from the description. Schema description coverage is 0%, and the description does not explain that the parameter controls currency conversion or any of its constraints.
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 ('Get') and resource ('CoinMarketCap's latest aggregate crypto-market metrics'), and lists the included data families. It implicitly distinguishes itself from asset-level siblings via 'aggregate', but it does not name or contrast any sibling tool.
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 explicit when-to-use or when-not-to-use guidance is given. 'Latest' hints at current-snapshot usage versus historical siblings, but no alternatives or conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a ranked, paginated list of active cryptocurrencies with current market data. Use this tool for market breadth/ranking; use cmc_quotes_latest for a known small asset set.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | market_cap | |
| limit | No | ||
| start | No | ||
| convert | No | ||
| sort_dir | No | desc |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| status | Yes |
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 that results are ranked and paginated. However it says nothing about authentication requirements, rate limits, or whether the list is point-in-time vs cached. It adds some behavioral value but leaves the mutation/safety-style context absent.
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 tight sentences with no filler, and the routing rule is front-loaded after the core purpose. 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?
An output schema exists so return values need not be described, and the breadth-vs-quotes routing is covered. But with 0% parameter documentation and no annotations, the description is thin for a tool exposing a 17-option sort enum, pagination, and multi-currency conversion.
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 0% across 5 parameters, so the description must compensate. 'Ranked' and 'paginated' loosely map to sort and start/limit, but the 17-value sort enum, sort_dir, convert, and the 1-250 limit bound are not explained at all, leaving most parameter meaning undocumented.
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 resource ('Get a ranked, paginated list of active cryptocurrencies with current market data'), and names the sibling it is not (cmc_quotes_latest). An agent can differentiate this breadth/ranking tool from the quote tool without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly gives the selection rule: use this for market breadth/ranking, use cmc_quotes_latest for a known small asset set. The alternative and the condition that picks it are stated, not inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the latest CoinMarketCap market quotes for a known set of cryptocurrencies. Prefer CMC IDs over symbols when identity ambiguity matters.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | No | ||
| slugs | No | ||
| convert | No | ||
| symbols | No | ||
| skip_invalid | No |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| status | Yes |
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, and it discloses almost nothing. It does not state auth requirements, rate limits, what happens when an unknown symbol/id is supplied, or how the 'latest' snapshot is scoped (spot price? market cap?). The skip_invalid parameter clearly implies a failure mode that the description never explains.
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 sentences, zero filler, and the identifier-preference advice is placed immediately after the purpose statement. Nothing is padded or restated from 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?
An output schema exists, so return values need not be explained. But with zero annotations and 0% schema description coverage across five parameters, the identifier ambiguity between ids/slugs/symbols and the skip_invalid semantics are left for the agent to guess. The description is materially incomplete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for five undocumented parameters. It covers only the ids-vs-symbols tradeoff and says nothing about slugs, convert (default USD, max 3 targets), or skip_invalid, whose behavior is entirely opaque without prose.
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 resource: 'Get the latest CoinMarketCap market quotes'. Combined with the name's 'latest' token, it distinguishes itself from the historical siblings (cmc_cmc100_historical, cmc_fear_greed_historical, etc.) and from listing/info tools. It stops short of explicitly naming which sibling to use instead for other quote shapes.
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?
'Prefer CMC IDs over symbols when identity ambiguity matters' gives real guidance on which identifier to supply, which is more than most definitions offer. However, it says nothing about when to choose this tool over cmc_listings_latest, cmc_crypto_info, or the cmc100/cmc20 index variants, leaving primary tool-selection inference to the agent.
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.
v1.0.1cmc_altcoin_season_historicalcmc_altcoin_season_latestcmc_cmc100_historicalcmc_cmc100_latestcmc_cmc20_historicalcmc_cmc20_latestcmc_crypto_infocmc_crypto_mapcmc_fear_greed_historicalcmc_fear_greed_latestcmc_global_metrics_latestcmc_listings_latestcmc_quotes_latestScored across 13 tools
Each tool targets a distinct data type or time window (latest vs historical for indices, fear & greed, altcoin season; separate tools for ID resolution, metadata, quotes, listings, global metrics). No two tools overlap significantly.
All tools use a consistent snake_case pattern with the cmc_ prefix and a noun_qualifier structure (e.g., cmc_cmc100_historical, cmc_quotes_latest). The convention is predictable throughout.
13 tools is well-scoped for a market data server, covering several indices, sentiment indicators, and core market queries without excessive redundancy.
The set covers latest and historical data for indices and sentiment, but lacks historical data for individual cryptocurrency quotes/prices and global metrics history. This is a notable gap for a comprehensive market data API.
Read-only educational MCP for CryptoDecentral Sovereign. No auth, trading, custody, or advice.
33 pay-per-call market and news data tools over MCP with free discovery and x402 payments.
Free read-only crypto whale-tracking & market-data MCP tools across 14 chains. No auth.
Free, read-only MCP subset of x402 Toolbox's cheap data endpoints, free via MCP.