Skip to main content
Glama
Sign In

Fivebar Trading

by io.github.fivebar-xyz
OverviewDiscussionsAdmin

Follow the money (a wallet's flows)

wallet_flows
Read-only

Where a wallet's money came from and where it went over the last days, on Robinhood Chain (default), HyperEVM, Elysium, Base, Ethereum or Arbitrum: every counterparty that sent it or received tokens from it, grouped and priced in USD (today's prices), with transfer counts, the tokens moved and first and last dates. Counterparties are marked wallet or contract, and labelled when they're registered ERC-8004 agents or well-known contracts (never people). Also the first money in within the window, often what funded it. Use to trace a deployer's sells, a seller's buyers, or where funds were sent. Premium: 2¢ a call from prepaid agent credits (3 free premium calls a day). Send your agent key as Authorization: Bearer .

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": {
      "address": "<address>"
    },
    "name": "wallet_flows"
  }
}

Input Schema

NameRequiredDescriptionDefault
daysNoHow far back, in days. Default 30, max 90
chainNoDefault robinhood
tokenNoOptional token contract to follow as well (e.g. the token a deployer launched), in case the wallet no longer holds it
addressYesWallet address (0x...)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / chain / enum
      Previous value: -[
-  "robinhood",
-  "hyperevm",
-  "base",
-  "ethereum",
-  "arbitrum"
-]New value: +[
+  "robinhood",
+  "hyperevm",
+  "elysium",
+  "base",
+  "ethereum",
+  "arbitrum"
+]
  2. Changed1 schema field changed
    • changedInput schema / properties / chain / enum
      Previous value: -[
-  "robinhood",
-  "base",
-  "ethereum",
-  "arbitrum"
-]New value: +[
+  "robinhood",
+  "hyperevm",
+  "base",
+  "ethereum",
+  "arbitrum"
+]
  3. Added

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only say readOnly/openWorld; the description adds what the annotations cannot cover — USD pricing is at today's prices, results are grouped with counts and date ranges, counterparties are typed and labelled (ERC-8004 agents, known contracts, never people), and the auth path plus a per-call cost with a free daily allowance are disclosed. An agent knows exactly what it is paying for and what it gets.

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 core resource and scope, then layers the return shape, use cases, and cost/auth. It is dense but each block earns its place; the single sprawling sentence and the parenthetical pricing/agent-key tail make it slightly harder to scan.

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, the description steps in and specifies the returned fields (grouped counterparties, USD value, transfer counts, tokens, first/last dates, labels) along with auth, cost, and default chain. Nothing needed to call it correctly or interpret the response is missing.

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%, including the days default/max and the chain default, so the schema already carries parameter meaning. The description reinforces the window ('over the last days') and the multi-chain scope but adds little syntax or format detail beyond the schema.

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: it returns where a wallet's money came from and went, grouped by counterparty, priced in USD, across a named set of chains. The inclusion of counterparty typing, labels, transfer counts and the 'first money in' makes it clearly distinct from siblings like wallet_events or wallet_holdings.

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?

Gives concrete use cases: tracing a deployer's sells, a seller's buyers, or where funds were sent. That is clear context for when to reach for it, but it does not name a competing sibling or state an exclusion (e.g. use wallet_events for raw transfers instead).

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

All Fivebar Trading 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