Skip to main content
Glama

check_balance

Read-onlyIdempotent

Read your own account and cost nothing: credit balance left, the USDC funding address to top up, key tier and expiry, and lifetime usage totals. Takes no arguments and is not billed. Call it after an HTTP 402 from compress to see the shortfall, or before a long batch to confirm credit. It reads the account belonging to the API key in your MCP client config (Authorization: Bearer ...) - that is the balance compress bills against.

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

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds what they cannot: the call is not billed, it takes no arguments, and it authenticates via the Bearer token in the MCP client config. It also states which account is read (the one compress bills against), removing ambiguity that no structured field captures.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Three sentences, front-loaded with what the tool returns, followed by cost behavior and then auth/usage. Every sentence carries distinct information (returns, cost, trigger conditions, identity) with no repetition.

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, but the description compensates by naming the exact fields the agent will get back plus the cost and auth model. Nothing needed to invoke this correctly or interpret its result 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 yields a baseline of 4, and the description confirms this explicitly with 'takes no arguments,' which is useful reassurance but nothing beyond the empty 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?

Opens with a specific verb and resource and then enumerates exactly what is returned: credit balance, USDC funding address, key tier/expiry, lifetime usage totals. It also positions itself against the only sibling by tying itself to the HTTP 402 flow from compress, so the agent can distinguish the two without reading schemas.

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?

Gives explicit trigger conditions: call it after an HTTP 402 from compress to diagnose the shortfall, or before a long batch to confirm credit. Both when-to-use cases are named concretely, with the alternative (compress) referenced by name.

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