CueFrame

Get Account

get_account

Read-onlyIdempotent

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).

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_account"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description
`plan`	No	The customer's current base plan/tier. null = unknown (billing not configured, or no active plan resolvable yet).
`orgId`	No	The org this API key is bound to — resolved server-side from the Authorization credential, NEVER from the request body/query.
`surfaces`	No	The 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.
`displayName`	No	Org/customer display name from the billing record; null when not set or unknown.
`costCeilings`	No	Discoverable per-call cost ceilings so an agent can price/right-size a request before a guaranteed 402.
`entitlements`	No	Per-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).
`generationLimit`	No	Separate 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.
`billingConfigured`	No	false = 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.

First observedOct 10, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only declare readOnly/idempotent/non-destructive; the description adds the entire funding model (one shared credit wallet via `fundedBy`, per-feature balances as alternative views of the same money), the `listUsdPerUnit` quoting semantics including 0 and null cases, and specific error behavior (billing_required with reason free_generation_cap). It also discloses that free accounts start with a grant and can still spend, which is exactly the kind of non-obvious trait annotations cannot convey.

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 action directive is correctly front-loaded, but the middle is a dense wall of field-level documentation for `balance`, `included`, `fundedBy`, `creditCost`, `listUsdPerUnit`, and `costCeilings` that largely duplicates the output schema. Several sentences (e.g. the full enumeration of which features spend the shared wallet) could be compressed without losing the decision rule.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given an output schema exists, the definition is more than complete — it covers funding semantics, error reasons, free-tier caveats, and the per-call cap name. The only shortfall is that it pours return-value documentation into the description rather than letting the output schema carry it, which is a completeness-by-volume rather than completeness-by-gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Zero parameters, so the baseline is 4; it earns a 5 by explicitly stating 'No args — identity is resolved from your key (never echoed from input)', which prevents an agent from inventing an account_id argument. That is meaningful semantics for an otherwise 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?

The opening clause names a specific verb and resource ('show THIS key's account') and enumerates exactly what is returned: bound org, current plan, entitlements map, cost ceilings. It is clearly distinguishable from get_usage and list_plans, which sit alongside it as siblings.

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 an explicit ordering rule ('ORIENT FIRST ... before you spend a metered call') plus a concrete read rule ('READ `balance`, NOT `included`') and an explicit pre-call check pattern against cost. The agent is told not just when to call it but what to do with the result before calling metered siblings like generate_media or compose.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All CueFrame tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.