Skip to main content
Glama

get_usage_summary

Read-onlyIdempotent

Workspace Analytics & Billing: the RUNS of ONE Enterprise workspace (the same runs as list_generation_events, so its rows added up equal these totals) added up per group. 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 (every run) or Member (only your own runs). group_by: any of day, week (its Monday), month (YYYY-MM) — cut in Asia/Ho_Chi_Minh — user, team, project, app, model, feature, channel, output_kind, duration_bucket, requested_duration_bucket, resolution, aspect_ratio, status; none = one row for the whole range. Each row: the group's fields (date, week, month, user_id + email, team ("unclassified" = no team; a person's team when the run finished, so a team change splits at that moment), project_id, app_name, model_id + model_name, feature, channel, output_kind, duration_bucket, requested_duration_bucket, resolution, aspect_ratio, status — as in list_generation_events), then: OUTPUT, on the day a run finished (still running: the day it was sent): attempts (runs; a retry is a new run), succeeded, failed, running (still in progress), outputs_image / outputs_video / outputs_audio (files made), gross_debit_credits, refunded_credits, net_credits (= gross − refunded; a run's refund counts with the run even when posted another day), reserved_credits (still held by runs in progress), cost_effective_usd (the runs' net × meta.cost_basis.effective_cents_per_credit, the workspace's one effective price; null when it has none) and cost_list_usd (1 credit = $0.01); queue_time_seconds (started − sent), generation_time_seconds (finished − started), request_to_result_seconds (finished − sent), each {avg, p50, p90, n, n_approximate}: per run, never parallel runs added together; p50 / p90 nearest-rank within the group; n = runs measured (runs still going are left out: they are in running), n_approximate = how many of them were timed from an approximate start; no sample ⇒ avg / p50 / p90 null, never 0. USE, on the day a run was SENT: active_users (people who sent ≥ 1 run), days_used (days with ≥ 1 run sent, free runs included), days_with_spend (days with ≥ 1 run sent that cost credits), last_used_day (rows per person: their last such day in the range; null = none). approved_creatives: Drama Studio only (the one studio with an approval step: an edit or a film a producer approved), on the day it was approved, for the editor who submitted it (else the approver); every other studio has no approved state yet (meta.missing_fields). Filters (user_id, team, project_id, app, model_id, feature, channel, output_kind, duration_bucket, requested_duration_bucket, resolution, status) work as in list_generation_events: only the matching runs are added up. Grouped by user or team, everyone who belonged to the workspace on a day of the range gets a row, with zeros when they did nothing. The credit ledger by the day each movement was posted is list_credit_transactions, a different view: do not mix the two. compare_previous=true adds the same rows for the window of the same length just before, with window = "previous" (and window = "current" on the others). from (first day, included) and to (the day after the last, excluded), YYYY-MM-DD in Asia/Ho_Chi_Minh, at most 366 days; default the last 30 days including today. Paging: up to limit rows (1–1,000, default 1,000); when meta.next_cursor is not null pass it as cursor (same arguments) for the next page. Free; at most 60 calls a minute per key or person. CSV: GET /api/v1/workspaces/{workspace_id}/reports/get_usage_summary?format=csv&group_by=day,user.

Input Schema

NameRequiredDescriptionDefault
toNoThe day after the last, excluded (YYYY-MM-DD, Asia/Ho_Chi_Minh). Default: tomorrow. At most 366 days after `from`.
appNoOnly runs of this app (app_name: the Cinematic Ads project's app name).
fromNoFirst day, included (YYYY-MM-DD, Asia/Ho_Chi_Minh). Default: 30 days before `to`.
teamNoOnly runs of this team, as the report names it ("unclassified" = people with no team).
limitNoRows per page.
cursorNometa.next_cursor of the previous page, unchanged.
statusNoOnly runs in this state.
channelNoOnly runs that came this way.
featureNoOnly runs of this feature (a feature from list_services, or what a step outside jobs was charged for: cinematic_ads_analysis, cinematic_ads_ai, cinematic_ads_export, drama_chat, …).
user_idNoOnly this person's runs (a user id from list_workspace_members).
group_byNoThe dimensions of a row, e.g. ["day", "user"]. None = one row for the whole range.
model_idNoOnly runs of this model (a model_id from list_services; older names of the same model are included).
project_idNoOnly runs of this project (a Cinematic Ads or Drama Studio project id).
resolutionNoOnly videos of this measured resolution, e.g. 720p (the shorter side in pixels).
output_kindNoOnly runs making this kind of output.
workspace_idYesThe workspace: the one the reporting key belongs to, or one you are a member of.
duration_bucketNoOnly videos whose measured length is in this bucket.
compare_previousNoAlso return the window of the same length just before (rows with window = "previous").
requested_duration_bucketNoOnly videos whose requested length is in this bucket.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds far more: authorization paths and their scope differences, cost ("Free"), a 60-calls-per-minute rate limit per key or person, timezone and 366-day range bounds, cursor paging via meta.next_cursor, and precise semantics for null vs. 0 ("no sample ⇒ avg / p50 / p90 null, never 0"). Member-level row visibility and zero-filled rows for people who did nothing are disclosed up front.

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?

Nearly every clause carries real information, and the purpose is front-loaded in the first sentence. But the body is one enormous run-on paragraph mixing auth, grouping, row schema, metrics, filters, paging, and CSV export, with no headers or line breaks; an agent must parse ~700 dense words to find any single fact.

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 19 parameters and no output schema, the description carries the full burden of describing the return shape, and it does: it enumerates group fields and each metric (attempts, net_credits, reserved_credits, cost_effective_usd, the three latency percentiles with their n and n_approximate semantics) plus the approved_creatives caveat tied to meta.missing_fields. Nothing essential for correct invocation or interpretation appears to be missing.

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?

Schema coverage is 100%, yet the description still adds meaning the schema cannot: group_by is defined operationally (week starts Monday, month as YYYY-MM, cuts made in Asia/Ho_Chi_Minh, none = a single row), from/to are clarified as first-day-included and day-after-last-excluded with a 30-day default, and compare_previous is explained as producing rows tagged window = "previous". It also explains that filters reduce the runs being summed, not just the returned rows.

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?

"Workspace Analytics & Billing: the RUNS of ONE Enterprise workspace ... added up per group" states a specific verb (aggregate), resource (generation runs), and scope (single workspace), and immediately distinguishes itself from list_generation_events by asserting the rows sum to the same totals. An agent can tell exactly what this tool returns without opening the schema.

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?

Explicitly names two alternatives and the conditions that separate them: the same underlying runs as list_generation_events but pre-aggregated, and a different view from list_credit_transactions with the direct instruction "do not mix the two." It also states prerequisites (reporting key or Owner/Admin/Member sign-in) and the Member limitation to own runs.

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