Skip to main content
Glama

A person's whole money picture, in one read

my_money
Read-onlyIdempotent

Everything one wallet was paid, is owed as a receipt, is only offered, and can do next, in a single free keyless read: dollars that settled, every OTHER token that settled and in what amount, open work receipts, token offers still standing on packets they took (each with the token's own risk label), their hours, what the Regen #77 payout ledger recorded for them, and exactly three doors. IT IS A BOARD-SIDE RECORD, NOT A CHAIN BALANCE: every figure is what this board itself recorded, no chain is read here, and a wallet's real holdings are whatever the chain says. A CREDIT IS NEVER MONEY: it is a receipt for work, not a token, not spendable, and nothing can be bought with it. The board prices no token, so a token amount carries no dollar value. There is no cash-out: what was paid sits in the person's own wallet, and turning it into money they can spend where they live happens on a rail they choose, which this board never names. Use this whenever the person asks what they have, what they are owed, or what to do next with it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
langNoThe language of the FRAME: the block labels, the door sentences and the honesty lines. Numbers, wallets, token symbols and packet ids never change. 'sw' is authored Kiswahili. Default 'en'.
workerWalletYesThe 0x… address to read. Address only, never a private key.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okNo
toolNo
fundedNo
payUsdNo
workIdNo
claimIdNo
claimableNo
next_callNo
proofRuleNo
fulfillableByNo
definitionOfDoneNo
needs_from_callerNo
notClaimableReasonNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already assure read-only/idempotent behavior; the description goes further by stating it is a free keyless read, that no chain is read, that credits are not money, that the board prices no token, and that there is no cash-out. This prevents an agent from presenting board figures as spendable balance or chain truth.

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 overview list is front-loaded and the usage rule appears last, so an agent can quickly get the gist. It is wordy with repeated warnings ('never money', 'not spendable', 'nothing can be bought', 'no cash-out') that overlap, but for a financial overview these cautions are defensible.

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?

Combined with the output schema and annotations, the description is complete: it says what data is included, what it is not, what will never be returned (cash-out rails, chain truth, dollar values), and when to call it. Nothing important for correct selection or expectation-setting 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?

The schema already documents both parameters completely (100% coverage), so the baseline is 3. The description adds no operation-level meaning for `lang` or `workerWallet` beyond the generic 'one wallet' phrasing; it neither clarifies nor obstructs 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?

The description names the concrete resource ('a person's whole money picture' / 'everything one wallet...') and a specific verb ('read'), then enumerates the exact data groups it returns. The 'BOARD-SIDE RECORD, NOT A CHAIN BALANCE' clause distinguishes it from chain-looking tools even though no sibling tool name is cited.

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 gives an explicit trigger: 'Use this whenever the person asks what they have, what they are owed, or what to do next with it.' It also sets a negative boundary by saying it is not a chain balance and that cash-out rails are never named. It does not name alternative sibling tools for those non-chain cases, so it falls just short of full routing guidance.

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.

Resources