Crypto events calendar: dated, sourced and impact-scored events for 14,000+ coins.
Scored across 7 tools
Each tool targets a distinct resource and action: get_coin vs list_coins, get_event vs list_events, plus list_categories, list_event_cancellations, and get_usage. There is no meaningful overlap—singular getters versus paginated listers versus meta-operations are clearly separable.
Every tool follows a strict verb_noun snake_case pattern: get_coin, get_event, get_usage, list_categories, list_coins, list_event_cancellations, list_events. The get/list distinction is applied consistently and predictably.
Seven tools is a well-scoped, focused surface for a read-oriented data API, with each tool earning its place. It sits comfortably in the ideal range, though the set is slightly lean and could arguably support a search tool.
The surface covers the core domain well: coins, events, categories, cancellations, and usage across both get and list operations. Minor gaps exist—no search endpoint and no tool for managing the webhooks that the descriptions repeatedly reference.
Returns the full coin payload by slug. 404 when the slug doesn't match any coin (tracked or otherwise).
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Coin slug (e.g. `bitcoin`). Lowercase, URL-safe. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the 404 failure mode when a slug does not match, but says nothing about auth requirements, rate limits, or whether the payload is cached/fresh.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the return behavior and followed by the error case. No filler or 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?
For a single-parameter lookup with no output schema, the description covers the essential behavior: what it returns and how it fails. It leaves the composition of the 'full coin payload' undefined, but that is discoverable and not needed to invoke the 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 coverage is 100% and the single 'slug' parameter is documented in the schema with format hints ('lowercase, URL-safe'). The description adds no meaning beyond that, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Returns the full coin payload') plus the lookup key ('by slug'), which clearly separates it from the list_coins sibling. It does not name the alternative explicitly, so it falls short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no mention of when to prefer list_coins, and no stated prerequisites. The reader must infer that this is the tool for retrieving one known coin versus enumerating many.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the full event payload by id. Tier-gated fields follow the caller's plan. A recently removed event returns 410 Gone with its id and cancelledAt. An unknown, temporarily unpublished, or out-of-window event returns 404.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The event id, as returned by `GET /v2/events`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it discloses tier/plan-dependent field gating and detailed error semantics (410 Gone with id and cancelledAt for removed events; 404 for unknown, unpublished, or out-of-window ids). It stops short of explicitly stating the read-only/side-effect-free nature or any auth/rate-limit 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?
Three sentences, each earning its place: purpose first, then plan-dependent behavior, then the two distinct error contracts. No filler, and the core action 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 single-parameter read tool with no annotations and no output schema, the description covers purpose, access gating, and the notable failure modes an agent must handle. It does not sketch the returned payload shape, though 'full event payload' plus the 410 variant give enough of a contract for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter and schema description coverage is 100%, so the schema already explains the id fully, including its source endpoint. The description's 'by id' adds no format, syntax, or constraint beyond what the schema provides, making the baseline 3 correct.
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 ('Returns the full event payload by id'), which cleanly separates it from the sibling list tools (list_events, list_event_cancellations) that return collections. An agent can tell instantly that this fetches exactly one record keyed by id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: fetch a known event by id. The description never says when to prefer this over list_events or how to obtain a valid id (that hint lives only in the schema's 'as returned by GET /v2/events'). No alternatives or exclusions are named, so this is minimum-viable routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the authenticated key's monthly usage counters. Does not consume quota beyond the cost of the HTTP call itself. Use this to backoff before hitting 429s or to drive alerts in your integration.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It usefully adds that the call 'does not consume quota beyond the cost of the HTTP call itself' and its relation to 429 rate limiting, which is real behavioral context. However, it omits auth/permission requirements beyond 'authenticated key', caching/freshness of the counters, and what is actually returned, so the coverage is partial.
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 short sentences, zero waste, and the core purpose is front-loaded before the quota-cost caveat and the use-case guidance. Each sentence adds distinct value.
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-param tool with no output schema, the description covers purpose, cost behavior, and intended use adequately. It is thin on what the 'usage counters' actually contain, which the absence of an output schema leaves entirely unexplained, so an agent cannot anticipate the return shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to clarify; the baseline for a no-param tool is 4. No misdirection about inputs is present.
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: 'Returns the authenticated key's monthly usage counters.' An agent can tell this is a usage/telemetry endpoint rather than a data endpoint, clearly distinct from siblings like get_coin or list_events. It stops short of explicitly naming a sibling to disambiguate against, so a 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete usage contexts: 'to backoff before hitting 429s or to drive alerts in your integration.' That tells the agent when this tool is worth calling. No explicit when-not condition or named alternative is offered, which keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns every category in the editorial taxonomy with the count of upcoming events per category (tier-windowed). Standard+ only. Query parameters are ignored; the list is not paginated.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does substantial work: it discloses a tier gating requirement (Standard+), that counts are tier-windowed, that input query parameters are silently ignored, and that results are unpaginated. That is meaningful behavioral context beyond a bare read operation, though it says nothing about rate limits or auth mechanics.
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, front-loaded with what is returned, then the tier constraint, then the no-params/no-pagination caveat. Every clause earns its place 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-parameter tool with no output schema, the description covers the essential contract: what comes back (all categories plus upcoming-event counts), who can call it, and that neither parameters nor pagination apply. Only minor gaps remain (exact count semantics or ordering), so it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, which sets a baseline of 4. The description reinforces this by explicitly stating query parameters are ignored, so the agent is not misled into trying to pass filters or pagination arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb (Returns) plus resource (every category in the editorial taxonomy) and even states the returned payload shape (event counts per category, tier-windowed). It is clearly distinct from siblings like list_coins or list_events, though it never explicitly names or contrasts an alternative.
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 a real precondition ('Standard+ only') and a usage caveat ('Query parameters are ignored'), which help an agent decide whether to call it. However, there is no explicit when-to-use vs. when-not guidance or routing to a sibling tool, so usage remains implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a paginated list of coins ordered by rank ascending (top-ranked first). Pass the tracked filter only when you need to limit results by editorial coverage.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Free-text search across name + symbol. Case-insensitive substring match. | |
| limit | No | Page size (1–200). | |
| cursor | No | Opaque pagination cursor. | |
| tracked | No | Filter by editorial coverage. Omit to return both tracked and untracked coins; set `true` for actively monitored coins only; set `false` for coins outside active coverage only. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses pagination and result ordering (rank ascending) that the schema does not state, but omits default page size, what the cursor represents, and any auth or rate-limit context for a read endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with zero filler; the pagination/ordering fact is front-loaded and the filter caveat follows. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-required-parameter read tool with no annotations or output schema, the description covers pagination, ordering, and filter intent adequately. A note on default page size or the shape of returned items would close the remaining gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters (q, limit, cursor, tracked) are already documented in the schema, setting the baseline at 3. The description adds the result-ordering guarantee but otherwise repeats the tracked-filter semantics rather than extending them.
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 ('Returns a paginated list of coins') plus the ordering guarantee (rank ascending), which lets an agent distinguish it from the singular get_coin sibling. It stops short of naming any sibling explicitly, so it is clear but not fully differentiated.
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 only usage guidance is for the `tracked` filter ('Pass the `tracked` filter only when you need to limit results by editorial coverage'), which largely restates the schema's own description. There is no guidance on when to prefer this over get_coin or list_categories, and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns removal records ordered by cancelledAt, then id. Available to every API V2 tier. Poll regularly and never leave more than 90 days between successful requests, even when webhooks are enabled.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size (1–100). | |
| since | No | Inclusive cancellation-time lower bound. Accepts RFC3339 or `YYYY-MM-DD`; defaults to 90 days ago. | |
| cursor | No | Opaque pagination cursor returned in the previous response's `meta.cursor`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden and does add real operational context: tier availability ('every API V2 tier') and a hard 90-day polling window implying records fall out of reach beyond that gap (consistent with `since` defaulting to 90 days ago). It still omits whether records are ever purged, how to iterate the cursor, and what failure/non-success looks like.
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 short sentences, front-loaded with what is returned, followed by access scope and the critical polling rule. No redundancy and no filler; the ordering and cadence details both earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple paginated list tool with full schema coverage, the description supplies the essentials an agent needs: resource, sort order, tier access, and the polling window that governs correct usage. With no output schema, it could say a bit more about what a removal record contains, but nothing critical 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 `limit`, `since`, and `cursor` are already fully documented in the schema. The description only adds the sort order, which indirectly justifies cursor pagination but adds no parameter syntax or format detail beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it returns removal (cancellation) records and notes their ordering by `cancelledAt` then `id`. That is clear enough to identify the resource, but it never differentiates from siblings like `list_events` or `get_event`, and 'removal records' is slightly vaguer than the tool name's 'event cancellations'.
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 a concrete polling directive — poll regularly, never leave more than 90 days between successful requests, and do so 'even when webhooks are enabled' — which tells the agent this is a reconciliation feed rather than an on-demand lookup. It stops short of explicitly naming an alternative tool or stating when this should be skipped.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a paginated list of upcoming and historical events within the date window available to the caller's plan. Default sort is date asc (soonest first). The coins, categories, and date filters compose with AND.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Inclusive upper bound on `date`. Default = today + tier upcoming window (e.g. 7 days on Free, 90 days on Standard, full on Pro+). | |
| from | No | Inclusive lower bound on `date`. Default = today. Free and Standard clamp past values to today; Pro clamps them to the previous 30 days; Elite and Enterprise can query the complete public catalog history since 2017. | |
| coins | No | Comma-separated coin **slugs** (e.g. `bitcoin,ethereum`). Tickers are accepted but **strongly discouraged**; symbols collide across coins (e.g. `UNI` resolves to several different projects). Use `GET /v2/coins` to look up canonical slugs. | |
| limit | No | Page size (1–100). | |
| cursor | No | Opaque pagination cursor returned in the previous response's `meta.cursor`. | |
| sortBy | No | Sort order. Default `date_asc` (soonest first). `impact_desc` is Elite+ only; lower tiers receive 403. | |
| keyword | No | Free-text search across event title and description. Case-insensitive substring match. | |
| impactMin | No | Lower bound on the precise impact score (0.0–10.0). Elite+ only; lower tiers receive 403. | |
| categories | No | Comma-separated category ids. Case-insensitive. Standard+ only; Free requests using this filter return 403. Use `GET /v2/categories` to look up the canonical id list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden: it does disclose pagination, the plan-gated date window, and that coins/categories/date filters compose with AND, which is genuine behavioral context. It stops short of any auth/permission model beyond 'caller's plan', rate limits, or error behavior (the 403s are only in the schema).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the operation and scope. Slight redundancy: 'Default sort is date asc (soonest first)' duplicates what the sortBy schema entry already says.
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 9-parameter, read-only listing tool with no output schema and no annotations, the description plus a very rich schema covers what an agent needs to call it. The absence of return-shape or pagination-cursor explanation is acceptable given the schema is exhaustive, though some error-condition context is left entirely to 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 description coverage is 100%, and the schema already documents defaults, tier clamps, the impactMin/categories 403 gating, and sort behavior, so the baseline is 3. The description only adds the cross-parameter AND composition rule and restates the default sort, adding modest value beyond the per-parameter docs.
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 ('Returns a paginated list of upcoming and historical events') with the scope qualified by plan tier. However, it never distinguishes this tool from sibling listing/read tools such as get_event or list_event_cancellations, so sibling differentiation is missing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent can infer this is the bulk-listing tool and that filters compose with AND, but there is no explicit when-to-use versus get_event or list_event_cancellations, nor when-not-to-use guidance. No alternatives are named.
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.
get_coinget_eventget_usagelist_categorieslist_coinslist_event_cancellationslist_eventsHourly crypto news sentiment and typed market events, with sources on every signal.
Verified biotech catalyst calendar (PDUFA/AdComm/trial readouts) anchored to official sources.
Live crypto funding-rate radar across 5 exchanges: events, pair briefings, calendar, spreads.
Gate news MCP for crypto news, structured events, announcements, and social sentiment.
Add one secure layer between your agents and this server.
