get_coverageThe blockchains and coins covered by this stablecoin blacklist and freeze record, the date of the most recent recorded event, and which lanes we cannot currently vouch for. Call this to find out whether a chain or coin is in scope before relying on an answer about it, and to check whether any part of the record is behind.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful behavioral context beyond that: it returns coverage metadata, recency information, and explicit gaps ('lanes we cannot currently vouch for', 'record is behind'). No contradiction with 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?
Two sentences with no filler. The first sentence enumerates what the tool returns, and the second states when to call it. Every clause earns its place and the key coverage scope 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 zero-parameter read-only coverage tool, the description covers what it returns, why an agent should call it, and its limitations (unverified lanes, staleness). No output schema exists, but the main return elements are named in prose, so 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?
There are zero parameters, so the schema is trivially complete and the baseline is 4. The description does not need to explain parameter meaning because there are none to explain.
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 the specific resource (the stablecoin blacklist and freeze record) and the exact questions it answers: which blockchains/coins are covered, the latest event date, and which lanes cannot be vouched for. This clearly differentiates it from siblings like get_address_status or list_freeze_events, which target individual addresses or events rather than overall coverage.
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 when to call it: before relying on an answer about a chain or coin, and to check whether the record is behind. It does not explicitly mention sibling alternatives or when not to use it, but for a zero-parameter coverage query the usage context is clear enough to guide an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a clearly distinct query type: per-address history, largest events, coverage metadata, per-coin policy, aggregate statistics, and the public event feed. Where list_freeze_events and get_address_status both return event rows, the descriptions explicitly point agents to the right tool for each use case.
The naming is mostly consistent with get_* snake_case verbs, and all names are readable and predictable. Minor deviations are list_freeze_events using 'list' instead of 'get' and get_biggest being more of a query label than a resource noun.
Six tools is well-scoped for a focused read-only tracker. Each tool earns its place and there is no redundancy or bloat.
The core domain is well covered: address lookups, token policies, aggregate statistics, coverage checks, ranked events, and a public event feed are all present. Minor gaps include no direct lookup by transaction/block/event ID and no way to page through the full historical event feed, but those limitations are clearly disclosed and do not break common workflows.