Skip to main content
Glama

What this caller is entitled to, and what it would be charged

get_account
Read-only

Who the credential in front of this request resolves to, which of the two paid lanes it would take, what it has left to spend, and the price of every route on both lanes. Unmetered and answerable WITHOUT a key: checking your balance must never cost a unit and must never be the thing that fails. A caller with no key gets a real answer (tier: anonymous, lane: x402, the full price list), not a 401, so both prices can be compared before committing to either. An unrecognised key also answers 200, with key_recognised: false — this is the endpoint you reach for when your key is the thing that is broken, so it must work then.

Wraps GET /v0/account. Access: no API key required.

Returns:

  • authenticated: Whether a credential was accepted.

  • key_present: Whether a credential was sent at all.

  • key_recognised: Whether it resolved, or NULL when none was sent — three-valued, because "no key" and "a key that did not resolve" need different fixes and one false for both would conflate them.

  • tier: anonymous, trial, oauth, or the organization key tier.

  • plan: The organization's plan key, or null when there is no organization.

  • lane: Which lane this caller would take on a metered route, so it can be PREDICTED rather than discovered by being refused: credit draws down Query Units, x402 pays per call, invalid_key resolves to nothing, no_account is a caller with no organisation behind it on the MCP surface, where there is no x402 door, and upgrade_required is that same surface reached by a caller that HAS an organisation whose plan excludes the route. The last two were one value until a signed-in connection with an organisation and a balance was told it had no account behind it.

  • organisation: Id and display name, or null. Named so an operator with several accounts knows which one to top up.

  • balance: Units available and the low-balance threshold, or NULL with a balance_note saying why there is no balance to report — an organizationless caller has none, which is not the same as having zero. low_balance is already computed here so a client does not have to know the threshold to apply it.

  • metered_routes: Every route with what one call costs on each lane: qu on the credit lane, x402_usd on the payment lane. Routes that cost nothing are listed AT ZERO rather than omitted, because a caller cannot tell "free" from "not thought about" by absence. runSql's qu is its MINIMUM — a query is priced by the time it takes, and sql_tiers gives the ceilings.

  • balance_note: Present only when balance is null, saying WHICH kind of nothing it is: no credential, one that did not resolve, a trial key that holds no balance by design, or an organization row that could not be read. A null balance is never a zero.

  • sql_tiers: What one run_sql call may cost, which is no longer one number: a query is priced by the time it takes, at one Query Unit per started five seconds with a floor of one. Each tier gives its timeout_seconds, its max_qu (what is HELD for the call and the most it can cost), its own rate limit, and two separate booleans — allowed is whether this caller's plan may buy it, available is whether this deployment can serve it at all. They are separate because "upgrade your plan" and "report a misconfiguration" are different things to go and do, and note says which applies.

  • top_up_url: Org-scoped deep link to the top-up page, or the plans page for a caller with no organization.

  • as_of: When this answer was assembled.

  • summary: One sentence saying what this lane means, for a human reading it in an agent transcript.

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 only declare readOnly/openWorld/non-destructive; the description goes well beyond that by promising an unmetered call that never costs a unit, always returns 200 rather than 401 for missing or unrecognised keys, and explains the three-valued key_recognised and the null-vs-zero balance distinction. These are exactly the operational traits an agent cannot infer from structured fields, and nothing contradicts readOnlyHint.

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 lead sentence is well front-loaded and the Returns block is organized field-by-field, but the total length is excessive and carries editorial design-history that does not help an agent act — notably the changelog aside about 'the last two were one value until a signed-in connection…' and the recurring justifications of null-vs-zero. Roughly a third of the text is rationale rather than instructions, so it is structured but not tight.

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, documenting return values is squarely the description's job, and it does so exhaustively: every field of the response is enumerated with its meaning, its null cases, and its enum values for tier, lane, and sql_tiers. An agent can parse the response and branch on lane without any other source.

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?

The tool takes zero parameters, so the 4 baseline applies and there is no parameter semantics to add. The description correctly spends no space on input arguments and instead devotes itself to the response shape, which is the right allocation.

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 sentence names a concrete verb set (resolves identity, selects lane, reports balance and prices) against a specific resource — the credential in front of the request — and verb 'wraps GET /v0/account' anchors it. Among siblings like get_agent, get_capability, and list_wallets, no other tool claims to report caller identity plus entitlement plus pricing, so the agent can route here unambiguously.

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 a strong when-to-use: check entitlement and price before committing to a lane, and specifically reach for it when your own key is the thing that is broken. It also states the no-key case is valid, which prevents the agent from self-censoring the call. What it lacks is an explicit contrast against siblings (e.g. why get_account rather than get_agent for identity), so the routing is implied rather than spelled out.

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