Bitquery: Crypto & Blockchain Data

Base Tx Events

base_tx_events

Read-only

ALL EVENT LOGS in one or more Base (base, L2, Coinbase L2) transactions, including decoded arguments plus raw topics and data. Use after base_find_events identifies a transaction, or whenever a tx receipt's complete event payload is needed. Accepts up to 50 transaction hashes separated by "|". Parsed=0 means no ABI matched: Event, Signature and Arguments can then be empty, but Topic0, Topics and Data remain usable. NOT the value moved in a transaction → use base_tx_transfers. Arguments are named objects with Name, Type, string Value and Indexed; integer values are decimal strings to avoid JSON-number precision loss; use raw Topics/Data for values wider than the decoded numeric fields. Argument names come from one known ABI for the Signature and can be another contract's wording - Topics and Data are the log's own. By default, reverted call-frame logs, removed logs and failed transactions are excluded; set only_successful=0 to inspect them with the returned status fields.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "tx_hash": "<tx_hash>"
    },
    "name": "base_tx_events"
  }
}

Input Schema

Name	Required	Description	Default
`event`	No	Event name or full signature, case-insensitive. Empty = every event in the requested transactions.
`limit`	No	Max event rows across all requested transactions (default 200, capped at 1000).
`format`	No	Shape of the returned data. "rows" (the default) returns one item per row. "columnar" returns a single item, {"columns":[...],"rows":[[value,...],...]}, naming the columns once and listing each row's values in that order; it is more compact for large results and carries the same values.	rows
`topic0`	No	Raw 32-byte event signature hash (topic0), hex with or without 0x. Empty = any topic0.
`tx_hash`	Yes	One Base transaction hash, or up to 50 hashes separated by "\|"; exactly 64 hex characters with optional 0x, case-insensitive. A malformed entry is refused before the query runs.
`only_successful`	No	1 (default) = confirmed logs only; 0 = also include failed transactions, reverted call frames and removed logs.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 28, 2026

addedInput schema / properties / format

Added value: +{
+  "default": "rows",
+  "description": "Shape of the returned data. \"rows\" (the default) returns one item per row. \"columnar\" returns a single item, {\"columns\":[...],\"rows\":[[value,...],...]}, naming the columns once and listing each row's values in that order; it is more compact for large results and carries the same values.",
+  "type": "string"
+}

First observedOct 7, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only say readOnly/destructive=false; the description adds substantive behavior: default exclusion of reverted call-frame logs, removed logs and failed transactions, and that only_successful=0 exposes them via status fields. It also warns that Parsed=0 means no ABI matched and decoded fields may be empty while raw fields remain usable, plus the ABI-vs-log naming caveat and decimal-string encoding for integers.

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-loaded with the resource and scope, then alternatives, then output semantics and default exclusions — each sentence carries information. It is dense and runs long across several clauses (the argument-naming caveat is especially wordy), so it is efficient but not maximally tight.

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

Completeness5/5

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

No output schema exists, yet the description names the returned fields (Event, Signature, Arguments, Topic0, Topics, Data), explains their structure (named objects with Name/Type/Value/Indexed) and their failure modes (Parsed=0, empty decoded fields). Combined with the exclusion defaults, an agent has everything needed to call and interpret this tool correctly.

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

Parameters4/5

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

Schema coverage is 100%, so parameters are already documented; the description still adds cross-cutting meaning the schema cannot, such as the 50-hash '|' batching limit, the only_successful=0 escape hatch, and how argument Values are encoded (decimal strings, raw Topics/Data for wider values). It does not add anything about limit/format beyond the schema, so it stops short of a 5.

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+resource ('ALL EVENT LOGS in one or more Base transactions') and immediately scopes what is returned ('decoded arguments plus raw topics and data'). It also names what it is not ('NOT the value moved in a transaction → use base_tx_transfers'), so an agent can separate it from base_find_events and base_tx_transfers without opening a 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?

Gives an explicit entry point ('Use after base_find_events identifies a transaction'), a general condition ('whenever a tx receipt's complete event payload is needed'), and an explicit exclusion routed to a sibling ('NOT the value moved ... use base_tx_transfers'). The only gap is that no other event-querying sibling is contrasted, but the primary routing decision is fully covered.

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

All Bitquery: Crypto & Blockchain Data 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.