Skip to main content
Glama

get_workspace_budget

Read-onlyIdempotent

Workspace Analytics & Billing: the budget of ONE Enterprise workspace, read now (not a date range). Needs a workspace reporting key (wdr_report_…, made by the workspace Owner) for that workspace, or your own sign-in as its Owner or Admin (the whole workspace) or Member (only your own numbers: your wallet, held and used credits; granted, sources and pool_available_credits are null). Returns data + meta. data.granted = every grant and top-up that added credits to the workspace since it began: credits (bonus included), usd (what was paid or granted in $; null when any grant has no $ amount) and how many grants. data.sources = the same split by source (apero_budget = a budget from Wandura, topup = a card purchase). data.pool_available_credits = credits in the shared pool not yet given to anyone. data.wallets = each member wallet: available_credits (spendable now) and held_credits (reserved by runs still in progress). data.held_credits = all credits reserved by runs in progress (they may still be refunded). data.used_credits = credits spent since the workspace began: gross_debit (charged), refunded, net = gross_debit − refunded (net includes held_credits). Moving credits between the pool and a wallet (allocate / reclaim) is never counted as cost. Money: effective_cents_per_credit = total $ granted ÷ total credits received, one price for the whole workspace (method v1-binh-quan); list_cents_per_credit = 1 (1 credit = $0.01 list price); used_cost_effective_usd = net × effective price, used_cost_list_usd = net × list price. When a price is unknown it is null (never 0) and meta.missing_fields says why. Times are ISO 8601 in Asia/Ho_Chi_Minh (+07:00): data.computed_at and meta.data_as_of = when this was computed; meta.earliest_available_at = the workspace's first credit movement. Free; at most 60 calls a minute per key or person. The same report as CSV: GET /api/v1/workspaces/{workspace_id}/reports/get_workspace_budget?format=csv.

Input Schema

NameRequiredDescriptionDefault
workspace_idYesThe workspace: the one the reporting key belongs to, or one you are a member of.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already cover the read-only/idempotent/non-destructive profile, and the description goes well beyond them: per-role data visibility differences, auth key requirements, a 60 calls/minute rate limit, 'free' cost, null-never-zero pricing behavior, and Asia/Ho_Chi_Minh time semantics. Even what is not counted as cost (allocate/reclaim) is disclosed.

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

Conciseness4/5

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

The gist is front-loaded in sentence one and every subsequent sentence carries real information, but the middle block is a dense run of field definitions that is hard to scan and would be better served by an output schema. The CSV endpoint note at the end is a useful, compact closer.

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, the description carries the full burden of documenting the response and does so exhaustively: data.granted, sources, pool_available_credits, wallets, held/used credits, price formulas, missing_fields, and timestamp fields. Nothing an agent needs to interpret the result is absent.

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

Parameters3/5

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

Schema coverage is 100% and the workspace_id description already explains the key-vs-membership scoping, so the description adds little new meaning for the single parameter. Its role-based visibility notes are behavioral context rather than parameter semantics, so the baseline 3 applies.

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 first sentence names a specific verb and resource with scope: the budget of ONE Enterprise workspace, read as of now rather than over a date range. The 'read now (not a date range)' clause explicitly separates it from time-series siblings like get_usage_summary or list_credit_transactions without requiring a schema look.

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 states the access conditions clearly: a wdr_report_ key made by the workspace Owner, or sign-in as Owner/Admin (whole workspace) versus Member (only your own numbers). What is missing is an explicit pointer to sibling tools when a date-ranged or multi-workspace view is wanted.

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