Crypto events calendar: dated, sourced and impact-scored events for 14,000+ coins.
Scored across 7 tools
Each tool targets a clearly distinct resource (individual coin vs. coin list, individual event vs. event list, cancellations, categories, usage). The singular get_* vs. plural list_* split makes boundaries obvious, and get_usage and list_event_cancellations occupy unique niches that no other tool overlaps. An agent can select correctly without hesitation.
All seven tools follow a strict snake_case verb_noun pattern, alternating only between get_ (single resource) and list_ (collections). No camelCase or style mixing. The naming is fully predictable and self-documenting.
Seven tools is well-scoped for a read-only calendar/coin API wrapper. Each tool maps to a natural API endpoint and earns its place—no redundancy, no filler.
The read surface covers coins, events, categories, cancellations, and usage—the core lifecycle for this domain. Minor gaps exist: no dedicated keyword/search or lookup-by-name tool, and no write operations, though the latter fits a read-only API. Agents can work around gaps via list_events filters.
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. It lists conferences, which have no score, last. | |
| 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. Excludes conferences, which have no score. | |
| 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?
No annotations are provided, so the description carries the full disclosure burden. It usefully states pagination, plan-dependent date windows, default sorting, and AND composition of filters, but it omits the 403/tier constraints for impactMin, categories, and impact_desc sorting, and does not describe authentication or 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?
Three sentences, front-loaded with purpose and scope, then default sort and filter composition. Every sentence adds useful information with no visible padding.
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 listing tool with no annotations and no output schema, the description covers purpose, pagination, plan-dependent date scope, default sort, and filter composition. It leaves tier/403 details and return-shape specifics to the schema or inference, which are minor gaps given the rich input 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%, so the baseline is 3. The description adds non-obvious meaning by stating that coins, categories, and date filters compose with AND, and it reinforces the default date_asc sort, which supplements the schema’s parameter-level 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?
States a specific verb and resource: returns a paginated list of upcoming and historical events, scoped by the caller's plan date window. It is clear what the tool does, but it does not explicitly differentiate itself from siblings such as get_event or list_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?
The description supplies useful context about plan-based date windows, default sort, and AND-composed filters, implying this is the listing/search tool. However, it does not explicitly say when to use this instead of get_event or list_event_cancellations, nor does it state any when-not conditions.
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.
list_events2 fields changedInput schema / properties / impactMin / descriptionPrevious value: -"Lower bound on the precise impact score (0.0–10.0). Elite+ only; lower tiers receive 403."New value: +"Lower bound on the precise impact score (0.0–10.0). Elite+ only; lower tiers receive 403. Excludes conferences, which have no score."Input schema / properties / sortBy / descriptionPrevious value: -"Sort order. Default `date_asc` (soonest first). `impact_desc` is Elite+ only; lower tiers receive 403."New value: +"Sort order. Default `date_asc` (soonest first). `impact_desc` is Elite+ only; lower tiers receive 403. It lists conferences, which have no score, last."get_coinget_eventget_usagelist_categorieslist_coinslist_event_cancellationslist_eventsHourly crypto news sentiment and typed market events, with sources on every signal.
Token unlock calendar for the next 60 days, rated by size vs circulating supply. Free, no key.
Verified biotech catalyst calendar (PDUFA/AdComm/trial readouts) anchored to official sources.
Live crypto funding rates on 5 exchanges: events, pair search, briefings, calendar, spreads, alerts.
Add one secure layer between your agents and this server.
