Cryptocurrency market data for 12,000+ coins and 350+ exchanges: prices, tickers, OHLCV, contract lookups, tags, and search.
Scored across 27 tools
Every potentially confusable pair is explicitly separated in the descriptions: getCoinExchanges vs getCoinMarkets, getTickers vs getTickersById, getCoinOHLCVToday vs getCoinOHLCVLatest vs getTickersHistoricalById, resolveId vs search, getCapabilities vs status. Each tool states what it does NOT do and points to the correct alternative, so an agent can route reliably even across 27 tools.
The dominant pattern is camelCase verb_noun (getCoinById, getExchangeMarkets, getTickersHistoricalById), which is predictable and readable. Minor deviations exist: getExchangeByID capitalizes 'ID' while all other tools use 'ById', and priceConverter/status are noun-only while search is a bare verb.
27 tools is heavy and sits at the upper edge of the rubric's acceptable band. The surface spans several sub-domains (coins, tickers, exchanges, markets, contracts, tags, people, plus server meta), and some entries like getCoinOHLCVToday vs getCoinOHLCVLatest could plausibly be folded into a parameterized tool.
Coverage is broad and symmetric: id resolution, current and historical prices, OHLC, exchange and market lookups, contract-based lookups, tags, people, global stats, and conversion are all present. Gaps remain around ICOs (referenced in search and tag counters but with no dedicated tool) and historical OHLC candles beyond today/yesterday, though the latter is a documented plan-tier limitation.
Get the server's capabilities, supported workflow patterns, validation rules and recommended tool sequences. Use FIRST to onboard as an agent, or when asked 'what can this server do', 'how should I chain these tools', 'what are the parameter rules'. This describes the MCP server itself, not crypto data.
| Name | Required | Description | Default |
|---|---|---|---|
| rationale | Yes | REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions. |
| Name | Required | Description |
|---|---|---|
| api | Yes | |
| note | No | |
| server | Yes | |
| plan_tiers | Yes | |
| tools_count | No | |
| coin_id_format | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, openWorld, and non-destructive behavior. The description adds useful scope: it is an onboarding/capability-discovery tool that describes the server itself rather than crypto data, and it indicates the kind of information returned.
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 tightly written sentences with no filler. The purpose is front-loaded, followed immediately by actionable usage guidance and a clear scope boundary.
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 rich parameter schema, output schema, and annotations, the description is complete enough for an agent to know when and why to call this tool. It also clarifies the non-crypto-data scope, which prevents confusion with sibling tools.
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 rationale parameter has 100% schema description coverage, including detailed examples and constraints, so the schema carries parameter semantics. The tool description does not add further detail about the rationale parameter, so baseline 3 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 and resource: get the server's capabilities, workflow patterns, validation rules, and recommended sequences. It explicitly distinguishes itself from sibling crypto-data tools by saying it describes the MCP server itself, not crypto data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit usage conditions: use FIRST to onboard as an agent, or when asked what the server can do, how to chain tools, or what the parameter rules are. This directly routes the agent on when to choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get descriptive project information about a coin: description, links, team and tags. Use for 'tell me about Uniswap', 'what is this project'. Does NOT include price; for price and market cap use getTickersById. Read-only; coinId is a canonical id (resolve with resolveId). No API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| coinId | Yes | Canonical CoinPaprika coin slug in 'symbol-name' format, e.g. 'btc-bitcoin', 'eth-ethereum', 'ada-cardano'. Do NOT pass ticker symbols ('BTC', 'AAVE') or guess the slug; it is not derivable from the symbol (e.g. AAVE resolves to 'aave-new', which you could not guess). Call search or resolveId first to resolve a symbol or name to its canonical id. | |
| rationale | Yes | REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions. |
| Name | Required | Description |
|---|---|---|
| id | No | CoinPaprika coin slug, format symbol-name (e.g. 'btc-bitcoin'). |
| name | No | |
| rank | No | |
| type | No | 'coin' or 'token'. |
| is_new | No | |
| symbol | No | |
| is_active | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare read-only, idempotent, non-destructive, and open-world behavior. The description adds useful context beyond them: no price data is returned, no API key is required, and coinId must be canonical. It does not cover rate limits or error behavior, so it falls short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with what the tool returns, then immediately covers usage examples, exclusions, id resolution, and auth. Every sentence carries actionable 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?
For a read-only lookup tool with strong annotations, a detailed schema, and an output schema, the description covers what it returns, what it excludes, when to use it, and how to prepare coinId. Nothing needed for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both coinId and rationale in detail. The description reinforces the canonical-id requirement and resolveId workflow, but adds little beyond the 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: fetching descriptive project information about a coin, including description, links, team, and tags. It explicitly distinguishes itself from getTickersById by noting that price and market cap are excluded.
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?
It gives concrete usage examples ('tell me about Uniswap', 'what is this project') and an explicit exclusion with the alternative: for price and market cap use getTickersById. It also tells the agent to resolve coinId with resolveId when needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the timeline of events for a coin (launches, partnerships, hard forks, conference talks) with dates and descriptions. Use for 'what is happening with X', 'upcoming events for Ethereum', 'X roadmap events'. For prices use getTickersById. Read-only; coinId is a canonical id, limit caps results. No API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| coinId | Yes | Canonical CoinPaprika coin slug in 'symbol-name' format, e.g. 'btc-bitcoin', 'eth-ethereum', 'ada-cardano'. Do NOT pass ticker symbols ('BTC', 'AAVE') or guess the slug; it is not derivable from the symbol (e.g. AAVE resolves to 'aave-new', which you could not guess). Call search or resolveId first to resolve a symbol or name to its canonical id. | |
| rationale | Yes | REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions. |
| Name | Required | Description |
|---|---|---|
| events | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and openWorld. The description adds beyond that: it calls out that there's no API key requirement, that coinId must be canonical, and that limit caps results. It doesn't elaborate on output shape, but an output schema exists to cover that.
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?
Dense and front-loaded: purpose first, then usage examples, then the price alternative, then constraints. Every clause carries information, though the final constraint sentence is a bit compressed and terse.
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 a rich output schema and full annotations, the description rounds out the picture with canonical-id guidance, the limit cap, and no-key auth. An agent has enough to invoke correctly; only the exact return shape is left to the schema, which is acceptable.
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?
coinId and rationale are documented in the schema, and the description reinforces the canonical-id requirement. It also gives meaning to limit ('caps results') that the bare schema leaves undocumented, compensating for the 67% coverage gap. Slightly short of full because limit's default/behavior is only loosely addressed.
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 (retrieve the event timeline for a coin) and enumerates event types with dates and descriptions. It explicitly distinguishes from getTickersById ('for prices use...'), so an agent can tell it apart from price siblings without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete example queries ('what is happening with X', 'upcoming events for Ethereum') and names the alternative for price lookups. The when-to-use condition and the exclusion are both explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the exchanges that LIST a specific coin (venue names only). Use for 'which exchanges list X', 'is X on Coinbase', 'where is X listed'. For where to BUY with per-market price and volume use getCoinMarkets; for the live price use getTickersById. Read-only; coinId is a canonical id, limit caps results. No API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| coinId | Yes | Canonical CoinPaprika coin slug in 'symbol-name' format, e.g. 'btc-bitcoin', 'eth-ethereum', 'ada-cardano'. Do NOT pass ticker symbols ('BTC', 'AAVE') or guess the slug; it is not derivable from the symbol (e.g. AAVE resolves to 'aave-new', which you could not guess). Call search or resolveId first to resolve a symbol or name to its canonical id. | |
| rationale | Yes | REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions. |
| Name | Required | Description |
|---|---|---|
| exchanges | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry the full safety profile (readOnly, idempotent, non-destructive, open-world), so the description is not the only source. It still adds real context: results are venue names only, no API key is required, and limit caps the result set. 'Read-only' and 'coinId is a canonical id' partly restate structured data, keeping it just below a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with purpose, then routing, then constraints. Efficient overall, though 'Read-only' and the canonical-id reminder overlap with the annotations and schema and could be trimmed.
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?
Output schema exists, so return-value explanation is unnecessary; the description still notes 'venue names only'. With three parameters, one of them undocumented in schema, and rich annotations, the description covers routing, auth requirements, and the limit semantics — nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%; coinId and rationale are thoroughly documented in the schema, but `limit` has no schema description. The description fills that gap by saying limit caps results, and reinforces the canonical-id constraint that the schema also states. It adds meaning for the undocumented parameter rather than merely echoing the 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?
States a specific verb and resource ('List the exchanges that LIST a specific coin') and immediately qualifies the scope with '(venue names only)'. It is clearly separable from getCoinMarkets and getTickersById, which are named 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?
Gives concrete user phrasings that should route here ('which exchanges list X', 'is X on Coinbase', 'where is X listed') and then names the two alternatives with the condition that selects each (per-market price/volume vs. live price). This is explicit when-to-use plus when-to-use-something-else.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the specific markets and trading pairs where a coin trades, with per-market price and 24h volume. Use for 'where can I buy X', 'X price on Binance', 'best market for X'. For just the list of exchange names use getCoinExchanges. Read-only; coinId is a canonical id, quotes sets quote currencies, limit caps results. No API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| coinId | Yes | Canonical CoinPaprika coin slug in 'symbol-name' format, e.g. 'btc-bitcoin', 'eth-ethereum', 'ada-cardano'. Do NOT pass ticker symbols ('BTC', 'AAVE') or guess the slug; it is not derivable from the symbol (e.g. AAVE resolves to 'aave-new', which you could not guess). Call search or resolveId first to resolve a symbol or name to its canonical id. | |
| quotes | No | ||
| rationale | Yes | REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions. |
| Name | Required | Description |
|---|---|---|
| markets | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered; the description's 'Read-only' merely repeats it. It does add useful operational context — no API key required — and clarifies that coinId must be canonical rather than a ticker, but says nothing about rate limits or result ordering.
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?
Three compact sentences: purpose and payload first, then routing examples, then the alternative sibling and operational notes. No filler and nothing important buried.
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 no prose, and annotations cover safety. Combined with a richly documented coinId, the definition is nearly complete; the remaining gaps are the quotes value format and whether limit truncates or paginates.
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 50%: coinId and rationale are richly documented in the schema, while limit and quotes have no schema descriptions. The description gives role-level meaning for both ('quotes sets quote currencies', 'limit caps results') but not the format — an agent cannot tell whether quotes is a comma-separated string like 'USD,BTC' or a repeated list, which is an invocation risk.
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 — the markets/trading pairs where a coin trades — plus the payload it returns (per-market price and 24h volume). It explicitly differentiates from the nearest sibling, getCoinExchanges, which returns only exchange names.
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 concrete user phrasings ('where can I buy X', 'X price on Binance', 'best market for X') that trigger this tool and names the alternative (getCoinExchanges) with the condition that selects it. The schema further routes to resolveId/search before calling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the latest full-day OHLC candle (open, high, low, close and volume) for a coin. Use for 'yesterday's candle for BTC'. For the live spot price use getTickersById. Read-only; coinId must be a canonical id (resolve a bare symbol with resolveId first), quote defaults to usd. No API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| quote | No | usd | |
| coinId | Yes | Canonical CoinPaprika coin slug in 'symbol-name' format, e.g. 'btc-bitcoin', 'eth-ethereum', 'ada-cardano'. Do NOT pass ticker symbols ('BTC', 'AAVE') or guess the slug; it is not derivable from the symbol (e.g. AAVE resolves to 'aave-new', which you could not guess). Call search or resolveId first to resolve a symbol or name to its canonical id. | |
| rationale | Yes | REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions. |
| Name | Required | Description |
|---|---|---|
| ohlcv | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive and open-world, so the description correctly spends its words adding context rather than repeating them: no API key required, quote defaults to usd, and coinId must be canonical. It does not mention rate limits, which day boundary the 'full day' uses, or the data source, but the output schema already covers return shape.
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?
Four short sentences with the core operation first, then the disambiguating example, then the alternative tool, then the preconditions. No sentence is filler and nothing important is buried.
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 no explanation, and the description covers prerequisites, defaults, and auth status. For a simple read tool this is nearly complete; only the candle's time boundary and sibling contrast with getCoinOHLCVToday are unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, so the baseline is 3. The coinId guidance ('must be a canonical id, resolve a bare symbol with resolveId first') largely restates the already-detailed schema description, and 'quote defaults to usd' only repeats the schema default without adding accepted-value guidance for the one param the schema leaves 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 the latest full-day OHLC candle') and enumerates the returned fields (open, high, low, close, volume). It is distinguishable from the near-twin getCoinOHLCVToday by the 'full-day' qualifier and from getTickersById by the explicit pointer to it.
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?
Gives a concrete usage example ('yesterday's candle for BTC'), names the alternative for live spot price (getTickersById), and states the prerequisite resolveId step for bare symbols. It does not contrast with getCoinOHLCVToday or the historical OHLCV siblings, which is the only remaining routing gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get today's in-progress OHLC candle for a coin. Use for 'today's high and low for ETH'. For the current spot price use getTickersById; for yesterday's full candle use getCoinOHLCVLatest, and for older prices getTickersHistoricalById. Read-only; coinId is a canonical id (resolve with resolveId). No API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| quote | No | usd | |
| coinId | Yes | Canonical CoinPaprika coin slug in 'symbol-name' format, e.g. 'btc-bitcoin', 'eth-ethereum', 'ada-cardano'. Do NOT pass ticker symbols ('BTC', 'AAVE') or guess the slug; it is not derivable from the symbol (e.g. AAVE resolves to 'aave-new', which you could not guess). Call search or resolveId first to resolve a symbol or name to its canonical id. | |
| rationale | Yes | REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions. |
| Name | Required | Description |
|---|---|---|
| ohlcv | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds meaningful context beyond annotations: the candle is 'in-progress,' coinId must be canonical, and no API key is required. It does not discuss rate limits or partial-data behavior, but with strong annotations the remaining gap 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?
The description is compact and front-loaded: the core purpose appears first, followed by alternatives and then implementation constraints. Every sentence adds useful information, with 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?
Given an output schema exists, the description need not explain return values. It sufficiently covers the tool's scope, alternatives, read-only nature, auth requirement, and canonical-id prerequisite. An agent has what it needs to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, with detailed schema text for coinId and rationale, so the baseline is 3. The description adds a useful reminder to resolve coinId with resolveId and reinforces canonical-id requirements, but it does not explain the quote parameter or add semantics beyond the schema for that undocumented parameter.
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: 'Get today's in-progress OHLC candle for a coin.' It distinguishes this from sibling tools by naming getTickersById, getCoinOHLCVLatest, and getTickersHistoricalById, so an agent can identify the exact use case without opening other schemas.
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?
It gives explicit when-to-use guidance ('today's high and low for ETH') and clearly routes alternatives: spot price to getTickersById, yesterday's full candle to getCoinOHLCVLatest, older prices to getTickersHistoricalById. The intended usage versus siblings is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available coins with id, name, symbol and rank. Use to discover coins or map a name to an id. Does NOT include prices; for prices use getTickers or getTickersById. Read-only; limit caps the number of coins returned. No API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Optional. Items per page (default 50, max 250). Server clamps requests above 250. | |
| rationale | Yes | REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions. |
| Name | Required | Description |
|---|---|---|
| coins | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/destructive, so the description correctly focuses on complementary facts: no API key required, and that limit caps the result count. What it doesn't disclose is pagination behavior or what happens past the first page, which for a list tool is the remaining behavioral 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?
Four short clauses, front-loaded with the resource and return fields, then the exclusion, then operational facts. Every sentence carries distinct information with no restatement of 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?
Output schema exists, so return values need no explanation; annotations carry the safety profile and the schema carries the parameter detail. The description fills the remaining slots – purpose, routing, and auth/limit context – with nothing material missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with limit fully documented (default 50, max 250, server clamp) and rationale also documented. The description's 'limit caps the number of coins returned' is consistent but adds nothing beyond the schema, so 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?
Specific verb+resource ('List all available coins') plus the exact fields returned (id, name, symbol, rank). It also explicitly carves out the price data domain, which separates it from the getTickers* siblings without needing to open their schemas.
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?
States both when to use it ('discover coins or map a name to an id') and when not to ('Does NOT include prices; for prices use getTickers or getTickersById'), naming the concrete alternatives. No inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the token contract addresses tracked on one platform as a list, mapping each contract to its CoinPaprika coin id. Use for 'contracts on ethereum', 'what tokens does BSC have', or to map a contract address to a coin id. Find the platformId first with getPlatforms; for one contract's live price use getTickerByContract, and for its history use getHistoricalTickerByContract. Read-only. Params: platformId (required) is a platform id such as 'eth-ethereum' or 'bsc-binance-smart-chain'; limit (optional, default 50, max 250) caps how many contracts return. An unknown platformId returns an error. No API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| rationale | Yes | REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions. | |
| platformId | Yes |
| Name | Required | Description |
|---|---|---|
| contracts | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description's 'Read-only' is largely redundant. It does add genuinely non-structured context: an unknown platformId returns an error, and no API key is required. It doesn't disclose result ordering or pagination behavior, which the output schema may partially cover.
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?
Front-loads what the tool returns before usage guidance, then siblings, then parameters — a sensible order with no filler sentences. Minor redundancy: 'Read-only' repeats the readOnlyHint annotation, and the description is on the long side for a two-parameter list 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?
With an output schema present, return-value detail is unnecessary; the description instead supplies the prerequisite lookup, error behavior, rate/auth note, and limit bounds. An agent has everything it needs to invoke this correctly on the first try.
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 low (33%), and the description compensates by explaining platformId with concrete example values ('eth-ethereum', 'bsc-binance-smart-chain') and limit's default and maximum (50/250). The third parameter (rationale) is well documented in the schema itself, so nothing critical is left 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 — 'List the token contract addresses tracked on one platform' — and adds the mapping to CoinPaprika coin IDs, which is the distinguishing feature versus the ticker siblings. An agent can tell it apart from getTickerByContract and getHistoricalTickerByContract without opening any 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?
Provides concrete trigger phrasings ('contracts on ethereum', 'what tokens does BSC have'), plus a prerequisite ordering ('Find the platformId first with getPlatforms') and explicit alternatives for price and history use cases. Both when-to-use and which-sibling-to-use are spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details for a specific exchange: 24h volume, market count, trust score, links and fiat support. Use for 'tell me about Binance', 'Coinbase exchange stats', 'is X a trustworthy exchange'. For the pairs traded there use getExchangeMarkets; find the exchange id first with search or getExchanges. Read-only; exchangeId is an exchange id such as binance. No API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| quotes | No | ||
| rationale | Yes | REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions. | |
| exchangeId | Yes |
| Name | Required | Description |
|---|---|---|
| id | No | |
| name | No | |
| fiats | No | |
| links | No | |
| active | No | |
| quotes | No | |
| markets | No | |
| message | No | |
| api_status | No | |
| currencies | No | |
| description | No | |
| last_updated | No | |
| adjusted_rank | No | |
| reported_rank | No | |
| website_status | No | |
| markets_data_fetched | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description reinforces that plus adds a genuinely non-structured fact: no API key required. It does not cover error behavior (unknown id) or rate limiting, but with annotations plus an output schema the safety profile is well covered.
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?
Four dense sentences, each doing distinct work: what it returns, example queries, sibling routing, and preconditions/format. Front-loaded with the payload rather than burying it.
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?
Return values are covered by the output schema, id resolution and auth are handled, so the agent has everything needed to call it correctly. The only real hole is the undocumented 'quotes' filter, which 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?
Schema coverage is only 33%, so the description has to compensate — it does for exchangeId by giving the format and an example value ('binance'), which prevents agents from passing a name or numeric internal id. However it never mentions the optional 'quotes' parameter, leaving that input ambiguous 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?
Specific verb + resource with the exact payload enumerated (24h volume, market count, trust score, links, fiat support), which makes it immediately distinguishable from getExchanges (listing) and getExchangeMarkets (pairs). An agent can tell what it returns without opening the 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?
Gives concrete trigger phrases ('tell me about Binance', 'is X a trustworthy exchange') and explicitly routes the adjacent needs elsewhere: getExchangeMarkets for pairs, search/getExchanges to resolve the id first. When-to-use, when-not-to-use, and the alternative are all stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the trading pairs (markets) on one exchange as a list, each with the pair, base and quote coin ids, latest price, 24h volume and category. Use for 'what pairs trade on Binance', 'markets on Kraken', 'BTC pairs on Coinbase'. For exchange-level stats such as trust score use getExchangeByID; find the exchangeId first with getExchanges. Read-only. Params: exchangeId (required) is an exchange id such as 'binance'; quotes (optional, default 'usd') is a comma-separated list of quote currencies for the figures, e.g. 'usd,btc'; limit (optional, default 50, max 250) caps how many markets return. No API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| quotes | No | ||
| rationale | Yes | REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions. | |
| exchangeId | Yes |
| Name | Required | Description |
|---|---|---|
| markets | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so safety is covered. The description adds two genuinely new facts — 'No API key required' and the default/max behaviour of quotes and limit — but says nothing about pagination, ordering, or what happens when an exchange has more markets than the limit (truncation vs paging).
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?
Front-loads the purpose and outputs before the routing guidance and parameter notes, and each section earns its place. Slightly dense — the param details are packed into one long sentence chain rather than being visually separated.
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-shape detail is unnecessary; the description still summarises the returned fields. Combined with defaults, the exchangeId prerequisite chain, and the auth note, an agent has everything needed to call this correctly on the first try.
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 only 25% (only the rationale param is described), so the description must carry the rest — and it does: exchangeId format example ('binance'), quotes as a comma-separated quote-currency list with default 'usd', and limit default 50 / max 250. The rationale param is left to its own rich schema description, which is reasonable.
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?
Opens with a specific verb and resource ('List the trading pairs (markets) on one exchange') and immediately discloses the per-item fields (pair, base/quote ids, price, 24h volume, category). This clearly separates it from getCoinMarkets (per-coin) and getExchangeByID (exchange stats).
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?
Gives concrete triggering phrasings ('what pairs trade on Binance', 'markets on Kraken') plus explicit routing: use getExchangeByID for trust-score style stats and getExchanges to obtain the exchangeId first. Both the when and the when-not are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List exchanges tracked by CoinPaprika as a list ranked by rank, each with id, name, trust score, active market count and 24h volume. Use for 'top exchanges by volume', 'biggest crypto exchanges', or to find an exchangeId before calling getExchangeByID. For one exchange's full stats use getExchangeByID; for its trading pairs use getExchangeMarkets. Read-only. Params: quotes (optional, default 'usd') is a comma-separated list of quote currencies for the volume figures, for example 'usd,btc'; limit (optional, default 50, max 250) caps how many exchanges return. No API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| quotes | No | ||
| rationale | Yes | REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions. |
| Name | Required | Description |
|---|---|---|
| exchanges | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, open-world behavior. The description adds useful context beyond that: results are ranked by rank, volume figures depend on quote currencies, no API key is required, and the limit has a max of 250.
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 front-loaded with purpose, then usage routing, then parameters. It is somewhat long, but nearly every sentence adds actionable information; 'Read-only' lightly repeats the annotation and is the only minor redundancy.
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 rich annotations and output schema, the description supplies everything else an agent needs: scope, ranking, output fields, alternatives, auth requirement, and parameter behavior. No important invocation detail is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%, so the description must carry parameter meaning. It explains quotes as a comma-separated list with default 'usd' and an example, and limit as a cap with default 50 and max 250. The required rationale parameter is not described here, but the schema documents it thoroughly.
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 ('List exchanges tracked by CoinPaprika'), describes the ordering and returned fields, and explicitly distinguishes itself from getExchangeByID and getExchangeMarkets. An agent can identify this tool without opening the 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?
Gives concrete use cases ('top exchanges by volume', 'biggest crypto exchanges') and explicitly names alternatives for other tasks: getExchangeByID for single-exchange stats, getExchangeMarkets for trading pairs. It also explains the common workflow of finding an exchangeId first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a global crypto market overview: total market cap, total 24h volume, Bitcoin dominance, and market-wide 24h change. Use for 'how is the crypto market doing', 'total market cap', 'BTC dominance'. For a single coin's price use getTickersById. Read-only; takes no parameters and needs no API key.
| Name | Required | Description | Default |
|---|---|---|---|
| rationale | Yes | REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, and the description usefully reinforces 'Read-only' and adds that no API key is needed. However, the claim 'takes no parameters' conflicts with the schema's required 'rationale' parameter, so the description is partially misleading about the actual invocation contract.
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 three compact sentences with no filler: purpose, example trigger phrases, alternative tool, and auth/safety note are each given efficiently. The most decision-relevant information is front-loaded.
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 read-only market-wide tool, the description covers purpose, usage context, alternative routing, and authentication, while the output schema presumably covers return structure. The false 'takes no parameters' statement creates a real invocation gap, so the description is not fully reliable or 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 schema fully documents the required 'rationale' parameter with a clear description and examples, so the baseline is 3. However, the description explicitly says the tool 'takes no parameters,' which would cause an agent to omit the required rationale and fail validation. This active contradiction with the schema outweighs the schema's strong documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Get'), a clear resource ('global crypto market overview'), and enumerates the exact metrics returned: total market cap, total 24h volume, Bitcoin dominance, and market-wide 24h change. It is easily distinguishable from siblings like getTickersById, getTickers, and getCoinMarkets because it is explicitly market-wide rather than coin-specific.
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 gives concrete example user queries ('how is the crypto market doing', 'total market cap', 'BTC dominance') and explicitly directs agents to getTickersById for single-coin price queries. This is strong when-to-use and when-not-to-use guidance that reduces tool-selection errors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a token's price and market history by its contract address, as a time series. Use for 'token price on 2024-01-01 by address', 'hourly history for a contract'. For its current price use getTickerByContract; by coin id use getTickersHistoricalById. Read-only. Params: platformId (required) chain id like 'eth-ethereum'; contractAddress (required) token address; start (required) and end (optional, default now) accept 'yyyy-mm-dd' or ISO 8601; interval (optional, default '5m'); quote (optional, default 'usd'); limit (optional, default 50, max 250) caps points. Requires a Starter+ plan (COINPAPRIKA_API_KEY). Free tier on this hosted server: daily intervals up to a year back and hourly intervals up to 24 hours back; anything else returns a structured CP402_PAID_ENDPOINT stub.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | Optional end timestamp. Same formats as start. Defaults to now if omitted. | |
| limit | No | Optional. Number of data points (default 50, max 250). | |
| quote | No | Optional quote currency code (default 'usd'). | usd |
| start | Yes | Required. Start timestamp. Accepts ISO 8601 ('2026-01-15T00:00:00Z') or date-only ('2026-01-15'). UTC. | |
| interval | No | Optional. Sampling interval, default '1d'. On this hosted server (free tier) daily and coarser intervals ('1d', '24h', '7d', '14d', '30d', '90d', '365d') are served for the last year and hourly ones ('1h', '2h', '3h', '6h', '12h') for the last 24 hours; minute intervals ('5m', '15m', '30m') and older ranges need a paid plan with your own key. Upstream supports additional intervals; consult CoinPaprika docs if you need something outside this list. | 1d |
| rationale | Yes | REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions. | |
| platformId | Yes | Platform identifier (e.g., 'eth-ethereum', 'bnb-binance-coin'). Use getPlatforms to discover valid platforms. | |
| contractAddress | Yes | Token contract address on the platform. EVM addresses are case-insensitive; Solana addresses are case-sensitive base58. |
| Name | Required | Description |
|---|---|---|
| ticks | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly/idempotent/non-destructive), and the description adds non-obvious behavior the annotations cannot express: it needs a Starter+ plan with COINPAPRIKA_API_KEY, the hosted free tier only serves daily-over-a-year and hourly-over-24h, and out-of-tier requests return a structured CP402_PAID_ENDPOINT stub rather than a normal error. That last detail materially changes how an agent should interpret a response.
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?
Front-loaded with purpose and routing before the parameter recap, and every sentence is informational rather than filler. The plan-tier sentence is dense but necessary; trimming it would cost behaviorally important detail.
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 an 8-param tool with full schema coverage, annotations, and an output schema, the description supplies the missing operational context (plan gating, tier limits, stub fallback). The gaps are the stale interval default and the unmentioned required rationale parameter, both of which affect 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 100% and the schema already documents formats, defaults, and limits, so the schema carries the load; the description mostly restates it. It does add the useful 'limit caps points' framing, but it states interval defaults to '5m' while the schema declares default '1d', and it omits the required rationale parameter entirely — both can mislead an agent filling the call.
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 a token's price and market history by its contract address, as a time series') and immediately distinguishes itself from both siblings that serve similar data (getTickerByContract for current price, getTickersHistoricalById for coin-id lookups). An agent can route correctly without opening any 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?
Gives concrete invocation examples ('token price on 2024-01-01 by address', 'hourly history for a contract') plus explicit alternatives and the condition that selects each: current price -> getTickerByContract, coin id -> getTickersHistoricalById. It also states plan eligibility and what the free tier will and will not serve.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the profile of one person in crypto by id: name, description or bio, teams_count, positions held, and linked projects plus social and code accounts. Use for 'who is Vitalik Buterin', 'background on Charlie Lee', 'projects tied to this founder'. Find the personId first with search or resolveId using type 'people'; this tool needs the exact id, not a name. Read-only. Params: personId (required) is a canonical person id such as 'vitalik-buterin' or 'satoshi-nakamoto'; an unknown id returns not found. No API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| personId | Yes | ||
| rationale | Yes | REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions. |
| Name | Required | Description |
|---|---|---|
| id | No | |
| name | No | |
| links | No | |
| positions | No | |
| description | No | |
| teams_count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description reinforces that with 'Read-only' plus two useful operational facts not in the annotations: an unknown id returns not found, and no API key is required. It stops short of describing response shape or limits, but the output schema covers returns, so the remaining gap 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?
Front-loaded with the verb and resource, then prerequisites, then parameter detail — a sensible information hierarchy. A few clauses are redundant with structured data ('Read-only' repeats readOnlyHint, 'No API key required' is somewhat extraneous), and the quoted example queries are slightly padded, but nothing is confusing.
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 two-parameter read tool with an output schema, everything an agent needs is present: entity identity, returned fields, the id-resolution prerequisite, id format, and failure behavior. No behavioral or procedural ambiguity remains that would cause a wrong 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 coverage is 50%: rationale is fully documented in-schema, while personId has no schema description. The description compensates well for that half, giving format examples ('vitalik-buterin', 'satoshi-nakamoto'), marking it required, and defining the not-found behavior for bad ids. It adds nothing about the rationale parameter, but that one is already self-documenting.
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 profile of one person in crypto by id') and enumerates the returned content (name, bio, teams_count, positions, projects, social/code accounts). This clearly separates it from sibling lookups like getCoinById, getTagById, and getExchangeByID, which target different entities.
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 concrete usage exemplars ('who is Vitalik Buterin', 'background on Charlie Lee') and, crucially, an explicit routing instruction: find the personId first with search or resolveId using type 'people'. It also states the exclusion outright — 'this tool needs the exact id, not a name' — which prevents the most likely misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the smart-contract platforms (blockchains such as ethereum, bnb, polygon) for which CoinPaprika indexes token contracts. Use for 'which chains are supported for contract lookups', 'list contract platforms', or to pick a platform id before calling getContracts. Read-only; limit caps results. No API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| rationale | Yes | REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions. |
| Name | Required | Description |
|---|---|---|
| platforms | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotent, destructiveHint=false, openWorld), so the description doesn't need to. It still adds genuine context: 'No API key required' and 'limit caps results'. It doesn't say whether the list is stable/cached or what happens if limit exceeds available platforms, but with annotations carrying the safety load this is solid.
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?
Three tight sentences: purpose first, then usage triggers, then behavioral notes. Every clause carries information and nothing is repeated from the schema or annotations.
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 structure needn't be described, and the annotations cover the safety profile. Remaining minor gap is the 'limit' semantics and whether results are ordered/paginated, which the description leaves to the schema that doesn't document it either.
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 50%: the required 'rationale' parameter is fully documented in the schema, while 'limit' has only a default and no description. The phrase 'limit caps results' is the sole added semantics, and it doesn't say whether the value is a max count, has a ceiling, or what the default ordering is. Baseline 3 is appropriate given partial schema coverage.
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 ('List the smart-contract platforms') and immediately grounds it with concrete examples (ethereum, bnb, polygon) plus the indexing scope. An agent can distinguish it from getContracts, which the description explicitly positions as the consumer of this tool's output.
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 explicit use-case phrasings ('which chains are supported for contract lookups', 'list contract platforms') and names the follow-on tool: use this to pick a platform id before calling getContracts. The when-to-use and the relationship to the alternative are both spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details for one CoinPaprika tag (a category such as 'defi' or 'stablecoin'): its id, name, description, coin_counter, ico_counter, and optionally the coins and ICOs grouped under it. Use for 'what coins are in the defi tag', 'show the stablecoin category', 'tokens tagged ai'. To list every tag or find a tagId first use getTags. Read-only. Params: tagId (required) is a tag id from getTags such as 'defi'; additionalFields (optional, default none) is a comma-separated list of extra sections, valid values 'coins' and 'icos' (example 'coins,icos'). An unknown tagId returns an error. No API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| tagId | Yes | ||
| rationale | Yes | REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions. | |
| additionalFields | No |
| Name | Required | Description |
|---|---|---|
| id | No | |
| icos | No | |
| name | No | |
| type | No | |
| coins | No | Present when additionalFields=coins is requested. |
| description | No | |
| ico_counter | No | |
| coin_counter | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so 'Read-only' adds little, but the description contributes real extras: 'An unknown tagId returns an error' and 'No API key required' are auth/error behaviors not present in the annotations. It stops short of describing result size or pagination for the optional coin/ICO sections.
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?
Front-loaded with purpose and example intents before the parameter block, and nearly every clause carries information. It is dense but slightly run-on, and the trailing 'Read-only' restates an annotation without adding anything.
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 three-parameter read tool with an output schema, this covers purpose, sibling routing, both undocumented parameters with valid values, error behavior, and auth requirements. Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%, so the description carries the load and does so well: tagId is marked required with provenance ('from getTags such as defi'), and additionalFields gets a default ('none'), format ('comma-separated list'), and valid values ('coins', 'icos') plus an example — none of which appears in the schema. The required 'rationale' param is left to its own thorough schema 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 and resource ('Get details for one CoinPaprika tag'), enumerates the returned fields, and clarifies what a tag is with concrete examples ('defi', 'stablecoin'). It explicitly distinguishes itself from the sibling getTags, which lists all tags.
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 concrete user-intent phrasings ('what coins are in the defi tag', 'tokens tagged ai') that map to this tool and explicitly routes the alternative case ('to list every tag or find a tagId first use getTags'). The agent knows both when to call this and when to call a sibling instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all CoinPaprika tags (categories such as 'defi', 'stablecoin', 'memecoin', 'ai') used to group coins, returned as a list with each tag's id, name, coin_counter and ico_counter. Use for 'what crypto categories exist', 'list market sectors', or to find a tagId before calling getTagById. For the coins inside one tag use getTagById. Read-only. Params: additionalFields (optional, default none) is a comma-separated list of extra sections per tag, valid values 'coins' and 'icos' (example 'coins,icos'; omit for just summaries); limit (optional, default 50, max 250) caps how many tags return. No API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| rationale | Yes | REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions. | |
| additionalFields | No |
| Name | Required | Description |
|---|---|---|
| tags | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds value beyond that with 'No API key required' and the shape of what comes back (id, name, coin_counter, ico_counter), though it does not discuss rate limits or pagination behavior.
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?
Purpose, disambiguation and parameter rules are front-loaded and efficient. The enumeration of return fields is slightly wasteful given an output schema exists, and the single dense paragraph could be split, but no sentence is 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?
With an output schema present, the description need not explain return values, yet it still covers usage cases, sibling routing, auth requirements and both undocumented parameters. Nothing an agent needs to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, and the description fully compensates: it gives additionalFields' format (comma-separated), its exact valid values ('coins', 'icos') and an example, plus limit's default (50) and max (250). These are the very details the schema omits, including an effective enum the schema lacks.
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 ('List all CoinPaprika tags') with concrete examples of the category values, and explicitly distinguishes itself from the sibling getTagById ('For the coins inside one tag use getTagById'). An agent can select it without opening any 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?
Gives explicit trigger phrases ('what crypto categories exist', 'list market sectors'), a concrete precondition use case ('find a tagId before calling getTagById'), and names the alternative for the opposite need. When-to-use and when-not-to-use are both covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current price and market data of a token by its contract address (for on-chain and DeFi tokens). Use when you have a contract address (0x...) rather than a name. For history use getHistoricalTickerByContract. Read-only; platformId is the chain (e.g. eth-ethereum) and contractAddress the token address. No API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| rationale | Yes | REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions. | |
| platformId | Yes | ||
| contractAddress | Yes |
| Name | Required | Description |
|---|---|---|
| id | No | |
| name | No | |
| rank | No | |
| quotes | No | Keyed by quote currency code (e.g. 'USD', 'BTC'). |
| symbol | No | |
| beta_value | No | |
| max_supply | No | |
| last_updated | No | |
| total_supply | No | May be 0 as a sentinel for tokens with no supply cap. Cross-reference with CoinPaprika docs for sentinel semantics. |
| first_data_at | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the description's 'Read-only' line merely confirms them. It adds genuine context beyond annotations: 'No API key required' and the meaning of platformId/contractAddress. It does not discuss error behavior for unknown contract addresses or rate limits, so it stops short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences: purpose first, then the disambiguating selection rule, then parameter and auth notes. Every sentence carries information and nothing is repeated from the 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 an output schema present and annotations covering the safety profile, the description covers what an agent needs to select and call the tool. The remaining gap is that valid platformId identifiers aren't listed, forcing a lookup or a trial call.
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 only 33% (only 'rationale' is documented), so the description must compensate, and it does for both undocumented parameters: platformId is the chain with an example (eth-ethereum) and contractAddress is the token address. It does not enumerate valid platformId values, which would have made it a 5.
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 current price and market data of a token by contract address) and scopes it to on-chain/DeFi tokens. It is clearly distinguishable from getTickersById (which takes an id) and getHistoricalTickerByContract (history).
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 names the selecting condition ('when you have a contract address (0x...) rather than a name') and routes history requests to getHistoricalTickerByContract by name. No inference is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current prices, market caps and 24h changes for the top cryptocurrencies ranked by market cap. Use for 'top 5 coins', 'top crypto today', 'biggest cryptocurrencies', or a market snapshot. For one specific coin use getTickersById. Read-only; quotes sets the quote currencies (default USD), limit caps results. No API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| quotes | No | ||
| rationale | Yes | REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions. |
| Name | Required | Description |
|---|---|---|
| tickers | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds useful operational context: no API key is required, quotes sets quote currencies with a USD default, and limit caps results. It does not discuss rate limits or pagination, but the annotations lower the burden.
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 compact and front-loaded: purpose first, usage examples second, sibling alternative third, then parameter and auth notes. Every sentence adds useful information without repetition.
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, and annotations already cover the read-only, idempotent, open-world behavior. The description supplies enough additional detail about scope, alternative tools, auth, and the two main parameters for an agent to invoke it correctly.
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 low at 33%, with only rationale documented in the schema. The description compensates by explaining that quotes sets quote currencies and defaults to USD, and that limit caps the number of results. It does not specify quote formatting, but the added meaning over the schema is substantial.
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: fetching current prices, market caps, and 24h changes for top cryptocurrencies ranked by market cap. It clearly distinguishes this ranked-list tool from getTickersById, which is for one specific coin. An agent can identify the tool's purpose without opening the 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?
It gives explicit example use cases such as 'top 5 coins', 'top crypto today', and 'market snapshot'. It also names the alternative getTickersById for a single coin, making the when-to-use and when-not-to-use distinction clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current price, market cap, 24h change and volume of one cryptocurrency in USD or another quote currency. Use for 'what is the price of X', 'how much is Bitcoin worth', 'BTC to USD', 'ETH price now'. For past prices use getTickersHistoricalById. Read-only; coinId is a canonical id (resolve a bare symbol with resolveId first), quotes sets the quote currency (default USD). No API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| coinId | Yes | Canonical CoinPaprika coin slug in 'symbol-name' format, e.g. 'btc-bitcoin', 'eth-ethereum', 'ada-cardano'. Do NOT pass ticker symbols ('BTC', 'AAVE') or guess the slug; it is not derivable from the symbol (e.g. AAVE resolves to 'aave-new', which you could not guess). Call search or resolveId first to resolve a symbol or name to its canonical id. | |
| quotes | No | ||
| rationale | Yes | REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions. |
| Name | Required | Description |
|---|---|---|
| id | No | |
| name | No | |
| rank | No | |
| quotes | No | Keyed by quote currency code (e.g. 'USD', 'BTC'). |
| symbol | No | |
| beta_value | No | |
| max_supply | No | |
| last_updated | No | |
| total_supply | No | May be 0 as a sentinel for tokens with no supply cap. Cross-reference with CoinPaprika docs for sentinel semantics. |
| first_data_at | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered; the description adds non-obvious operational facts: no API key required, canonical-id requirement, and that quotes defaults to USD. It stops short of saying anything about rate limits or freshness/latency of the 'current' price, which matters for a price 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?
Front-loaded with the capability and payoff before routing guidance, and every sentence carries instruction or routing value. The example-utterance list is slightly padded and 'Read-only' restates the annotations, but nothing is genuinely 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?
An output schema exists, so return-shape explanation is correctly omitted, and the description covers the caller-side essentials: id resolution, quote currency, and the historical alternative. The only gap is that valid quote-currency values are not enumerated anywhere (the parameter has no enum or description in the schema).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% and the description compensates for the undocumented 'quotes' parameter by explaining it sets the quote currency with a USD default. It also reinforces the coinId semantics ('canonical id, resolve a bare symbol with resolveId first'), which the schema already covers well, so it adds meaning without much redundancy beyond that.
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 plus exactly which fields it returns (price, market cap, 24h change, volume) and in which currency. It also names the sibling to use for past prices (getTickersHistoricalById), so an agent can distinguish it from getTickers and getCoinById without opening any 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?
Gives explicit when-to-use phrasing tied to user utterances ('what is the price of X', 'BTC to USD') and an explicit exclusion routing to getTickersHistoricalById for historical values. It also names the prerequisite path (resolveId first) for bare symbols.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a coin's price, market cap and volume at past times as point-in-time snapshots (not OHLC candles). Use for 'price of BTC last Tuesday', 'ETH market cap on 2024-01-01'. For today's and yesterday's OHLC candles use getCoinOHLCVToday and getCoinOHLCVLatest; for the current price use getTickersById. Read-only. Params: coinId (required) canonical id like 'btc-bitcoin' (resolve via resolveId); start (required) and end (optional, default now) accept 'yyyy-mm-dd' or ISO 8601; interval (optional, default '5m'); quote (optional, default 'usd'); limit (optional, default 50, max 250) caps points. Requires a Starter+ plan (COINPAPRIKA_API_KEY). Free tier on this hosted server: daily intervals up to a year back and hourly intervals up to 24 hours back; anything else returns a structured CP402_PAID_ENDPOINT stub.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | Optional end timestamp. Same formats as start. Defaults to now if omitted. | |
| limit | No | Optional. Number of data points (default 50, max 250). | |
| quote | No | Optional quote currency code (default 'usd'). Examples: 'usd', 'btc', 'eth'. | usd |
| start | Yes | Required. Start timestamp. Accepts ISO 8601 ('2026-01-15T00:00:00Z') or date-only ('2026-01-15'). UTC. | |
| coinId | Yes | Canonical CoinPaprika coin slug in 'symbol-name' format, e.g. 'btc-bitcoin', 'eth-ethereum', 'ada-cardano'. Do NOT pass ticker symbols ('BTC', 'AAVE') or guess the slug; it is not derivable from the symbol (e.g. AAVE resolves to 'aave-new', which you could not guess). Call search or resolveId first to resolve a symbol or name to its canonical id. | |
| interval | No | Optional. Sampling interval, default '1d'. On this hosted server (free tier) daily and coarser intervals ('1d', '24h', '7d', '14d', '30d', '90d', '365d') are served for the last year and hourly ones ('1h', '2h', '3h', '6h', '12h') for the last 24 hours; minute intervals ('5m', '15m', '30m') and older ranges need a paid plan with your own key. Upstream supports additional intervals; consult CoinPaprika docs if you need something outside this list. | 1d |
| rationale | Yes | REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions. |
| Name | Required | Description |
|---|---|---|
| ticks | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, but the description adds substantial context beyond them: required Starter+ plan, API key requirement, free-tier range limits, and exactly what happens on an ineligible request (structured CP402_PAID_ENDPOINT stub). That is exactly the kind of behavioral disclosure an agent needs before calling.
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?
Front-loaded with purpose and the routing decision, then parameter notes, then constraints; no filler sentences. The parameter recap is somewhat redundant against a fully described schema, keeping it just short of a 5.
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 7-parameter read tool with an output schema, the description covers purpose, alternatives, plan gating and error behavior, so an agent has what it needs. The only gap is the interval default mismatch, which leaves ambiguity about the actual default sampling rate.
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 coinId, start, end, limit, quote and interval thoroughly, so the baseline is 3. The description restates most of that and adds the paid-plan interval matrix, but it also conflicts with the schema by declaring interval default '5m' while the schema default is '1d' — a discrepancy that could cause a wrong call.
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 coin's price, market cap and volume at past times as point-in-time snapshots') and explicitly distinguishes the output shape from OHLC candles. It also names the sibling tools that serve the neighboring use cases, so an agent can route without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete example queries ('price of BTC last Tuesday', 'ETH market cap on 2024-01-01') plus explicit exclusions pointing to getCoinOHLCVToday, getCoinOHLCVLatest and getTickersById. Plan-tier eligibility and the fallback CP402_PAID_ENDPOINT behavior are spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert an amount from one crypto or fiat to another at the current rate, e.g. 'how much is 0.5 BTC in USD', 'convert 100 USDC to EUR'. For a plain coin price without an amount, use getTickersById. Read-only; baseCurrencyId and quoteCurrencyId are canonical ids and amount is the quantity to convert. No API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | No | Optional. Amount of base currency to convert (default 1). Passing 0 returns a 0-valued response, which is rarely what you want; use 1 to get a unit-rate quote. | |
| rationale | Yes | REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions. | |
| baseCurrencyId | Yes | Required. Source CoinPaprika coin slug (e.g., 'btc-bitcoin'). Full slugs only; symbols like 'BTC' are rejected upstream. | |
| quoteCurrencyId | Yes | Required. Target CoinPaprika coin slug (e.g., 'usd-us-dollars', 'eth-ethereum'). |
| Name | Required | Description |
|---|---|---|
| price | No | |
| amount | No | |
| base_currency_id | No | |
| quote_currency_id | No | |
| base_currency_name | No | |
| quote_currency_name | No | |
| base_price_last_updated | No | |
| quote_price_last_updated | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so 'Read-only' is largely redundant. The description does add non-annotation context: 'at the current rate' (spot vs historical) and 'No API key required', which is genuine auth/setup information. It stops short of describing rate staleness or upstream error behavior, but with annotations covering the safety profile that is a minor 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?
Front-loaded with the verb and worked examples, then routing guidance, then parameter clarifications, then auth note. Dense and mostly waste-free, though the final sentence mixes param semantics and auth info in a slightly list-like way.
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?
Output schema exists so return values need no explanation, annotations cover the safety profile, and schema coverage is complete. The description supplies routing, examples, currency-id semantics and auth expectations — nothing an agent needs to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description still adds a compact semantic gloss — baseCurrencyId/quoteCurrencyId are 'canonical ids' and amount is 'the quantity to convert' — which reinforces the slug-vs-symbol trap the schema also warns about, slightly beating the baseline.
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 ('Convert an amount ... at the current rate') plus two concrete example queries, and explicitly contrasts with getTickersById for the plain-price case. An agent can distinguish it from siblings like getTickersById or getTickers without opening any 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?
Names the alternative (getTickersById) and the exact condition that should route the agent there: 'For a plain coin price without an amount'. It also implies the counterpart case (amount present → use this tool) via the examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a fuzzy coin, exchange, person or tag name or symbol to a ranked list of candidate CoinPaprika ids, best first (take the top one). Call FIRST when you have a bare name or symbol but need an id, since ids are not derivable, then pass the id to getTickersById for price. Returns candidates with id, name, symbol, type and rank; an empty list means no match. Read-only. Params: type (required; one of 'coin', 'exchange', 'people', 'tags') sets entity kind; query (required) is the fuzzy text; limit (optional, default 50, max 250) caps candidates. Answers 'id for AAVE', 'resolve Vitalik'. No API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | ||
| limit | No | ||
| query | Yes | ||
| rationale | Yes | REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions. |
| Name | Required | Description |
|---|---|---|
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint false. The description adds useful behavioral context beyond those annotations: results are ranked best-first, the return fields are listed, an empty list means no match, ids are not derivable, and no API key is required.
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 front-loaded with purpose and workflow, followed by terse parameter explanations, examples, and auth notes. Every sentence adds a distinct useful fact, with no filler or repetition of the 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?
Given the read-only, idempotent annotations and the presence of an output schema, the description covers trigger conditions, follow-up use, return value shape, failure semantics, and parameter constraints. Nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, so the description carries most of the parameter burden. It clearly explains type ('one of coin, exchange, people, tags sets entity kind'), query ('fuzzy text'), and limit ('optional, default 50, max 250'). However, it omits the required 'rationale' parameter from the natural-language params list, even though the schema itself documents rationale well.
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 ('Resolve'), a clear resource ('fuzzy coin, exchange, person or tag name or symbol'), and a definite outcome ('ranked list of candidate CoinPaprika ids, best first'). It also differentiates the tool from siblings by explaining it is the id-resolution step before getTickersById.
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 explicitly says 'Call FIRST when you have a bare name or symbol but need an id' and prescribes the follow-up action: 'pass the id to getTickersById for price.' This gives an agent concrete when-to-use guidance and prevents confusion with sibling lookup tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Broadly search CoinPaprika across coins, exchanges, ICOs, people and tags by name or symbol when the entity type is unknown or you are exploring. Use for 'find anything called X'. If you specifically need a coin's canonical id to fetch its price, prefer resolveId. Read-only; q is the query, categories filters entity types, limit caps results. No API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Required. Search query (case-insensitive, partial-match). | |
| limit | No | Optional. Items PER CATEGORY (not total). Default 50. | |
| modifier | No | Optional. Upstream-specific search modifier. | |
| rationale | Yes | REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions. | |
| categories | No | Optional. Comma-separated category filter: 'currencies', 'exchanges', 'icos', 'people', 'tags'. Omit to search all categories. |
| Name | Required | Description |
|---|---|---|
| icos | No | |
| tags | No | |
| people | No | |
| exchanges | No | |
| currencies | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the description's 'Read-only' adds little, but 'No API key required' discloses an auth requirement and 'limit caps results' flags a result-shape constraint worth knowing before calling. No destructive/permission caveats are missing for a read-only search.
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?
Front-loaded with the scope and the primary use case, and the alternative-tool routing follows before any parameter talk. The trailing sentence partially repeats annotation-declared facts (read-only) and schema facts, which costs it a point.
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 no explanation, and the annotations carry the safety profile. What remains for a broad multi-entity search — scope, category filtering, auth, and the resolveId escape hatch — is all present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all five params are documented upstream and the baseline is 3. The description's gloss ('q is the query, categories filters entity types, limit caps results') restates the schema and actually under-specifies limit, which the schema clarifies as per-category rather than total; the 'modifier' param goes unmentioned.
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 scope ('Broadly search CoinPaprika across coins, exchanges, ICOs, people and tags by name or symbol') and immediately distinguishes itself from resolveId for the canonical-id case. An agent can pick between this and the many get*By* siblings without opening a 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?
Gives explicit when-to-use ('entity type is unknown or you are exploring', 'find anything called X') and names the alternative with the condition that selects it ('If you specifically need a coin's canonical id to fetch its price, prefer resolveId'). Routing is fully determined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the CoinPaprika MCP server's status and configuration (uptime, mode, enabled features). Use when asked 'is the server up', 'what mode am I in', 'server status'. This reports the MCP server itself, not the crypto market; for market health use getGlobal. Read-only; takes no parameters and needs no API key.
| Name | Required | Description | Default |
|---|---|---|---|
| rationale | Yes | REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions. |
| Name | Required | Description |
|---|---|---|
| mode | No | |
| tier | No | |
| status | No | |
| api_base | No | |
| paid_features | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is structured data. The description still adds useful context beyond that: it needs no API key and reports server metadata rather than market data, which is a real disclosure. The only missing piece is what the status payload looks like, which the output schema covers.
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, front-loaded with the action and the returned fields, then the disambiguation and the read-only/credential note. Each clause carries distinct information with 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?
For a zero-business-argument, read-only status tool with an output schema and complete annotations, nothing an agent needs is absent. The description covers purpose, disambiguation and access requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the required 'rationale' parameter is fully documented in the schema and the baseline 3 applies. However, the description's claim that the tool 'takes no parameters' is imprecise given a mandatory rationale field exists, so it neither helps nor fully compensates here.
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 definition pairs a specific verb with a specific resource ('Get the CoinPaprika MCP server's status and configuration') and enumerates what that report contains (uptime, mode, enabled features). It also explicitly rules out the market-health reading that siblings like getGlobal provide, so an agent can separate the two 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?
It gives literal trigger utterances ('is the server up', 'what mode am I in', 'server status') and names the alternative tool, getGlobal, for the case the agent actually wants market health. Both the when and the when-not are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report a problem or gap back to the CoinPaprika MCP maintainers: call it when you got stuck, a response was unexpected, information you needed was missing, or a tool did not behave as documented. Use when the user says 'this is wrong', 'report this', 'that did not work'. Low friction, partial feedback is welcome, and every submission is read.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | REQUIRED: What you (or the user behind you) were trying to accomplish. | |
| expected | No | OPTIONAL: What you expected to happen. | |
| observed | No | OPTIONAL: What actually happened. | |
| severity | No | OPTIONAL: How badly this affected your task. Default 'minor'. | minor |
| blocked_at | No | OPTIONAL: Tool name or step where you got stuck. | |
| attempted_tools | No | OPTIONAL: List of tool names you called, in order, before submitting this feedback. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | True if the feedback row was persisted. |
| message | Yes | |
| severity | No | |
| tracking_id | No | Stable id agents can reference in follow-up submissions; null if persistence failed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare that this is a non-read-only, non-destructive, non-idempotent submission tool, and the description adds that partial feedback is welcome and every submission is read. It does not discuss privacy, rate limits, or exactly how submissions are processed, but it adds useful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded in the first sentence, and the second sentence efficiently adds usage triggers and tone. The description is appropriately sized with 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?
For a feedback-submission tool with full schema documentation, rich annotations, and an output schema, the description provides enough context to call it correctly. The agent knows when to use it, what to report, and that partial feedback is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all six parameters, including the required goal and optional expected/observed/severity fields. The description reinforces low-friction submission but adds no parameter-specific syntax or format details beyond the 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 action and target: report a problem or gap back to the CoinPaprika MCP maintainers. It is clearly distinguishable from all sibling tools, which are data-retrieval tools rather than feedback submission 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?
It explicitly lists when to call it: when stuck, when a response was unexpected, when needed information was missing, or when a tool did not behave as documented. It also names user phrasings such as 'this is wrong', 'report this', and 'that did not work', leaving little inference required.
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.
getCapabilities18 fields changedOutput schema / properties / api / additionalPropertiesRemoved value: -trueOutput schema / properties / api / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / api / propertiesRemoved value: -{}Output schema / properties / api / typeRemoved value: -"object"Output schema / properties / coin_id_format / additionalPropertiesRemoved value: -trueOutput schema / properties / coin_id_format / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / coin_id_format / propertiesRemoved value: -{}Output schema / properties / coin_id_format / typeRemoved value: -"object"Output schema / properties / note / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / plan_tiers / additionalPropertiesRemoved value: -trueOutput schema / properties / plan_tiers / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / plan_tiers / propertiesRemoved value: -{}Output schema / properties / plan_tiers / typeRemoved value: -"object"Output schema / properties / server / additionalPropertiesRemoved value: -trueOutput schema / properties / server / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / server / propertiesRemoved value: -{}Output schema / properties / server / typeRemoved value: -"object"Output schema / properties / tools_count / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]getCoinById7 fields changedOutput schema / properties / id / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / is_active / typePrevious value: -"boolean"New value: +[
+ "boolean",
+ "null"
+]Output schema / properties / is_new / typePrevious value: -"boolean"New value: +[
+ "boolean",
+ "null"
+]Output schema / properties / name / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / rank / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / symbol / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / type / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]getCoinEvents4 fields changedOutput schema / properties / events / items / additionalPropertiesRemoved value: -trueOutput schema / properties / events / items / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "date": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "date_to": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "description": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "is_conference": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "link": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "proof_image_link": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / events / items / propertiesRemoved value: -{
- "date": {
- "type": "string"
- },
- "date_to": {
- "type": [
- "string",
- "null"
- ]
- },
- "description": {
- "type": [
- "string",
- "null"
- ]
- },
- "id": {
- "type": "string"
- },
- "is_conference": {
- "type": "boolean"
- },
- "link": {
- "type": [
- "string",
- "null"
- ]
- },
- "name": {
- "type": "string"
- },
- "proof_image_link": {
- "type": [
- "string",
- "null"
- ]
- }
-}Output schema / properties / events / items / typeRemoved value: -"object"getCoinExchanges4 fields changedOutput schema / properties / exchanges / items / additionalPropertiesRemoved value: -trueOutput schema / properties / exchanges / items / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "active": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "adjusted_rank": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "api_status": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "currencies": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "description": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "fiats": {
+ "anyOf": [
+ {
+ "items": {},
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "last_updated": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "links": {},
+ "markets": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "markets_data_fetched": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "message": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "quotes": {
+ "anyOf": [
+ {
+ "additionalProperties": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {
+ "ath_date": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "ath_price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "market_cap": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "market_cap_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_12h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_15m": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_1h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_1y": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_30d": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_30m": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_6h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_7d": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_from_price_ath": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "volume_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "volume_24h_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "reported_rank": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "website_status": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / exchanges / items / propertiesRemoved value: -{
- "active": {
- "type": "boolean"
- },
- "adjusted_rank": {
- "type": [
- "number",
- "null"
- ]
- },
- "api_status": {
- "type": "boolean"
- },
- "currencies": {
- "type": "number"
- },
- "description": {
- "type": [
- "string",
- "null"
- ]
- },
- "fiats": {
- "items": {},
- "type": "array"
- },
- "id": {
- "type": "string"
- },
- "last_updated": {
- "type": "string"
- },
- "links": {},
- "markets": {
- "type": "number"
- },
- "markets_data_fetched": {
- "type": "boolean"
- },
- "message": {
- "type": [
- "string",
- "null"
- ]
- },
- "name": {
- "type": "string"
- },
- "quotes": {
- "additionalProperties": {
- "additionalProperties": true,
- "properties": {
- "ath_date": {
- "type": [
- "string",
- "null"
- ]
- },
- "ath_price": {
- "type": [
- "number",
- "null"
- ]
- },
- "market_cap": {
- "type": [
- "number",
- "null"
- ]
- },
- "market_cap_change_24h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_12h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_15m": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_1h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_1y": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_24h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_30d": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_30m": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_6h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_7d": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_from_price_ath": {
- "type": [
- "number",
- "null"
- ]
- },
- "price": {
- "type": [
- "number",
- "null"
- ]
- },
- "volume_24h": {
- "type": [
- "number",
- "null"
- ]
- },
- "volume_24h_change_24h": {
- "type": [
- "number",
- "null"
- ]
- }
- },
- "type": "object"
- },
- "type": "object"
- },
- "reported_rank": {
- "type": [
- "number",
- "null"
- ]
- },
- "website_status": {
- "type": "boolean"
- }
-}Output schema / properties / exchanges / items / typeRemoved value: -"object"getCoinMarkets4 fields changedOutput schema / properties / markets / items / additionalPropertiesRemoved value: -trueOutput schema / properties / markets / items / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "adjusted_volume_24h_share": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "base_currency_id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "base_currency_name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "category": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "exchange_id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "exchange_name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "fee_type": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "last_updated": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "market_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "outlier": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "pair": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "quote_currency_id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "quote_currency_name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "quotes": {
+ "anyOf": [
+ {
+ "additionalProperties": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {
+ "ath_date": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "ath_price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "market_cap": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "market_cap_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_12h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_15m": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_1h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_1y": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_30d": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_30m": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_6h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_7d": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_from_price_ath": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "volume_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "volume_24h_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / markets / items / propertiesRemoved value: -{
- "adjusted_volume_24h_share": {
- "type": "number"
- },
- "base_currency_id": {
- "type": "string"
- },
- "base_currency_name": {
- "type": "string"
- },
- "category": {
- "type": "string"
- },
- "exchange_id": {
- "type": "string"
- },
- "exchange_name": {
- "type": "string"
- },
- "fee_type": {
- "type": "string"
- },
- "last_updated": {
- "type": "string"
- },
- "market_url": {
- "type": [
- "string",
- "null"
- ]
- },
- "outlier": {
- "type": "boolean"
- },
- "pair": {
- "type": "string"
- },
- "quote_currency_id": {
- "type": "string"
- },
- "quote_currency_name": {
- "type": "string"
- },
- "quotes": {
- "additionalProperties": {
- "additionalProperties": true,
- "properties": {
- "ath_date": {
- "type": [
- "string",
- "null"
- ]
- },
- "ath_price": {
- "type": [
- "number",
- "null"
- ]
- },
- "market_cap": {
- "type": [
- "number",
- "null"
- ]
- },
- "market_cap_change_24h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_12h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_15m": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_1h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_1y": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_24h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_30d": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_30m": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_6h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_7d": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_from_price_ath": {
- "type": [
- "number",
- "null"
- ]
- },
- "price": {
- "type": [
- "number",
- "null"
- ]
- },
- "volume_24h": {
- "type": [
- "number",
- "null"
- ]
- },
- "volume_24h_change_24h": {
- "type": [
- "number",
- "null"
- ]
- }
- },
- "type": "object"
- },
- "type": "object"
- }
-}Output schema / properties / markets / items / typeRemoved value: -"object"getCoinOHLCVLatest4 fields changedOutput schema / properties / ohlcv / items / additionalPropertiesRemoved value: -trueOutput schema / properties / ohlcv / items / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "close": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "high": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "low": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "market_cap": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "open": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "time_close": {
+ "description": "ISO 8601 bucket close. Often '23:59:59Z' for daily candles, inclusive.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "time_open": {
+ "description": "ISO 8601 bucket open.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "volume": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / ohlcv / items / propertiesRemoved value: -{
- "close": {
- "type": "number"
- },
- "high": {
- "type": "number"
- },
- "low": {
- "type": "number"
- },
- "market_cap": {
- "type": [
- "number",
- "null"
- ]
- },
- "open": {
- "type": "number"
- },
- "time_close": {
- "description": "ISO 8601 bucket close. Often '23:59:59Z' for daily candles, inclusive.",
- "type": "string"
- },
- "time_open": {
- "description": "ISO 8601 bucket open.",
- "type": "string"
- },
- "volume": {
- "type": [
- "number",
- "null"
- ]
- }
-}Output schema / properties / ohlcv / items / typeRemoved value: -"object"getCoinOHLCVToday4 fields changedOutput schema / properties / ohlcv / items / additionalPropertiesRemoved value: -trueOutput schema / properties / ohlcv / items / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "close": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "high": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "low": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "market_cap": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "open": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "time_close": {
+ "description": "ISO 8601 bucket close. Often '23:59:59Z' for daily candles, inclusive.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "time_open": {
+ "description": "ISO 8601 bucket open.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "volume": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / ohlcv / items / propertiesRemoved value: -{
- "close": {
- "type": "number"
- },
- "high": {
- "type": "number"
- },
- "low": {
- "type": "number"
- },
- "market_cap": {
- "type": [
- "number",
- "null"
- ]
- },
- "open": {
- "type": "number"
- },
- "time_close": {
- "description": "ISO 8601 bucket close. Often '23:59:59Z' for daily candles, inclusive.",
- "type": "string"
- },
- "time_open": {
- "description": "ISO 8601 bucket open.",
- "type": "string"
- },
- "volume": {
- "type": [
- "number",
- "null"
- ]
- }
-}Output schema / properties / ohlcv / items / typeRemoved value: -"object"getCoins4 fields changedOutput schema / properties / coins / items / additionalPropertiesRemoved value: -trueOutput schema / properties / coins / items / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "id": {
+ "description": "CoinPaprika coin slug, format symbol-name (e.g. 'btc-bitcoin').",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "is_active": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "is_new": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "rank": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "symbol": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "type": {
+ "description": "'coin' or 'token'.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / coins / items / propertiesRemoved value: -{
- "id": {
- "description": "CoinPaprika coin slug, format symbol-name (e.g. 'btc-bitcoin').",
- "type": "string"
- },
- "is_active": {
- "type": "boolean"
- },
- "is_new": {
- "type": "boolean"
- },
- "name": {
- "type": "string"
- },
- "rank": {
- "type": "number"
- },
- "symbol": {
- "type": "string"
- },
- "type": {
- "description": "'coin' or 'token'.",
- "type": "string"
- }
-}Output schema / properties / coins / items / typeRemoved value: -"object"getContracts4 fields changedOutput schema / properties / contracts / items / additionalPropertiesRemoved value: -trueOutput schema / properties / contracts / items / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "address": {
+ "description": "Contract address on the platform. Lowercase canonical for EVM; case-sensitive for Solana.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "id": {
+ "description": "CoinPaprika coin slug (e.g. 'usdc-usd-coin').",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "is_active": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "rank": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "symbol": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "type": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / contracts / items / propertiesRemoved value: -{
- "address": {
- "description": "Contract address on the platform. Lowercase canonical for EVM; case-sensitive for Solana.",
- "type": "string"
- },
- "id": {
- "description": "CoinPaprika coin slug (e.g. 'usdc-usd-coin').",
- "type": "string"
- },
- "is_active": {
- "type": "boolean"
- },
- "name": {
- "type": "string"
- },
- "rank": {
- "type": "number"
- },
- "symbol": {
- "type": "string"
- },
- "type": {
- "type": "string"
- }
-}Output schema / properties / contracts / items / typeRemoved value: -"object"getExchangeByID12 fields changedOutput schema / properties / active / typePrevious value: -"boolean"New value: +[
+ "boolean",
+ "null"
+]Output schema / properties / api_status / typePrevious value: -"boolean"New value: +[
+ "boolean",
+ "null"
+]Output schema / properties / currencies / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / id / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / last_updated / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / markets / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / markets_data_fetched / typePrevious value: -"boolean"New value: +[
+ "boolean",
+ "null"
+]Output schema / properties / name / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / quotes / additionalPropertiesRemoved value: -{
- "additionalProperties": true,
- "properties": {
- "ath_date": {
- "type": [
- "string",
- "null"
- ]
- },
- "ath_price": {
- "type": [
- "number",
- "null"
- ]
- },
- "market_cap": {
- "type": [
- "number",
- "null"
- ]
- },
- "market_cap_change_24h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_12h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_15m": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_1h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_1y": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_24h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_30d": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_30m": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_6h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_7d": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_from_price_ath": {
- "type": [
- "number",
- "null"
- ]
- },
- "price": {
- "type": [
- "number",
- "null"
- ]
- },
- "volume_24h": {
- "type": [
- "number",
- "null"
- ]
- },
- "volume_24h_change_24h": {
- "type": [
- "number",
- "null"
- ]
- }
- },
- "type": "object"
-}Output schema / properties / quotes / anyOfAdded value: +[
+ {
+ "additionalProperties": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {
+ "ath_date": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "ath_price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "market_cap": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "market_cap_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_12h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_15m": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_1h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_1y": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_30d": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_30m": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_6h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_7d": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_from_price_ath": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "volume_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "volume_24h_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / quotes / typeRemoved value: -"object"Output schema / properties / website_status / typePrevious value: -"boolean"New value: +[
+ "boolean",
+ "null"
+]getExchangeMarkets4 fields changedOutput schema / properties / markets / items / additionalPropertiesRemoved value: -trueOutput schema / properties / markets / items / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "adjusted_volume_24h_share": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "base_currency_id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "base_currency_name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "category": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "fee_type": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "last_updated": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "market_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "outlier": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "pair": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "quote_currency_id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "quote_currency_name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "quotes": {
+ "anyOf": [
+ {
+ "additionalProperties": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {
+ "ath_date": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "ath_price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "market_cap": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "market_cap_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_12h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_15m": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_1h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_1y": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_30d": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_30m": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_6h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_7d": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_from_price_ath": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "volume_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "volume_24h_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / markets / items / propertiesRemoved value: -{
- "adjusted_volume_24h_share": {
- "type": "number"
- },
- "base_currency_id": {
- "type": "string"
- },
- "base_currency_name": {
- "type": "string"
- },
- "category": {
- "type": "string"
- },
- "fee_type": {
- "type": "string"
- },
- "last_updated": {
- "type": "string"
- },
- "market_url": {
- "type": [
- "string",
- "null"
- ]
- },
- "outlier": {
- "type": "boolean"
- },
- "pair": {
- "type": "string"
- },
- "quote_currency_id": {
- "type": "string"
- },
- "quote_currency_name": {
- "type": "string"
- },
- "quotes": {
- "additionalProperties": {
- "additionalProperties": true,
- "properties": {
- "ath_date": {
- "type": [
- "string",
- "null"
- ]
- },
- "ath_price": {
- "type": [
- "number",
- "null"
- ]
- },
- "market_cap": {
- "type": [
- "number",
- "null"
- ]
- },
- "market_cap_change_24h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_12h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_15m": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_1h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_1y": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_24h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_30d": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_30m": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_6h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_7d": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_from_price_ath": {
- "type": [
- "number",
- "null"
- ]
- },
- "price": {
- "type": [
- "number",
- "null"
- ]
- },
- "volume_24h": {
- "type": [
- "number",
- "null"
- ]
- },
- "volume_24h_change_24h": {
- "type": [
- "number",
- "null"
- ]
- }
- },
- "type": "object"
- },
- "type": "object"
- }
-}Output schema / properties / markets / items / typeRemoved value: -"object"getExchanges4 fields changedOutput schema / properties / exchanges / items / additionalPropertiesRemoved value: -trueOutput schema / properties / exchanges / items / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "active": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "adjusted_rank": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "api_status": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "currencies": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "description": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "fiats": {
+ "anyOf": [
+ {
+ "items": {},
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "last_updated": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "links": {},
+ "markets": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "markets_data_fetched": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "message": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "quotes": {
+ "anyOf": [
+ {
+ "additionalProperties": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {
+ "ath_date": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "ath_price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "market_cap": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "market_cap_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_12h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_15m": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_1h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_1y": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_30d": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_30m": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_6h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_7d": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_from_price_ath": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "volume_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "volume_24h_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "reported_rank": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "website_status": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / exchanges / items / propertiesRemoved value: -{
- "active": {
- "type": "boolean"
- },
- "adjusted_rank": {
- "type": [
- "number",
- "null"
- ]
- },
- "api_status": {
- "type": "boolean"
- },
- "currencies": {
- "type": "number"
- },
- "description": {
- "type": [
- "string",
- "null"
- ]
- },
- "fiats": {
- "items": {},
- "type": "array"
- },
- "id": {
- "type": "string"
- },
- "last_updated": {
- "type": "string"
- },
- "links": {},
- "markets": {
- "type": "number"
- },
- "markets_data_fetched": {
- "type": "boolean"
- },
- "message": {
- "type": [
- "string",
- "null"
- ]
- },
- "name": {
- "type": "string"
- },
- "quotes": {
- "additionalProperties": {
- "additionalProperties": true,
- "properties": {
- "ath_date": {
- "type": [
- "string",
- "null"
- ]
- },
- "ath_price": {
- "type": [
- "number",
- "null"
- ]
- },
- "market_cap": {
- "type": [
- "number",
- "null"
- ]
- },
- "market_cap_change_24h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_12h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_15m": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_1h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_1y": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_24h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_30d": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_30m": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_6h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_7d": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_from_price_ath": {
- "type": [
- "number",
- "null"
- ]
- },
- "price": {
- "type": [
- "number",
- "null"
- ]
- },
- "volume_24h": {
- "type": [
- "number",
- "null"
- ]
- },
- "volume_24h_change_24h": {
- "type": [
- "number",
- "null"
- ]
- }
- },
- "type": "object"
- },
- "type": "object"
- },
- "reported_rank": {
- "type": [
- "number",
- "null"
- ]
- },
- "website_status": {
- "type": "boolean"
- }
-}Output schema / properties / exchanges / items / typeRemoved value: -"object"getHistoricalTickerByContract4 fields changedOutput schema / properties / ticks / items / additionalPropertiesRemoved value: -trueOutput schema / properties / ticks / items / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "market_cap": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "timestamp": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "volume_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / ticks / items / propertiesRemoved value: -{
- "market_cap": {
- "type": [
- "number",
- "null"
- ]
- },
- "price": {
- "type": "number"
- },
- "timestamp": {
- "type": "string"
- },
- "volume_24h": {
- "type": [
- "number",
- "null"
- ]
- }
-}Output schema / properties / ticks / items / typeRemoved value: -"object"getPeopleById3 fields changedOutput schema / properties / id / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / name / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / teams_count / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]getPlatforms1 field changedOutput schema / properties / platforms / items / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]getTagById7 fields changedOutput schema / properties / coin_counter / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / coins / items / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / ico_counter / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / icos / items / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / id / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / name / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / type / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]getTags4 fields changedOutput schema / properties / tags / items / additionalPropertiesRemoved value: -trueOutput schema / properties / tags / items / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "coin_counter": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "coins": {
+ "anyOf": [
+ {
+ "items": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Present when additionalFields=coins is requested."
+ },
+ "description": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "ico_counter": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "icos": {
+ "anyOf": [
+ {
+ "items": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "type": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / tags / items / propertiesRemoved value: -{
- "coin_counter": {
- "type": "number"
- },
- "coins": {
- "description": "Present when additionalFields=coins is requested.",
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "description": {
- "type": [
- "string",
- "null"
- ]
- },
- "ico_counter": {
- "type": "number"
- },
- "icos": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "id": {
- "type": "string"
- },
- "name": {
- "type": "string"
- },
- "type": {
- "type": "string"
- }
-}Output schema / properties / tags / items / typeRemoved value: -"object"getTickerByContract9 fields changedOutput schema / properties / first_data_at / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / id / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / last_updated / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / name / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / quotes / additionalPropertiesRemoved value: -{
- "additionalProperties": true,
- "properties": {
- "ath_date": {
- "type": [
- "string",
- "null"
- ]
- },
- "ath_price": {
- "type": [
- "number",
- "null"
- ]
- },
- "market_cap": {
- "type": [
- "number",
- "null"
- ]
- },
- "market_cap_change_24h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_12h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_15m": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_1h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_1y": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_24h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_30d": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_30m": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_6h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_7d": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_from_price_ath": {
- "type": [
- "number",
- "null"
- ]
- },
- "price": {
- "type": [
- "number",
- "null"
- ]
- },
- "volume_24h": {
- "type": [
- "number",
- "null"
- ]
- },
- "volume_24h_change_24h": {
- "type": [
- "number",
- "null"
- ]
- }
- },
- "type": "object"
-}Output schema / properties / quotes / anyOfAdded value: +[
+ {
+ "additionalProperties": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {
+ "ath_date": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "ath_price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "market_cap": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "market_cap_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_12h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_15m": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_1h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_1y": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_30d": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_30m": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_6h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_7d": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_from_price_ath": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "volume_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "volume_24h_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / quotes / typeRemoved value: -"object"Output schema / properties / rank / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / symbol / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]getTickers4 fields changedOutput schema / properties / tickers / items / additionalPropertiesRemoved value: -trueOutput schema / properties / tickers / items / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "beta_value": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "first_data_at": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "last_updated": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "max_supply": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "quotes": {
+ "anyOf": [
+ {
+ "additionalProperties": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {
+ "ath_date": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "ath_price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "market_cap": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "market_cap_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_12h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_15m": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_1h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_1y": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_30d": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_30m": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_6h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_7d": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_from_price_ath": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "volume_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "volume_24h_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Keyed by quote currency code (e.g. 'USD', 'BTC')."
+ },
+ "rank": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "symbol": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "total_supply": {
+ "description": "May be 0 as a sentinel for tokens with no supply cap. Cross-reference with CoinPaprika docs for sentinel semantics.",
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / tickers / items / propertiesRemoved value: -{
- "beta_value": {
- "type": [
- "number",
- "null"
- ]
- },
- "first_data_at": {
- "type": "string"
- },
- "id": {
- "type": "string"
- },
- "last_updated": {
- "type": "string"
- },
- "max_supply": {
- "type": [
- "number",
- "null"
- ]
- },
- "name": {
- "type": "string"
- },
- "quotes": {
- "additionalProperties": {
- "additionalProperties": true,
- "properties": {
- "ath_date": {
- "type": [
- "string",
- "null"
- ]
- },
- "ath_price": {
- "type": [
- "number",
- "null"
- ]
- },
- "market_cap": {
- "type": [
- "number",
- "null"
- ]
- },
- "market_cap_change_24h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_12h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_15m": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_1h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_1y": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_24h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_30d": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_30m": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_6h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_7d": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_from_price_ath": {
- "type": [
- "number",
- "null"
- ]
- },
- "price": {
- "type": [
- "number",
- "null"
- ]
- },
- "volume_24h": {
- "type": [
- "number",
- "null"
- ]
- },
- "volume_24h_change_24h": {
- "type": [
- "number",
- "null"
- ]
- }
- },
- "type": "object"
- },
- "description": "Keyed by quote currency code (e.g. 'USD', 'BTC').",
- "type": "object"
- },
- "rank": {
- "type": "number"
- },
- "symbol": {
- "type": "string"
- },
- "total_supply": {
- "description": "May be 0 as a sentinel for tokens with no supply cap. Cross-reference with CoinPaprika docs for sentinel semantics.",
- "type": [
- "number",
- "null"
- ]
- }
-}Output schema / properties / tickers / items / typeRemoved value: -"object"getTickersById9 fields changedOutput schema / properties / first_data_at / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / id / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / last_updated / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / name / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / quotes / additionalPropertiesRemoved value: -{
- "additionalProperties": true,
- "properties": {
- "ath_date": {
- "type": [
- "string",
- "null"
- ]
- },
- "ath_price": {
- "type": [
- "number",
- "null"
- ]
- },
- "market_cap": {
- "type": [
- "number",
- "null"
- ]
- },
- "market_cap_change_24h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_12h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_15m": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_1h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_1y": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_24h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_30d": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_30m": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_6h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_7d": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_from_price_ath": {
- "type": [
- "number",
- "null"
- ]
- },
- "price": {
- "type": [
- "number",
- "null"
- ]
- },
- "volume_24h": {
- "type": [
- "number",
- "null"
- ]
- },
- "volume_24h_change_24h": {
- "type": [
- "number",
- "null"
- ]
- }
- },
- "type": "object"
-}Output schema / properties / quotes / anyOfAdded value: +[
+ {
+ "additionalProperties": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {
+ "ath_date": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "ath_price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "market_cap": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "market_cap_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_12h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_15m": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_1h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_1y": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_30d": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_30m": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_6h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_7d": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_from_price_ath": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "volume_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "volume_24h_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / quotes / typeRemoved value: -"object"Output schema / properties / rank / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / symbol / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]getTickersHistoricalById4 fields changedOutput schema / properties / ticks / items / additionalPropertiesRemoved value: -trueOutput schema / properties / ticks / items / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "market_cap": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "timestamp": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "volume_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / ticks / items / propertiesRemoved value: -{
- "market_cap": {
- "type": [
- "number",
- "null"
- ]
- },
- "price": {
- "type": "number"
- },
- "timestamp": {
- "type": "string"
- },
- "volume_24h": {
- "type": [
- "number",
- "null"
- ]
- }
-}Output schema / properties / ticks / items / typeRemoved value: -"object"priceConverter8 fields changedOutput schema / properties / amount / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / base_currency_id / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / base_currency_name / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / base_price_last_updated / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / price / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Output schema / properties / quote_currency_id / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / quote_currency_name / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / quote_price_last_updated / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]search16 fields changedOutput schema / properties / currencies / items / additionalPropertiesRemoved value: -trueOutput schema / properties / currencies / items / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "id": {
+ "description": "CoinPaprika coin slug, format symbol-name (e.g. 'btc-bitcoin').",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "is_active": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "is_new": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "rank": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "symbol": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "type": {
+ "description": "'coin' or 'token'.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / currencies / items / propertiesRemoved value: -{
- "id": {
- "description": "CoinPaprika coin slug, format symbol-name (e.g. 'btc-bitcoin').",
- "type": "string"
- },
- "is_active": {
- "type": "boolean"
- },
- "is_new": {
- "type": "boolean"
- },
- "name": {
- "type": "string"
- },
- "rank": {
- "type": "number"
- },
- "symbol": {
- "type": "string"
- },
- "type": {
- "description": "'coin' or 'token'.",
- "type": "string"
- }
-}Output schema / properties / currencies / items / typeRemoved value: -"object"Output schema / properties / exchanges / items / additionalPropertiesRemoved value: -trueOutput schema / properties / exchanges / items / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "active": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "adjusted_rank": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "api_status": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "currencies": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "description": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "fiats": {
+ "anyOf": [
+ {
+ "items": {},
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "last_updated": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "links": {},
+ "markets": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "markets_data_fetched": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "message": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "quotes": {
+ "anyOf": [
+ {
+ "additionalProperties": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {
+ "ath_date": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "ath_price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "market_cap": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "market_cap_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_12h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_15m": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_1h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_1y": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_30d": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_30m": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_6h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_7d": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_from_price_ath": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "volume_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "volume_24h_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "reported_rank": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "website_status": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / exchanges / items / propertiesRemoved value: -{
- "active": {
- "type": "boolean"
- },
- "adjusted_rank": {
- "type": [
- "number",
- "null"
- ]
- },
- "api_status": {
- "type": "boolean"
- },
- "currencies": {
- "type": "number"
- },
- "description": {
- "type": [
- "string",
- "null"
- ]
- },
- "fiats": {
- "items": {},
- "type": "array"
- },
- "id": {
- "type": "string"
- },
- "last_updated": {
- "type": "string"
- },
- "links": {},
- "markets": {
- "type": "number"
- },
- "markets_data_fetched": {
- "type": "boolean"
- },
- "message": {
- "type": [
- "string",
- "null"
- ]
- },
- "name": {
- "type": "string"
- },
- "quotes": {
- "additionalProperties": {
- "additionalProperties": true,
- "properties": {
- "ath_date": {
- "type": [
- "string",
- "null"
- ]
- },
- "ath_price": {
- "type": [
- "number",
- "null"
- ]
- },
- "market_cap": {
- "type": [
- "number",
- "null"
- ]
- },
- "market_cap_change_24h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_12h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_15m": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_1h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_1y": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_24h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_30d": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_30m": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_6h": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_change_7d": {
- "type": [
- "number",
- "null"
- ]
- },
- "percent_from_price_ath": {
- "type": [
- "number",
- "null"
- ]
- },
- "price": {
- "type": [
- "number",
- "null"
- ]
- },
- "volume_24h": {
- "type": [
- "number",
- "null"
- ]
- },
- "volume_24h_change_24h": {
- "type": [
- "number",
- "null"
- ]
- }
- },
- "type": "object"
- },
- "type": "object"
- },
- "reported_rank": {
- "type": [
- "number",
- "null"
- ]
- },
- "website_status": {
- "type": "boolean"
- }
-}Output schema / properties / exchanges / items / typeRemoved value: -"object"Output schema / properties / people / items / additionalPropertiesRemoved value: -trueOutput schema / properties / people / items / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "description": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "links": {},
+ "name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "positions": {
+ "anyOf": [
+ {
+ "items": {},
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "teams_count": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / people / items / propertiesRemoved value: -{
- "description": {
- "type": [
- "string",
- "null"
- ]
- },
- "id": {
- "type": "string"
- },
- "links": {},
- "name": {
- "type": "string"
- },
- "positions": {
- "items": {},
- "type": "array"
- },
- "teams_count": {
- "type": "number"
- }
-}Output schema / properties / people / items / typeRemoved value: -"object"Output schema / properties / tags / items / additionalPropertiesRemoved value: -trueOutput schema / properties / tags / items / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "coin_counter": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "coins": {
+ "anyOf": [
+ {
+ "items": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Present when additionalFields=coins is requested."
+ },
+ "description": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "ico_counter": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "icos": {
+ "anyOf": [
+ {
+ "items": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "type": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / tags / items / propertiesRemoved value: -{
- "coin_counter": {
- "type": "number"
- },
- "coins": {
- "description": "Present when additionalFields=coins is requested.",
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "description": {
- "type": [
- "string",
- "null"
- ]
- },
- "ico_counter": {
- "type": "number"
- },
- "icos": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "id": {
- "type": "string"
- },
- "name": {
- "type": "string"
- },
- "type": {
- "type": "string"
- }
-}Output schema / properties / tags / items / typeRemoved value: -"object"status5 fields changedOutput schema / properties / api_base / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / mode / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / paid_features / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / status / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / tier / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]submitFeedback5 fields changedOutput schema / properties / message / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / ok / typePrevious value: -"boolean"New value: +[
+ "boolean",
+ "null"
+]Output schema / properties / severity / anyOfAdded value: +[
+ {
+ "enum": [
+ "blocker",
+ "major",
+ "minor",
+ "nit"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / severity / enumRemoved value: -[
- "blocker",
- "major",
- "minor",
- "nit"
-]Output schema / properties / severity / typeRemoved value: -"string"getTickerByContract1 field changedOutput schema / properties / circulating_supplyRemoved value: -{
- "type": [
- "number",
- "null"
- ]
-}getTickers1 field changedOutput schema / properties / tickers / items / properties / circulating_supplyRemoved value: -{
- "type": [
- "number",
- "null"
- ]
-}getTickersById1 field changedOutput schema / properties / circulating_supplyRemoved value: -{
- "type": [
- "number",
- "null"
- ]
-}submitFeedback3 fields changedInput schema / properties / attempted_tools / items / maxLengthAdded value: +100Input schema / properties / attempted_tools / maxItemsAdded value: +50Input schema / properties / blocked_at / maxLengthAdded value: +200getChangelogIDsgetCoinOHLCVHistoricalgetMappingskeyInfogetCapabilities2 fields changedInput schema / properties / rationale / descriptionPrevious value: -"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets — use generic descriptions."New value: +"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "api": {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ },
+ "coin_id_format": {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ },
+ "note": {
+ "type": "string"
+ },
+ "plan_tiers": {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ },
+ "server": {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ },
+ "tools_count": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "server",
+ "api",
+ "plan_tiers"
+ ],
+ "type": "object"
+}getChangelogIDs2 fields changedInput schema / properties / rationale / descriptionPrevious value: -"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets — use generic descriptions."New value: +"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "ids": {
+ "items": {},
+ "type": "array"
+ }
+ },
+ "required": [
+ "ids"
+ ],
+ "type": "object"
+}getCoinById3 fields changedInput schema / properties / coinId / descriptionPrevious value: -"Canonical CoinPaprika coin slug in 'symbol-name' format, e.g. 'btc-bitcoin', 'eth-ethereum', 'ada-cardano'. Do NOT pass ticker symbols ('BTC', 'AAVE') or guess the slug — it is not derivable from the symbol (e.g. AAVE resolves to 'aave-new', which you could not guess). Call search or resolveId first to resolve a symbol or name to its canonical id."New value: +"Canonical CoinPaprika coin slug in 'symbol-name' format, e.g. 'btc-bitcoin', 'eth-ethereum', 'ada-cardano'. Do NOT pass ticker symbols ('BTC', 'AAVE') or guess the slug; it is not derivable from the symbol (e.g. AAVE resolves to 'aave-new', which you could not guess). Call search or resolveId first to resolve a symbol or name to its canonical id."Input schema / properties / rationale / descriptionPrevious value: -"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets — use generic descriptions."New value: +"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "id": {
+ "description": "CoinPaprika coin slug, format symbol-name (e.g. 'btc-bitcoin').",
+ "type": "string"
+ },
+ "is_active": {
+ "type": "boolean"
+ },
+ "is_new": {
+ "type": "boolean"
+ },
+ "name": {
+ "type": "string"
+ },
+ "rank": {
+ "type": "number"
+ },
+ "symbol": {
+ "type": "string"
+ },
+ "type": {
+ "description": "'coin' or 'token'.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+}getCoinEvents3 fields changedInput schema / properties / coinId / descriptionPrevious value: -"Canonical CoinPaprika coin slug in 'symbol-name' format, e.g. 'btc-bitcoin', 'eth-ethereum', 'ada-cardano'. Do NOT pass ticker symbols ('BTC', 'AAVE') or guess the slug — it is not derivable from the symbol (e.g. AAVE resolves to 'aave-new', which you could not guess). Call search or resolveId first to resolve a symbol or name to its canonical id."New value: +"Canonical CoinPaprika coin slug in 'symbol-name' format, e.g. 'btc-bitcoin', 'eth-ethereum', 'ada-cardano'. Do NOT pass ticker symbols ('BTC', 'AAVE') or guess the slug; it is not derivable from the symbol (e.g. AAVE resolves to 'aave-new', which you could not guess). Call search or resolveId first to resolve a symbol or name to its canonical id."Input schema / properties / rationale / descriptionPrevious value: -"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets — use generic descriptions."New value: +"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "events": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "date": {
+ "type": "string"
+ },
+ "date_to": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "description": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "id": {
+ "type": "string"
+ },
+ "is_conference": {
+ "type": "boolean"
+ },
+ "link": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "type": "string"
+ },
+ "proof_image_link": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "events"
+ ],
+ "type": "object"
+}getCoinExchanges3 fields changedInput schema / properties / coinId / descriptionPrevious value: -"Canonical CoinPaprika coin slug in 'symbol-name' format, e.g. 'btc-bitcoin', 'eth-ethereum', 'ada-cardano'. Do NOT pass ticker symbols ('BTC', 'AAVE') or guess the slug — it is not derivable from the symbol (e.g. AAVE resolves to 'aave-new', which you could not guess). Call search or resolveId first to resolve a symbol or name to its canonical id."New value: +"Canonical CoinPaprika coin slug in 'symbol-name' format, e.g. 'btc-bitcoin', 'eth-ethereum', 'ada-cardano'. Do NOT pass ticker symbols ('BTC', 'AAVE') or guess the slug; it is not derivable from the symbol (e.g. AAVE resolves to 'aave-new', which you could not guess). Call search or resolveId first to resolve a symbol or name to its canonical id."Input schema / properties / rationale / descriptionPrevious value: -"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets — use generic descriptions."New value: +"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "exchanges": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "active": {
+ "type": "boolean"
+ },
+ "adjusted_rank": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "api_status": {
+ "type": "boolean"
+ },
+ "currencies": {
+ "type": "number"
+ },
+ "description": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "fiats": {
+ "items": {},
+ "type": "array"
+ },
+ "id": {
+ "type": "string"
+ },
+ "last_updated": {
+ "type": "string"
+ },
+ "links": {},
+ "markets": {
+ "type": "number"
+ },
+ "markets_data_fetched": {
+ "type": "boolean"
+ },
+ "message": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "type": "string"
+ },
+ "quotes": {
+ "additionalProperties": {
+ "additionalProperties": true,
+ "properties": {
+ "ath_date": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "ath_price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "market_cap": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "market_cap_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_12h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_15m": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_1h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_1y": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_30d": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_30m": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_6h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_7d": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_from_price_ath": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "volume_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "volume_24h_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "object"
+ },
+ "reported_rank": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "website_status": {
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "exchanges"
+ ],
+ "type": "object"
+}getCoinMarkets3 fields changedInput schema / properties / coinId / descriptionPrevious value: -"Canonical CoinPaprika coin slug in 'symbol-name' format, e.g. 'btc-bitcoin', 'eth-ethereum', 'ada-cardano'. Do NOT pass ticker symbols ('BTC', 'AAVE') or guess the slug — it is not derivable from the symbol (e.g. AAVE resolves to 'aave-new', which you could not guess). Call search or resolveId first to resolve a symbol or name to its canonical id."New value: +"Canonical CoinPaprika coin slug in 'symbol-name' format, e.g. 'btc-bitcoin', 'eth-ethereum', 'ada-cardano'. Do NOT pass ticker symbols ('BTC', 'AAVE') or guess the slug; it is not derivable from the symbol (e.g. AAVE resolves to 'aave-new', which you could not guess). Call search or resolveId first to resolve a symbol or name to its canonical id."Input schema / properties / rationale / descriptionPrevious value: -"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets — use generic descriptions."New value: +"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "markets": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "adjusted_volume_24h_share": {
+ "type": "number"
+ },
+ "base_currency_id": {
+ "type": "string"
+ },
+ "base_currency_name": {
+ "type": "string"
+ },
+ "category": {
+ "type": "string"
+ },
+ "exchange_id": {
+ "type": "string"
+ },
+ "exchange_name": {
+ "type": "string"
+ },
+ "fee_type": {
+ "type": "string"
+ },
+ "last_updated": {
+ "type": "string"
+ },
+ "market_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "outlier": {
+ "type": "boolean"
+ },
+ "pair": {
+ "type": "string"
+ },
+ "quote_currency_id": {
+ "type": "string"
+ },
+ "quote_currency_name": {
+ "type": "string"
+ },
+ "quotes": {
+ "additionalProperties": {
+ "additionalProperties": true,
+ "properties": {
+ "ath_date": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "ath_price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "market_cap": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "market_cap_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_12h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_15m": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_1h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_1y": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_30d": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_30m": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_6h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_7d": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_from_price_ath": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "volume_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "volume_24h_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "object"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "markets"
+ ],
+ "type": "object"
+}getCoinOHLCVHistorical3 fields changedInput schema / properties / coinId / descriptionPrevious value: -"Canonical CoinPaprika coin slug in 'symbol-name' format, e.g. 'btc-bitcoin', 'eth-ethereum', 'ada-cardano'. Do NOT pass ticker symbols ('BTC', 'AAVE') or guess the slug — it is not derivable from the symbol (e.g. AAVE resolves to 'aave-new', which you could not guess). Call search or resolveId first to resolve a symbol or name to its canonical id."New value: +"Canonical CoinPaprika coin slug in 'symbol-name' format, e.g. 'btc-bitcoin', 'eth-ethereum', 'ada-cardano'. Do NOT pass ticker symbols ('BTC', 'AAVE') or guess the slug; it is not derivable from the symbol (e.g. AAVE resolves to 'aave-new', which you could not guess). Call search or resolveId first to resolve a symbol or name to its canonical id."Input schema / properties / rationale / descriptionPrevious value: -"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets — use generic descriptions."New value: +"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "ohlcv": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "close": {
+ "type": "number"
+ },
+ "high": {
+ "type": "number"
+ },
+ "low": {
+ "type": "number"
+ },
+ "market_cap": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "open": {
+ "type": "number"
+ },
+ "time_close": {
+ "description": "ISO 8601 bucket close. Often '23:59:59Z' for daily candles, inclusive.",
+ "type": "string"
+ },
+ "time_open": {
+ "description": "ISO 8601 bucket open.",
+ "type": "string"
+ },
+ "volume": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "ohlcv"
+ ],
+ "type": "object"
+}getCoinOHLCVLatest3 fields changedInput schema / properties / coinId / descriptionPrevious value: -"Canonical CoinPaprika coin slug in 'symbol-name' format, e.g. 'btc-bitcoin', 'eth-ethereum', 'ada-cardano'. Do NOT pass ticker symbols ('BTC', 'AAVE') or guess the slug — it is not derivable from the symbol (e.g. AAVE resolves to 'aave-new', which you could not guess). Call search or resolveId first to resolve a symbol or name to its canonical id."New value: +"Canonical CoinPaprika coin slug in 'symbol-name' format, e.g. 'btc-bitcoin', 'eth-ethereum', 'ada-cardano'. Do NOT pass ticker symbols ('BTC', 'AAVE') or guess the slug; it is not derivable from the symbol (e.g. AAVE resolves to 'aave-new', which you could not guess). Call search or resolveId first to resolve a symbol or name to its canonical id."Input schema / properties / rationale / descriptionPrevious value: -"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets — use generic descriptions."New value: +"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "ohlcv": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "close": {
+ "type": "number"
+ },
+ "high": {
+ "type": "number"
+ },
+ "low": {
+ "type": "number"
+ },
+ "market_cap": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "open": {
+ "type": "number"
+ },
+ "time_close": {
+ "description": "ISO 8601 bucket close. Often '23:59:59Z' for daily candles, inclusive.",
+ "type": "string"
+ },
+ "time_open": {
+ "description": "ISO 8601 bucket open.",
+ "type": "string"
+ },
+ "volume": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "ohlcv"
+ ],
+ "type": "object"
+}getCoinOHLCVToday3 fields changedInput schema / properties / coinId / descriptionPrevious value: -"Canonical CoinPaprika coin slug in 'symbol-name' format, e.g. 'btc-bitcoin', 'eth-ethereum', 'ada-cardano'. Do NOT pass ticker symbols ('BTC', 'AAVE') or guess the slug — it is not derivable from the symbol (e.g. AAVE resolves to 'aave-new', which you could not guess). Call search or resolveId first to resolve a symbol or name to its canonical id."New value: +"Canonical CoinPaprika coin slug in 'symbol-name' format, e.g. 'btc-bitcoin', 'eth-ethereum', 'ada-cardano'. Do NOT pass ticker symbols ('BTC', 'AAVE') or guess the slug; it is not derivable from the symbol (e.g. AAVE resolves to 'aave-new', which you could not guess). Call search or resolveId first to resolve a symbol or name to its canonical id."Input schema / properties / rationale / descriptionPrevious value: -"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets — use generic descriptions."New value: +"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "ohlcv": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "close": {
+ "type": "number"
+ },
+ "high": {
+ "type": "number"
+ },
+ "low": {
+ "type": "number"
+ },
+ "market_cap": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "open": {
+ "type": "number"
+ },
+ "time_close": {
+ "description": "ISO 8601 bucket close. Often '23:59:59Z' for daily candles, inclusive.",
+ "type": "string"
+ },
+ "time_open": {
+ "description": "ISO 8601 bucket open.",
+ "type": "string"
+ },
+ "volume": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "ohlcv"
+ ],
+ "type": "object"
+}getCoins2 fields changedInput schema / properties / rationale / descriptionPrevious value: -"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets — use generic descriptions."New value: +"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "coins": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "id": {
+ "description": "CoinPaprika coin slug, format symbol-name (e.g. 'btc-bitcoin').",
+ "type": "string"
+ },
+ "is_active": {
+ "type": "boolean"
+ },
+ "is_new": {
+ "type": "boolean"
+ },
+ "name": {
+ "type": "string"
+ },
+ "rank": {
+ "type": "number"
+ },
+ "symbol": {
+ "type": "string"
+ },
+ "type": {
+ "description": "'coin' or 'token'.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "coins"
+ ],
+ "type": "object"
+}getContracts2 fields changedInput schema / properties / rationale / descriptionPrevious value: -"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets — use generic descriptions."New value: +"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "contracts": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "address": {
+ "description": "Contract address on the platform. Lowercase canonical for EVM; case-sensitive for Solana.",
+ "type": "string"
+ },
+ "id": {
+ "description": "CoinPaprika coin slug (e.g. 'usdc-usd-coin').",
+ "type": "string"
+ },
+ "is_active": {
+ "type": "boolean"
+ },
+ "name": {
+ "type": "string"
+ },
+ "rank": {
+ "type": "number"
+ },
+ "symbol": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "contracts"
+ ],
+ "type": "object"
+}getExchangeByID2 fields changedInput schema / properties / rationale / descriptionPrevious value: -"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets — use generic descriptions."New value: +"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "active": {
+ "type": "boolean"
+ },
+ "adjusted_rank": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "api_status": {
+ "type": "boolean"
+ },
+ "currencies": {
+ "type": "number"
+ },
+ "description": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "fiats": {
+ "items": {},
+ "type": "array"
+ },
+ "id": {
+ "type": "string"
+ },
+ "last_updated": {
+ "type": "string"
+ },
+ "links": {},
+ "markets": {
+ "type": "number"
+ },
+ "markets_data_fetched": {
+ "type": "boolean"
+ },
+ "message": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "type": "string"
+ },
+ "quotes": {
+ "additionalProperties": {
+ "additionalProperties": true,
+ "properties": {
+ "ath_date": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "ath_price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "market_cap": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "market_cap_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_12h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_15m": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_1h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_1y": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_30d": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_30m": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_6h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_7d": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_from_price_ath": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "volume_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "volume_24h_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "object"
+ },
+ "reported_rank": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "website_status": {
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+}getExchangeMarkets2 fields changedInput schema / properties / rationale / descriptionPrevious value: -"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets — use generic descriptions."New value: +"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "markets": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "adjusted_volume_24h_share": {
+ "type": "number"
+ },
+ "base_currency_id": {
+ "type": "string"
+ },
+ "base_currency_name": {
+ "type": "string"
+ },
+ "category": {
+ "type": "string"
+ },
+ "fee_type": {
+ "type": "string"
+ },
+ "last_updated": {
+ "type": "string"
+ },
+ "market_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "outlier": {
+ "type": "boolean"
+ },
+ "pair": {
+ "type": "string"
+ },
+ "quote_currency_id": {
+ "type": "string"
+ },
+ "quote_currency_name": {
+ "type": "string"
+ },
+ "quotes": {
+ "additionalProperties": {
+ "additionalProperties": true,
+ "properties": {
+ "ath_date": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "ath_price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "market_cap": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "market_cap_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_12h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_15m": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_1h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_1y": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_30d": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_30m": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_6h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_7d": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_from_price_ath": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "volume_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "volume_24h_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "object"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "markets"
+ ],
+ "type": "object"
+}getExchanges2 fields changedInput schema / properties / rationale / descriptionPrevious value: -"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets — use generic descriptions."New value: +"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "exchanges": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "active": {
+ "type": "boolean"
+ },
+ "adjusted_rank": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "api_status": {
+ "type": "boolean"
+ },
+ "currencies": {
+ "type": "number"
+ },
+ "description": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "fiats": {
+ "items": {},
+ "type": "array"
+ },
+ "id": {
+ "type": "string"
+ },
+ "last_updated": {
+ "type": "string"
+ },
+ "links": {},
+ "markets": {
+ "type": "number"
+ },
+ "markets_data_fetched": {
+ "type": "boolean"
+ },
+ "message": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "type": "string"
+ },
+ "quotes": {
+ "additionalProperties": {
+ "additionalProperties": true,
+ "properties": {
+ "ath_date": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "ath_price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "market_cap": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "market_cap_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_12h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_15m": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_1h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_1y": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_30d": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_30m": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_6h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_7d": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_from_price_ath": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "volume_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "volume_24h_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "object"
+ },
+ "reported_rank": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "website_status": {
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "exchanges"
+ ],
+ "type": "object"
+}getGlobal2 fields changedInput schema / properties / rationale / descriptionPrevious value: -"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets — use generic descriptions."New value: +"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+}getHistoricalTickerByContract4 fields changedInput schema / properties / interval / defaultPrevious value: -"5m"New value: +"1d"Input schema / properties / interval / descriptionPrevious value: -"Optional. Sampling interval. Common values: '5m', '15m', '30m', '1h', '6h', '12h', '24h', '7d', '14d', '30d'. Upstream supports additional intervals; consult CoinPaprika docs if you need something outside this list."New value: +"Optional. Sampling interval, default '1d'. On this hosted server (free tier) daily and coarser intervals ('1d', '24h', '7d', '14d', '30d', '90d', '365d') are served for the last year and hourly ones ('1h', '2h', '3h', '6h', '12h') for the last 24 hours; minute intervals ('5m', '15m', '30m') and older ranges need a paid plan with your own key. Upstream supports additional intervals; consult CoinPaprika docs if you need something outside this list."Input schema / properties / rationale / descriptionPrevious value: -"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets — use generic descriptions."New value: +"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "ticks": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "market_cap": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "price": {
+ "type": "number"
+ },
+ "timestamp": {
+ "type": "string"
+ },
+ "volume_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "ticks"
+ ],
+ "type": "object"
+}getMappings2 fields changedInput schema / properties / rationale / descriptionPrevious value: -"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets — use generic descriptions."New value: +"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "mappings": {
+ "items": {},
+ "type": "array"
+ }
+ },
+ "required": [
+ "mappings"
+ ],
+ "type": "object"
+}getPeopleById2 fields changedInput schema / properties / rationale / descriptionPrevious value: -"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets — use generic descriptions."New value: +"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "description": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "id": {
+ "type": "string"
+ },
+ "links": {},
+ "name": {
+ "type": "string"
+ },
+ "positions": {
+ "items": {},
+ "type": "array"
+ },
+ "teams_count": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+}getPlatforms2 fields changedInput schema / properties / rationale / descriptionPrevious value: -"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets — use generic descriptions."New value: +"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "platforms": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "platforms"
+ ],
+ "type": "object"
+}getTagById2 fields changedInput schema / properties / rationale / descriptionPrevious value: -"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets — use generic descriptions."New value: +"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "coin_counter": {
+ "type": "number"
+ },
+ "coins": {
+ "description": "Present when additionalFields=coins is requested.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "description": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "ico_counter": {
+ "type": "number"
+ },
+ "icos": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+}getTags2 fields changedInput schema / properties / rationale / descriptionPrevious value: -"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets — use generic descriptions."New value: +"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "tags": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "coin_counter": {
+ "type": "number"
+ },
+ "coins": {
+ "description": "Present when additionalFields=coins is requested.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "description": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "ico_counter": {
+ "type": "number"
+ },
+ "icos": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "tags"
+ ],
+ "type": "object"
+}getTickerByContract2 fields changedInput schema / properties / rationale / descriptionPrevious value: -"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets — use generic descriptions."New value: +"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "beta_value": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "circulating_supply": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "first_data_at": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "last_updated": {
+ "type": "string"
+ },
+ "max_supply": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "name": {
+ "type": "string"
+ },
+ "quotes": {
+ "additionalProperties": {
+ "additionalProperties": true,
+ "properties": {
+ "ath_date": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "ath_price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "market_cap": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "market_cap_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_12h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_15m": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_1h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_1y": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_30d": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_30m": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_6h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_7d": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_from_price_ath": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "volume_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "volume_24h_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "description": "Keyed by quote currency code (e.g. 'USD', 'BTC').",
+ "type": "object"
+ },
+ "rank": {
+ "type": "number"
+ },
+ "symbol": {
+ "type": "string"
+ },
+ "total_supply": {
+ "description": "May be 0 as a sentinel for tokens with no supply cap. Cross-reference with CoinPaprika docs for sentinel semantics.",
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+}getTickers2 fields changedInput schema / properties / rationale / descriptionPrevious value: -"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets — use generic descriptions."New value: +"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "tickers": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "beta_value": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "circulating_supply": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "first_data_at": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "last_updated": {
+ "type": "string"
+ },
+ "max_supply": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "name": {
+ "type": "string"
+ },
+ "quotes": {
+ "additionalProperties": {
+ "additionalProperties": true,
+ "properties": {
+ "ath_date": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "ath_price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "market_cap": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "market_cap_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_12h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_15m": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_1h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_1y": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_30d": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_30m": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_6h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_7d": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_from_price_ath": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "volume_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "volume_24h_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "description": "Keyed by quote currency code (e.g. 'USD', 'BTC').",
+ "type": "object"
+ },
+ "rank": {
+ "type": "number"
+ },
+ "symbol": {
+ "type": "string"
+ },
+ "total_supply": {
+ "description": "May be 0 as a sentinel for tokens with no supply cap. Cross-reference with CoinPaprika docs for sentinel semantics.",
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "tickers"
+ ],
+ "type": "object"
+}getTickersById3 fields changedInput schema / properties / coinId / descriptionPrevious value: -"Canonical CoinPaprika coin slug in 'symbol-name' format, e.g. 'btc-bitcoin', 'eth-ethereum', 'ada-cardano'. Do NOT pass ticker symbols ('BTC', 'AAVE') or guess the slug — it is not derivable from the symbol (e.g. AAVE resolves to 'aave-new', which you could not guess). Call search or resolveId first to resolve a symbol or name to its canonical id."New value: +"Canonical CoinPaprika coin slug in 'symbol-name' format, e.g. 'btc-bitcoin', 'eth-ethereum', 'ada-cardano'. Do NOT pass ticker symbols ('BTC', 'AAVE') or guess the slug; it is not derivable from the symbol (e.g. AAVE resolves to 'aave-new', which you could not guess). Call search or resolveId first to resolve a symbol or name to its canonical id."Input schema / properties / rationale / descriptionPrevious value: -"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets — use generic descriptions."New value: +"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "beta_value": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "circulating_supply": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "first_data_at": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "last_updated": {
+ "type": "string"
+ },
+ "max_supply": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "name": {
+ "type": "string"
+ },
+ "quotes": {
+ "additionalProperties": {
+ "additionalProperties": true,
+ "properties": {
+ "ath_date": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "ath_price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "market_cap": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "market_cap_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_12h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_15m": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_1h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_1y": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_30d": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_30m": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_6h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_7d": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_from_price_ath": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "volume_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "volume_24h_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "description": "Keyed by quote currency code (e.g. 'USD', 'BTC').",
+ "type": "object"
+ },
+ "rank": {
+ "type": "number"
+ },
+ "symbol": {
+ "type": "string"
+ },
+ "total_supply": {
+ "description": "May be 0 as a sentinel for tokens with no supply cap. Cross-reference with CoinPaprika docs for sentinel semantics.",
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+}getTickersHistoricalById5 fields changedInput schema / properties / coinId / descriptionPrevious value: -"Canonical CoinPaprika coin slug in 'symbol-name' format, e.g. 'btc-bitcoin', 'eth-ethereum', 'ada-cardano'. Do NOT pass ticker symbols ('BTC', 'AAVE') or guess the slug — it is not derivable from the symbol (e.g. AAVE resolves to 'aave-new', which you could not guess). Call search or resolveId first to resolve a symbol or name to its canonical id."New value: +"Canonical CoinPaprika coin slug in 'symbol-name' format, e.g. 'btc-bitcoin', 'eth-ethereum', 'ada-cardano'. Do NOT pass ticker symbols ('BTC', 'AAVE') or guess the slug; it is not derivable from the symbol (e.g. AAVE resolves to 'aave-new', which you could not guess). Call search or resolveId first to resolve a symbol or name to its canonical id."Input schema / properties / interval / defaultPrevious value: -"5m"New value: +"1d"Input schema / properties / interval / descriptionPrevious value: -"Optional. Sampling interval. Common values: '5m', '15m', '30m', '1h', '6h', '12h', '24h', '7d', '14d', '30d'. Upstream supports additional intervals; consult CoinPaprika docs if you need something outside this list."New value: +"Optional. Sampling interval, default '1d'. On this hosted server (free tier) daily and coarser intervals ('1d', '24h', '7d', '14d', '30d', '90d', '365d') are served for the last year and hourly ones ('1h', '2h', '3h', '6h', '12h') for the last 24 hours; minute intervals ('5m', '15m', '30m') and older ranges need a paid plan with your own key. Upstream supports additional intervals; consult CoinPaprika docs if you need something outside this list."Input schema / properties / rationale / descriptionPrevious value: -"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets — use generic descriptions."New value: +"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "ticks": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "market_cap": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "price": {
+ "type": "number"
+ },
+ "timestamp": {
+ "type": "string"
+ },
+ "volume_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "ticks"
+ ],
+ "type": "object"
+}keyInfo2 fields changedInput schema / properties / rationale / descriptionPrevious value: -"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets — use generic descriptions."New value: +"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "message": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+}priceConverter3 fields changedInput schema / properties / amount / descriptionPrevious value: -"Optional. Amount of base currency to convert (default 1). Passing 0 returns a 0-valued response, which is rarely what you want — use 1 to get a unit-rate quote."New value: +"Optional. Amount of base currency to convert (default 1). Passing 0 returns a 0-valued response, which is rarely what you want; use 1 to get a unit-rate quote."Input schema / properties / rationale / descriptionPrevious value: -"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets — use generic descriptions."New value: +"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "amount": {
+ "type": "number"
+ },
+ "base_currency_id": {
+ "type": "string"
+ },
+ "base_currency_name": {
+ "type": "string"
+ },
+ "base_price_last_updated": {
+ "type": "string"
+ },
+ "price": {
+ "type": "number"
+ },
+ "quote_currency_id": {
+ "type": "string"
+ },
+ "quote_currency_name": {
+ "type": "string"
+ },
+ "quote_price_last_updated": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+}resolveId2 fields changedInput schema / properties / rationale / descriptionPrevious value: -"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets — use generic descriptions."New value: +"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "results": {
+ "items": {},
+ "type": "array"
+ }
+ },
+ "required": [
+ "results"
+ ],
+ "type": "object"
+}search2 fields changedInput schema / properties / rationale / descriptionPrevious value: -"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets — use generic descriptions."New value: +"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "currencies": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "id": {
+ "description": "CoinPaprika coin slug, format symbol-name (e.g. 'btc-bitcoin').",
+ "type": "string"
+ },
+ "is_active": {
+ "type": "boolean"
+ },
+ "is_new": {
+ "type": "boolean"
+ },
+ "name": {
+ "type": "string"
+ },
+ "rank": {
+ "type": "number"
+ },
+ "symbol": {
+ "type": "string"
+ },
+ "type": {
+ "description": "'coin' or 'token'.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "exchanges": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "active": {
+ "type": "boolean"
+ },
+ "adjusted_rank": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "api_status": {
+ "type": "boolean"
+ },
+ "currencies": {
+ "type": "number"
+ },
+ "description": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "fiats": {
+ "items": {},
+ "type": "array"
+ },
+ "id": {
+ "type": "string"
+ },
+ "last_updated": {
+ "type": "string"
+ },
+ "links": {},
+ "markets": {
+ "type": "number"
+ },
+ "markets_data_fetched": {
+ "type": "boolean"
+ },
+ "message": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "type": "string"
+ },
+ "quotes": {
+ "additionalProperties": {
+ "additionalProperties": true,
+ "properties": {
+ "ath_date": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "ath_price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "market_cap": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "market_cap_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_12h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_15m": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_1h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_1y": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_30d": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_30m": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_6h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_change_7d": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "percent_from_price_ath": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "volume_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "volume_24h_change_24h": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "object"
+ },
+ "reported_rank": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "website_status": {
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "icos": {
+ "items": {},
+ "type": "array"
+ },
+ "people": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "description": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "id": {
+ "type": "string"
+ },
+ "links": {},
+ "name": {
+ "type": "string"
+ },
+ "positions": {
+ "items": {},
+ "type": "array"
+ },
+ "teams_count": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "tags": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "coin_counter": {
+ "type": "number"
+ },
+ "coins": {
+ "description": "Present when additionalFields=coins is requested.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "description": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "ico_counter": {
+ "type": "number"
+ },
+ "icos": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}status2 fields changedInput schema / properties / rationale / descriptionPrevious value: -"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets — use generic descriptions."New value: +"REQUIRED. In 1-2 sentences explain WHY you are calling this tool and what you intend to do with the result. Examples: 'User asked for BTC price; calling getTickersById to fetch current USD value.' 'Building a portfolio dashboard; need OHLCV for ETH last 7 days.' This is logged and reviewed to improve the MCP. Do not include user PII or secrets; use generic descriptions."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "api_base": {
+ "type": "string"
+ },
+ "mode": {
+ "type": "string"
+ },
+ "paid_features": {
+ "type": "string"
+ },
+ "status": {
+ "type": "string"
+ },
+ "tier": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+}submitFeedback1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "message": {
+ "type": "string"
+ },
+ "ok": {
+ "description": "True if the feedback row was persisted.",
+ "type": "boolean"
+ },
+ "severity": {
+ "enum": [
+ "blocker",
+ "major",
+ "minor",
+ "nit"
+ ],
+ "type": "string"
+ },
+ "tracking_id": {
+ "description": "Stable id agents can reference in follow-up submissions; null if persistence failed.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "ok",
+ "message"
+ ],
+ "type": "object"
+}getCapabilitiesgetChangelogIDsgetCoinByIdgetCoinEventsgetCoinExchangesgetCoinMarketsgetCoinOHLCVHistoricalgetCoinOHLCVLatestgetCoinOHLCVTodaygetCoinsgetContractsgetExchangeByIDgetExchangeMarketsgetExchangesgetGlobalgetHistoricalTickerByContractgetMappingsgetPeopleByIdgetPlatformsgetTagByIdgetTagsgetTickerByContractgetTickersgetTickersByIdgetTickersHistoricalByIdkeyInfopriceConverterresolveIdsearchstatussubmitFeedback
Add one secure layer between your agents and this server.