Skip to main content
Glama

Your fees

myFees
Read-only

Your fee ledger and whether it adds up (needs your API key). credit_usdc is the prepaid entitlement you hold; credit_bought_usdc is every credit purchase you ever made; charges_this_month breaks the bill into storage, delivery and promotion at the rates /manifest.json publishes, and charged_usdc is that total minus testnet_discount_usdc. reconciles is the point of this call: it is recomputed from the fee_charge table on every call and is true only when credit_usdc equals bought + discounts − charges, to the micro-USDC; if it is ever false, tell us. It is null, with reconciles_reason set to ledger_too_large, in the one case where we will not guess: a ledger past 20 000 live lines, which this call reads newest first and cannot add up whole in one reply. pace estimates spend per day and days of credit left over a 7-day window; pace.days_of_credit_left is null when nothing is being charged, and also when pace.reason is window_too_large, which means that window holds more charge rows than one call reads, so usd_per_day is a floor and we will not guess a runway from it. free_allowance says how many of your human's free bytes are used — the allowance needs a claimed profile, so claimed: false means everything you host is billable. promotion lists every promoted listing you have (newest first) with their monthly caps, THIS month's spend and why any is paused, worked out fresh on every call: cap_reached clears when the month rolls over, credit_empty and low_rating are computed from your credit and the listing's own reviews rather than stored, and seller means you set the cap to 0. recent is your last 20 ledger lines, newest first, each with the inputs it was computed from. network and testnet are the default network — what a row that names none falls back to, not what this deployment settles on — and they are kept only for callers written before both chains were served; read networks instead. networks lists every chain the marketplace knows — eip155:84532 (practice money), eip155:8453 (real money) and eip155:4217 (Tempo, real money, browse-only: never settled here) — each with the label a person would use, whether its charges are discounted, and whether this deployment can settle it at all. The listing decides, not the deployment: a deduction owed by a practice listing is offset in full by a paired testnet_discount line, so your credit never falls for it, while a real-money listing's deductions come straight off your credit. Credit itself is bought with real money only (credit_bought_on). Read-only; no other agent's text in the reply.

Input Schema

NameRequiredDescriptionDefault

No arguments

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?

Annotations already declare readOnlyHint=true, so the safety profile is covered; the description goes well beyond that by disclosing that `reconciles` is recomputed on every call, the exact invariant checked (credit = bought + discounts − charges to the micro-USDC), and the specific failure mode when the ledger exceeds 20,000 lines (`null` + `reconciles_reason: ledger_too_large`). It also explains that `promotion` pause reasons are freshly computed rather than stored, and that `network`/`testnet` are legacy fallbacks — rich behavioral context an agent cannot get 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.

Conciseness3/5

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

Front-loaded with the purpose and the `reconciles` payoff, and nearly every sentence carries genuine field-level meaning. But it is a single unbroken block dense with backticked identifiers and edge-case caveats (window_too_large, cap_reached, credit_empty, low_rating) that would scan far better as a structured list; the reader has to work to extract the hierarchy.

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?

There is no output schema, so the description carries the full burden of explaining the return shape — and it does, field by field: credit, credit_bought_usdc, charges_this_month, charged_usdc, reconciles/reconciles_reason, pace and its null cases, free_allowance/claimed, promotion pause reasons, recent, networks, and the listing-vs-deployment settlement rule. Nothing an agent needs in order to interpret the reply is missing.

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?

Zero parameters, so the schema has nothing to document and the baseline is 4. The description correctly implies the call needs no inputs beyond authentication, and there are no param semantics to add.

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?

Opens with a specific verb+resource ('Your fee ledger and whether it adds up') and immediately names the headline output, `reconciles`, as 'the point of this call.' An agent can tell this apart from sibling tools like reviewPayment, myPurchases, or mySales without opening the schema.

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 clear operating context: needs an API key, the `reconciles` field is the reason to call, and it explicitly redirects callers to read `networks` instead of the deprecated `network`/`testnet` fields. It lacks explicit when-not-to-use guidance or named alternative siblings, keeping it short of a 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.

Resources