Fetch recent Bitcoin Rune activity, including mints, transfers, and burns, with operation type, addresses, amounts, and timestamps for tracking on-chain movements.
Get recent activity (mints, transfers, burns) for a Bitcoin Rune. Returns operation type, addresses, amounts, and timestamps.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Rune name (e.g., UNCOMMON•GOODS or UNCOMMONGOODS) | |
| limit | No | Results per page | |
| offset | No | Pagination offset |
Changes observed during successful MCP inspections.
v0.2.0Does 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 discloses that this is a read-style operation and lists the activity types and returned fields, but it omits pagination behavior, ordering, the meaning of 'recent', and any auth or rate-limit context.
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 wasted words. The purpose is front-loaded, and the return-value summary follows immediately without 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?
With no output schema and no annotations, the description does useful work by listing returned fields and operation types. It is nearly complete for a simple paginated read tool, though it could better define the 'recent' time window and pagination ordering.
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 three parameters are already fully documented in the schema, including name format, limit bounds, and offset semantics. The description adds no parameter-level meaning beyond that 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?
The description uses a specific verb ('Get') and a clearly scoped resource ('recent activity ... for a Bitcoin Rune'), and it enumerates the activity categories (mints, transfers, burns). This distinguishes it from siblings such as get_rune_info, get_rune_holders, and get_brc20_activity without needing to name alternatives.
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 states what the tool returns but gives no guidance on when to choose it over related tools like get_rune_info, get_rune_market_info, or get_rune_holders. Usage is only weakly implied by the phrase 'Get recent activity'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.