Skip to main content
Glama

Get Account

get_account
Read-only

ORIENT FIRST — show THIS key's account before you spend a metered call: the org it is bound to, the current plan, a per-feature entitlements map, and per-call cost ceilings. READ balance, NOT included. CueFrame is credit-funded: rendering (entitlements.exports), generation (generate), preview stills (compose_capture), the judge (compose_verify) and the Director (compose) have NO separate per-plan allowance — they all spend one shared wallet, named in fundedBy (credits; generation is metered in provider-cost units against that wallet). Each balance restates that ONE wallet in that feature's own unit at creditCost credits per unit, so they are alternative ways to spend the same money, not four budgets. Each entitlement also carries listUsdPerUnit: the dollar quote for ONE unit before you call (0 = a plan grant that draws no credits, e.g. resource_import — stock search + import are free; null = not quotable up front). Check the requested cost against the balance. For generation, also check generationLimit: free accounts have a separate provider-cost cap even with a positive wallet. A billing_required error with reason free_generation_cap requires a credit-pack purchase through normal checkout. included:false means the plan genuinely lacks the feature. Every new org starts with a free credit grant, so an account with an empty usage history can still render, generate, preview and score. costCeilings.generateMediaUsdPerCall is the generate_media per-call USD cap. No args — identity is resolved from your key (never echoed from input).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
planNoThe customer's current base plan/tier. null = unknown (billing not configured, or no active plan resolvable yet).
orgIdNoThe org this API key is bound to — resolved server-side from the Authorization credential, NEVER from the request body/query.
surfacesNoThe browser URLs that actually exist, so an agent asked to "show me" can hand the user a real link instead of guessing one from an id. A null means the surface is not built, not that it is hidden from this key.
displayNameNoOrg/customer display name from the billing record; null when not set or unknown.
costCeilingsNoDiscoverable per-call cost ceilings so an agent can price/right-size a request before a guaranteed 402.
entitlementsNoPer-feature entitlements keyed by featureId. Covers the billing-gated capabilities: `exports` gates create_render AND generate_media output; `compose` gates compose; `brand_kits` gates create_brand_kit; `resource_import` gates import_resource (a boolean grant: `listUsdPerUnit` 0 — stock search and import cost no credits for a keyed caller); plus ai_tokens/storage/compose_verify/compose_capture/etc. Read `listUsdPerUnit` for what one unit costs before you spend it. Most capabilities are CREDIT-FUNDED — `included` is true and the real limit is `balance`, drawn from the shared wallet named in `fundedBy` (`credits` — generation included; a free org is additionally bounded by a generation cap). So read `balance`, not `included`, to decide whether you can afford a call; `included:false` means the plan genuinely lacks the feature. Check BEFORE a metered call to avoid a mid-workflow 402 billing_required (whose error `details.featureId` names the gating feature).
generationLimitNoSeparate lifetime generation cap before a credit-pack purchase. Wallet balance is still shared; generation must also fit this remaining provider-cost allowance. null means unknown.
billingConfiguredNofalse = billing is not configured in this environment, so plan/entitlement values are best-effort and may be null (unknown), not authoritative.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

With only readOnlyHint/openWorldHint available, the description carries the full behavioral burden and does so richly: it explains the shared-wallet funding model, that balance values are alternative restatements of one pool rather than separate budgets, that null/0 listUsdPerUnit mean distinct things, and the free_generation_cap failure mode. This is well beyond what annotations provide.

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 opening 'ORIENT FIRST' cue is well front-loaded, but the bulk is a dense, jargon-heavy single paragraph mixing billing, entitlement and error semantics. Much of the field-by-field billing lecture could be trimmed or deferred to the output schema, so it is over-sized for a no-arg read.

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?

Even though an output schema exists, the description supplies the interpretation key (balance vs included, fundedBy, creditCost, costCeilings) an agent needs to act on the response. Nothing required to call or make sense of this tool 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 gives a baseline of 4, and the description adds a useful note — 'No args — identity is resolved from your key (never echoed from input)' — clarifying that the key is the implicit input. No further parameter detail is possible, so this is the ceiling of useful value.

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 states a specific verb and resource up front — 'show THIS key's account' — and enumerates exactly what it returns (org binding, plan, entitlements map, per-call cost ceilings). It is clearly distinguishable from siblings like get_usage or list_plans.

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?

'ORIENT FIRST — show THIS key's account before you spend a metered call' gives explicit when-to-use guidance framed by a cost constraint. It goes further by telling the agent what to inspect (balance, generationLimit, listUsdPerUnit) and how to react to a billing_required error.

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.