Skip to main content
Glama

Search transactions

search_transactions
Read-onlyIdempotent

Read-only chain-wide Explorer DB transaction search. Use for general transaction, native XGR value, from/to address, hash, input, session id, validity/execution, and block/time-range questions; do not sample XDaLa sessions for chain-wide transaction questions.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoRecipient address, contract address or upper bound used for the query.
fromNoSender address or lower bound used for the query.
pageNoOne-based page number for paginated explorer/API results.
limitNoMaximum number of records to return.
validNoValue for the valid parameter.
txHashNo0x-prefixed transaction hash to inspect or resolve.
toBlockNoValue for the to block parameter.
executedNoValue for the executed parameter.
hasInputNoValue for the has input parameter.
hasValueNoValue for the has value parameter.
fromBlockNoValue for the from block parameter.
sessionIdNoXDaLa session identifier used to query runtime or explorer data.
valueEqWeiNoValue for the value eq wei parameter.
valueGtWeiNoValue for the value gt wei parameter.
valueLtWeiNoValue for the value lt wei parameter.
windowHoursNoValue for the window hours parameter.
contractCreationNoValue for the contract creation parameter.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYesStructured result data returned by the XGR MCP gateway.

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds context about the data source ('Explorer DB') and the chain-wide scope, reinforcing the read-only nature and distinguishing from session-scoped queries. No contradictions 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.

Conciseness5/5

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

The description is two sentences, front-loaded with the core purpose ('Read-only chain-wide Explorer DB transaction search'), and every word adds value. No redundancy or filler.

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?

Given 17 parameters, no required parameters, and an output schema, the description provides a high-level overview and usage guideline. It covers the main use cases and excludes inappropriate usage. It does not detail combination logic or pagination, which is acceptable for a search tool with a rich schema.

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 detailed descriptions for all 17 parameters. The description adds meta-guidance by grouping parameters into categories (e.g., 'value, from/to address, hash'), but does not provide new information beyond what the schema already offers. Baseline 3 is appropriate.

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?

The description clearly states it is a 'Read-only chain-wide Explorer DB transaction search' and lists specific query types (transaction, native XGR value, from/to address, hash, input, session id, validity/execution, block/time-range). This distinguishes it from sibling tools like get_account_transactions (scoped to an account) or get_block_transactions (scoped to a block) by emphasizing chain-wide scope.

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

Usage Guidelines4/5

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

The description explicitly says 'Use for ... questions; do not sample XDaLa sessions for chain-wide transaction questions.' This provides clear when-to-use and when-not-to-use guidance. However, it does not name specific alternative sibling tools, which would elevate the score to 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.2/5.0
Disambiguation2/5

There are many overlapping session-listing tools (list_xdala_sessions, get_recent_xdala_sessions, find_latest_xdala_session, list_xdala_session_ids, get_latest_session_payload) and duplicate validation tools (validate_xdala_bundle is an alias for validate_xgr_multibundle). Descriptions help but boundaries are still unclear.

Naming Consistency4/5

The verb_noun snake_case pattern is consistent across nearly all tools (get_, list_, create_, cancel_, validate_). Minor inconsistencies include the alias validate_xdala_bundle and interchangeable verbs like get_ vs read_ vs resolve_ for similar read operations.

Tool Count1/5

With 95 tools, this is far beyond the 25+ threshold for 'too many'. While the domain is broad, the sheer number makes the tool surface unwieldy and difficult for an agent to navigate.

Completeness4/5

The tool set covers a wide range of operations: handoffs, session queries, transaction exploration, contract reads, validation, gas requests, and purchases. Minor gaps exist (e.g., no direct workflow editing tools), but overall the surface is remarkably complete.