Skip to main content
Glama

Get balance and hunting stats

get_balance

Credit balance, free reviews left, the full hunting record (reviews run, bugs confirmed incl. free minors, false positives, total billed), what everything costs, the last movements of the balance, and a link to Stripe's billing page with the invoices. Call it when the user asks about price, about a charge, or for their payment history – the prices come from the server, so never quote one from memory. For the ACCRUAL HISTORY – what the money bought, what the stories earned, what each hunt cost – pass history (rows per page, newest first) and page with before from the answer's next_cursor. Each row says its kind and hunts – how many hunts a row that is a review, a grant or a code was worth; a movement of money (a top-up of any amount, a refund, a correction) has hunts: null and is read by its delta_usd; catches_left answers a different question and floors, because part of a hunt buys nothing – because the user counts hunts while the ledger counts dollars – the rows that moved no money still moved value, and dollars alone cannot show them. A kind names what happened (purchase / charge / free_review_used / subscription_charge – a review the retired subscription covered, at no charge – / story_grant / promo_grant – a code handing over hunts free hunts – / rating_grant – earned by rating a landing – / species_grant – earned by a species catch, when the server rules and caps allow it – / refund / expiry); credit and debit mean money moved with no more specific reason – an operator correction, money returned – and are also what a movement older than this feature falls back to, so never read a sign label as a date. The one row the history cannot explain is an older one that moved NO money: it reads other, 0 hunts.

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

Input Schema

NameRequiredDescriptionDefault
beforeNoPaging cursor: the `next_cursor` of the previous page. Only meaningful with `history`.
historyNoReturn the accrual history: this many rows, newest first. Omit for the balance alone.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the full behavioral burden and does most of it: it discloses the authoritative source of prices, that history is newest-first and cursor-paged, that money movements carry `hunts: null` and are read via `delta_usd`, and the fallback behavior for rows older than the feature (credit/debit, or `other` with 0 hunts). It omits auth/prerequisite assumptions and any rate-limit or response-size expectations, which keeps it short of a 5.

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?

The usage guidance is front-loaded, but the middle section degenerates into a very long em-dash chain enumerating kinds and apologizing for the `hunts`/`delta_usd`/`catches_left` distinction. The parenthetical asides ('a review the retired subscription covered, at no charge', the aside about counting hunts versus dollars) are informative but buried in one dense paragraph that is hard 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?

There is no output schema, so the description must explain return values, and it does: every documented field and every `kind` value gets a gloss, plus the documented edge cases (money movements with `hunts: null`, legacy `credit`/`debit` fallback, the `other` row that moved no money). An agent can call this and interpret the response without further discovery.

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?

Schema coverage is 100%, so the baseline is 3; the description earns an increment by adding real semantics the schema lacks – that `history` returns rows newest first and that `before` must be taken from the previous answer's `next_cursor`. It does not clarify the interaction of the 200-row maximum over repeated pages or what happens with a stale cursor.

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 clause enumerates the exact resource set returned – credit balance, free reviews left, hunting record, prices, recent movements, and a Stripe invoice link – so the tool's identity is unmistakable. No sibling in the list (get_findings, get_bug_dex, redeem_code, etc.) overlaps with billing/balance reporting, so differentiation is implicit but unambiguous.

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 concrete triggers ('when the user asks about price, about a charge, or for their payment history') plus a hard rule against quoting prices from memory. It also states the mode split explicitly: omit `history` for the balance alone, pass it for accrual history. That is as close to explicit when/when-not as a two-parameter read tool needs.

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.