Verified token unlock calendar from the Tokenomics Audit Desk: upcoming unlocks, per-token history.
Scored across 4 tools
The three data tools split cleanly by filter dimension: single token, explicit date range, and a fixed 90-day forward window. `list_upcoming_unlocks` is largely a convenience preset over `get_unlock_calendar`, so an agent could reasonably reach for either for near-term queries, but the descriptions (verified-figures-only, soonest-first) make the intended roles clear enough.
Three of four tools follow a clean verb_noun pattern (get_token_unlocks, get_unlock_calendar, list_upcoming_unlocks) with the resource name in snake_case. `dataset_info` breaks the pattern as a bare noun phrase, a minor deviation in an otherwise predictable set.
Four tools is well-scoped for a read-only unlock calendar: metadata, per-token lookup, date-range query, and an upcoming view. Each tool has a distinct job and none feels like filler or is conspicuously absent.
The read surface covers provenance, token-scoped retrieval, arbitrary date ranges, and a rolling forward view, which is solid lifecycle coverage for a static dataset. Minor gaps remain: no way to enumerate which token symbols the desk tracks, no pagination or result-cap controls, and no filtering by unlock size or type.
Provenance and coverage of the unlock dataset behind this server: version, coverage window, entry count, sources, license (MIT) and attribution.
| 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 disclosure burden, and it does well by enumerating the exact fields returned (version, coverage window, entry count, sources, license MIT, attribution), signalling a static, read-only metadata lookup with no arguments and no side effects. It does not explicitly state that it performs no mutation, which is the only reason 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?
A single front-loaded sentence that fully identifies the resource and its contents with zero filler. Every listed item (version, coverage window, entry count, sources, license, attribution) earns its place as a preview of the returned fields.
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?
There is no output schema, so the description must characterize the return value, which it does by listing the metadata fields an agent will receive. Combined with the zero-parameter schema, this is nearly complete; only an explicit statement of read-only/no-side-effect behavior 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?
The tool takes zero parameters, so the baseline is 4. The description correctly implies no input is needed, and there is nothing further to document.
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 the specific resource (dataset provenance/coverage metadata for the unlock dataset) and enumerates what it contains (version, coverage window, entry count, sources, license, attribution). This clearly separates it from the data-returning siblings get_token_unlocks, get_unlock_calendar and list_upcoming_unlocks, though the verb is only implicit ('Provenance and coverage of...').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: by describing itself as dataset provenance/coverage metadata, an agent can infer this is the tool to call for context about the data rather than for the unlock records themselves. There is no explicit 'use this when...' statement and no named alternative or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return every unlock event in the calendar for one token, matched case-insensitively against the token symbol (e.g. ENA, ZRO) or the project name (e.g. Ethena, LayerZero).
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Token symbol or project name to look up. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose a meaningful behavioral trait — case-insensitive matching against either symbol or project name — but says nothing about read-only safety, ordering, empty/no-match results, or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the action and scope, and the matching rule plus examples are packed in without waste.
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?
Adequate for a one-parameter lookup, but with no output schema and no annotations, the description does not describe what an unlock event contains or what a no-match response looks like — details the agent would otherwise need.
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 baseline would be 3, but the description adds real semantics: the single parameter is matched case-insensitively and accepts either a symbol (ENA, ZRO) or a project name (Ethena, LayerZero), with concrete examples.
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 every unlock event in the calendar for one token. An agent can distinguish it from list_upcoming_unlocks and get_unlock_calendar by the single-token scope, though siblings are never 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?
Usage is implied by 'for one token' versus the calendar-wide siblings, but there is no explicit when-to-use/when-not guidance or pointer to an alternative tool for multi-token or date-window queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return all unlock events whose date falls inside an inclusive ISO date range (YYYY-MM-DD). Omit a bound to leave that side open.
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | No | Last date to include, YYYY-MM-DD. | |
| start_date | No | First date to include, YYYY-MM-DD. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does disclose that the range is inclusive and that omitted bounds are open-ended. However, it does not cover return format, ordering, pagination, or what happens when both bounds are omitted, leaving meaningful behavioral gaps for a query 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?
The description is two tight sentences with the core operation front-loaded and no wasted text. The range semantics are stated efficiently in the second sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The definition is adequate for a simple two-parameter read query, but with no output schema and no annotations, it leaves return shape and key behavioral details implicit. It also does not relate the tool to its siblings, which matters given list_upcoming_unlocks and get_token_unlocks overlap in domain.
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 already 100%, so the baseline is 3, but the description adds useful semantics: the range is inclusive, both dates are ISO YYYY-MM-DD, and omitting a bound leaves that side open. This meaningfully clarifies the optional start_date and end_date parameters beyond the schema descriptions.
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: "Return all unlock events" filtered by a date range. It is clear what the tool does, though it does not explicitly differentiate itself from siblings like list_upcoming_unlocks or get_token_unlocks.
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-like guidance is "Omit a bound to leave that side open," which explains parameter behavior rather than when to choose this tool over alternatives. No sibling tools are referenced and no when/when-not conditions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List dated token unlock events from the Tokenomics Audit Desk 90-day unlock calendar, starting today (UTC), soonest first. Only events the desk holds verified figures for are included.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of events to return. | |
| days_ahead | No | How many days ahead of today to look (1-90). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the full burden; it does disclose three behavioral traits: the 90-day source calendar, UTC-based start-of-window semantics, and a coverage caveat that only desk-verified figures are included. It says nothing about return shape per event, pagination beyond 'limit', or freshness/caching, which are real gaps for a feed tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste, with the core action and window front-loaded and the data-quality caveat placed second. 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?
There is no output schema and the description never indicates what an unlock event contains (token, date, amount, supply percentage), so an agent cannot reason about downstream use. For a data-retrieval tool whose return contents are entirely unspecified, the definition under-delivers despite the decent scoping information.
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 both parameters carry bounds, defaults and descriptions, so the baseline is 3. The description only weakly reinforces days_ahead via '90-day unlock calendar' and adds no meaning for limit beyond what the schema states.
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 dated token unlock events') plus the data source and ordering ('soonest first'), which is enough detail to picture the output. It does not explicitly contrast itself with the overlapping siblings get_token_unlocks and get_unlock_calendar, so sibling differentiation is left to the reader.
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?
'Starting today (UTC)' implies a forward-looking window and that past events are excluded, which is useful implied guidance. However, nothing says when to choose this over get_unlock_calendar or get_token_unlocks, and the 1-90 day horizon is only inferable from the schema.
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.
dataset_infoget_token_unlocksget_unlock_calendarlist_upcoming_unlocksToken unlock calendar for the next 60 days, rated by size vs circulating supply. Free, no key.
Free token data: revenue, net flow after emissions, supply/unlock history, catalysts, errors marked
Crypto events calendar: dated, sourced and impact-scored events for 14,000+ coins.
Pre-trade crypto intelligence: survival rating, order-book depth, unlocks and contract flags.
Add one secure layer between your agents and this server.