Skip to main content
Glama

GetTransfers

Read-onlyIdempotent

Get transfers

Retrieves a list of transfers based on various query filters.

Transfer access: Requires transfers.read. Without transfers.filter, the default feed is descending by time, with no filters except chains and an optional usdGte=1. transfers.explorer additionally permits one address or entity as base, or base=all with one token. Combining a specific base and token, or changing other filters or sorting, requires transfers.filter. Full filtering includes explorer queries. Separately, offset + limit may not exceed the caller's transfers.max_results, counting an omitted limit as its default of 20. Logged-out access comes from the anonymous plan over the default plan; its initial grants permit only the default feed's first 50 results. A missing capability or a request past transfers.max_results returns 401 for logged-out callers or 403 for authenticated callers.

Rate Limit: This endpoint has a stricter rate limit of 1 request per second.

Sequence ranges: Every chain numbers its transfers as they are indexed, and includeCursors=true reports each chain's latest number. Pass seqGte and seqLte to fetch one chain's transfers between two of those numbers — for example, to poll incrementally without missing or repeating a transfer by walking from the last sequence you saw to the latest one reported. A sequence range needs exactly one chain, one whose transfers carry sequences, and may span at most 10,000,000 sequences; a range spanning more is walked in segments, the last of them ending at the chain's reported number. A range must end at or below that number — a seqLte beyond it is rejected, because the transfers up to it are not all searchable yet, and a chain reporting no number yet accepts no range at all. Sequences begin when a chain's numbering was introduced, so older transfers carry no seq and ranges below the earliest sequenced transfer return nothing. It cannot be combined with timeLast, which moves with the clock — use timeGte and timeLte. A sequence range comes back in ascending sequence order and so cannot be combined with sortKey or sortDir, and every transfer in it carries its own seq. That is how you page a range: a response with fewer than limit transfers has completed it, and a full one is continued by repeating the request with seqGte set to the last transfer's seq plus one. count is capped and does not report whether any of the range remains.

Real-time streaming: For live transfer notifications instead of polling, use the WebSocket API. See GET /ws/transfers for real-time streaming with transfer filtering. Service-wallet selectors are supported on the HTTP transfer endpoints only.

Filter forms: For the filter forms these parameters accept, see the Param Filters guide.

Costs 2 API credits per row.

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": "GetTransfers"
  }
}

Input Schema

NameRequiredDescriptionDefault
queryNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the annotations, it discloses authentication requirements, capability gating, 401/403 behavior, a stricter 1 request/second rate limit, credit cost, and max_results pagination constraints. This is unusually rich behavioral context and does not contradict the read-only, idempotent annotations.

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?

The description is long but well-structured into access, rate-limit, sequence-range, streaming, and filter sections. Some detail is verbose and partially duplicates the schema, but most sentences carry useful constraints for this complex endpoint.

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?

Given the complex query surface, annotations, and lack of an output schema, the description is complete enough to call the tool correctly. It covers access, costs, rate limits, pagination, sequence paging, and streaming alternatives; return-object field details are the only notable omission.

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?

The description adds important interaction semantics beyond the schema, especially for sequence ranges, timeLast incompatibility, sorting constraints, includeCursors, and offset+limit limits. It does not explain every filter form in detail, but it compensates substantially for the top-level schema coverage gap.

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

Purpose4/5

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

The description states a clear verb and resource: retrieving a list of transfers based on query filters. It is easy to distinguish from live streaming via its explicit WebSocket alternative, but it does not differentiate from sibling transfer tools such as GetUnenrichedTransfers or GetTransfersForTransaction.

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?

It gives explicit usage conditions: default feed behavior, when transfers.filter is required, sequence-range polling mechanics, and when to use the WebSocket API instead. These are concrete when-to-use and when-not-to-use guidelines rather than implied usage.

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.