SiteCheck Crypto & Finance

Recent Subtensor chain events, optionally filtered

crypto_subtensor_events

Read-only

Recent Subtensor chain events, optionally filtered by pallet, event name, block range, or pagination. Requires TAOSTATS_API_KEY. Related tools on this server, for a different need: crypto_subtensor_block_events when you need events of a single Bittensor Subtensor block by block; crypto_subtensor_registrations when you need recent neuron registration events across all subnets. Price: $0.003 in USDC per successful call, paid with x402 (Base, Solana or Arc); failed calls are not charged.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "crypto_subtensor_events"
  }
}

Input Schema

Name	Required	Description
`name`	No	Event name (e.g. ExtrinsicSuccess, Transfer)
`page`	No	Page number
`limit`	No	Maximum events to return
`pallet`	No	Substrate pallet name (e.g. SubtensorModule, System, Balances)

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 2, 2026

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the readOnly/openWorld annotations by disclosing the TAOSTATS_API_KEY requirement and the paid-call model, including that failures are not charged and which rails settle payment (x402 on Base, Solana, Arc). That is exactly the operational context an agent needs before committing to a call. It stops short of anything on result shape or rate limits, but the output schema covers returns.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the resource and filters, then auth, then alternatives, then price — a sensible priority order. The pricing clause is long and the 'Related tools on this server, for a different need' construction is slightly awkward, but nothing is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With annotations, a full output schema, and zero required parameters, the definition covers auth, cost, and sibling routing — the main things an agent needs. The only real gap is the phantom 'block range' filter claim, which should either be removed or backed by actual schema properties.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with per-parameter examples (pallet and event-name samples), so the baseline is 3. The description adds little beyond restating the filter axes, and it advertises a 'block range' filter that does not exist among the four schema properties — a mismatch that could lead an agent to attempt a nonexistent argument.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (recent Subtensor chain events) plus its filter axes, which immediately distinguishes it from the block-scoped and registration-specific siblings. An agent can classify this as the general/broad events lister without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent: use crypto_subtensor_block_events for a single block's events and crypto_subtensor_registrations for neuron registrations across subnets. Both alternatives come with the condition that selects them, so selection is not left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All SiteCheck Crypto & Finance tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?