Skip to main content
Glama
Sign In

Roundhouse

by io.roundhouseai
OverviewDiscussionsAdmin

Settlements for one wallet

list_entity_settlements
Read-only

Settlements where this wallet is either the payer or the payee, newest first. Walkable deeply in time order: (payer, block_time desc) and (payee, block_time desc) cover it, so page N costs what page 1 does and a wallet's whole history can be paged for velocity or trend.

Wraps GET /v0/entities/{wallet}/settlements. Access: requires an API key (Authorization: Bearer rh_live_… or x-api-key).

Returns:

  • wallet: The wallet queried, lowercased.

  • settlements: Settlement rows, newest first, decorated with resolved display names. Each row also carries is_self_payment (payer = payee, annotated rather than only excluded — a third of the feed can be self-payment) and evidence: { verified, method, probability, tier }. verified is THREE-VALUED — true a named facilitator relayed it, false examined with no EIP-3009 marker, and null gasless and authorized but NOT ESTABLISHED as x402, which is not the same as disproven. tier is proven | probable | unproven | not_x402 | ungraded.

  • next_before: Cursor for the next page, or null.

  • meta: The chain served and as_of. On a non-empty page meta also carries page_self_payments, page_self_payment_usd, page_gross_usd and page_organic_usd. All four are THIS PAGE only, as the names say: they are not site-wide figures and summing them across pages is not a total.

Input Schema

NameRequiredDescriptionDefault
limitNoRows to return. Clamped to 100; values outside the range are clamped, not rejected.
beforeNoOpaque cursor from a previous response's `next_before`. It encodes the whole sort key, tiebreaker included, so a page boundary inside a group of rows sharing a timestamp does not skip the rest. Do not parse it or build one by hand.
walletYesAn EVM address (`0x` + 40 hex digits; case-insensitive, lowercased before lookup) or a Solana address (base58; case-sensitive, used exactly as given). An address the index has not observed answers `coverage.known: false`, not zeros.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the annotations (readOnly/openWorld), it discloses the auth requirement (Bearer API key), pagination cost, the three-valued `verified` semantics, the `tier` enum, and the critical caveat that `page_*` meta fields are per-page and not summable across pages. This is exactly the kind of behavioral context an agent can't infer from structured fields.

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?

It's front-loaded with the purpose and organized into a Returns section, and every claim is substantive. The 'Walkable deeply in time order' sentence is a bit dense and slightly overwrought, keeping it just under top marks.

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?

With no output schema and read-only annotations covered, the description fully carries the burden: it documents the return fields, the ambiguous three-valued `verified`, and the per-page aggregation trap. An agent has everything needed to call and interpret it correctly.

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%, so all three parameters are already documented, including clamping behavior and the opaque cursor. The description's paging-cost remark adds marginal context but doesn't elaborate parameter syntax beyond the schema, so the baseline 3 applies.

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 opening sentence states a specific resource and disambiguates scope: settlements where the wallet is payer OR payee, ordered newest first. This clearly separates it from sibling tools like list_transactions and list_flows.

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?

It explains that the underlying indexes enable deep sequential paging, so an agent knows it can walk a wallet's whole history for velocity or trend analysis, and it implies this is the right tool for per-wallet settlement history. It doesn't explicitly name an alternative (e.g. list_transactions) or state when not to use it.

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

All Roundhouse toolsInspect
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