Skip to main content
Glama

Organization Usage

get_organization_usage
Read-onlyIdempotent

Retrieve paginated usage records across all teams and product lines, with per-team and per-product attribution; filter by date, team, product, endpoint, or API key.

Instructions

Returns paginated usage records across all teams and product lines in your organization, with each record attributed to a specific team via the username field and a product line via the product field.

Covers all three fal product lines:

  • model_apis — model API endpoint calls (e.g. fal-ai/flux/dev)

  • serverless — fal Serverless SDK billing

  • compute — fal Compute (raw instance time)

Availability: This endpoint is available to enterprise customers with organizations enabled. Contact your account team or support@fal.ai to request access.

Must be called with an admin API key on the organization's root team.

Key Features:

  • Organization-wide usage data across all teams and products

  • Filter by team(s) (team_username), product line (product), endpoint, API key (api_key_id), date range, and auth method

  • Per-team and per-product attribution on every usage record

  • Paginated time series and aggregate summary views

See fal.ai docs for more details.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endNoEnd date in ISO8601 format, exclusive (e.g., '2025-02-01T00:00:00Z' or '2025-02-01'). Data up to but not including this timestamp is returned. Defaults to current time.
limitNoMaximum number of items to return. Actual maximum depends on query type and expansion parameters.
startNoStart date in ISO8601 format (e.g., '2025-01-01T00:00:00Z' or '2025-01-01'). Defaults to 24 hours ago.
cursorNoPagination cursor from previous response. Encodes the page number.
expandNoData to include in the response. Use 'time_series' for time-bucketed data, 'summary' for aggregate statistics, 'auth_method' for a resolved authentication method label, and 'auth_method_structured' for a machine-readable auth method object (detail, api_key_id, login_username). At least one of 'time_series' or 'summary' is required.
accountNoExact private account key profile label, not an authenticated provider owner ID.
productNoRestrict results to one or more product lines. Accepts a comma-separated list or repeated parameter. Defaults to all three (model_apis, serverless, compute).
timezoneNoTimezone for date aggregation and boundaries. All timestamps in responses are in UTC, but this controls how dates are bucketed.UTC
timeframeNoAggregation timeframe for timeseries data (auto-detected from date range if not specified). Auto-detection uses: minute (<2h), hour (<2d), day (<64d), week (<183d), month (>=183d).
api_key_idNoFilter by specific API key ID(s). Accepts 1-50 key IDs. Supports comma-separated values: ?api_key_id=key1,key2 or array syntax: ?api_key_id=key1&api_key_id=key2
endpoint_idNoFilter by specific endpoint ID(s). Accepts 1-50 endpoint IDs. Supports comma-separated values: ?endpoint_id=model1,model2 or array syntax: ?endpoint_id=model1&endpoint_id=model2
team_usernameNoFilter by one or more team usernames within the organization. Accepts a comma-separated list or repeated parameter. If not provided, returns usage across all teams.
bound_to_timeframeNoWhether to adjust start/end dates to align with timeframe boundaries and use exclusive end. Defaults to true. When true, dates are aligned to the start of the timeframe period (e.g., start of day) and end is made exclusive (e.g., start of next day). When false, uses exact dates provided.true

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: the admin-key-on-root-team auth requirement, the enterprise availability gate, pagination behavior, and the fact that every record carries team (username) and product attribution. It stops short of describing rate limits or response envelope details.

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?

Front-loads the core purpose, then availability and auth, then features — a sensible ordering. It is on the long side and the 'Key Features' bullet list partially restates the opening paragraph and the filter set already in the schema, which is mild redundancy rather than waste.

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?

For a 13-parameter, no-output-schema tool this covers everything an agent needs: auth prerequisite, availability gate, filter dimensions, enumeration of product lines, pagination, and the shape of each returned record. Nothing essential to invoking it correctly 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?

Schema description coverage is 100%, so the baseline is 3. The description adds some meaning on top: it spells out the three product values with descriptions, names the attribution fields returned per record, and groups the filter dimensions (team, product, endpoint, api_key_id, date range, auth method). No extra syntax or format guidance is added, but the added framing is real.

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?

States a specific verb and resource ('Returns paginated usage records') and immediately bounds the scope to 'across all teams and product lines in your organization,' which is what separates it from the team-scoped get_usage/get_analytics siblings. The enumerations of the three product lines and the per-record attribution fields leave no ambiguity about what this tool produces.

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?

Gives concrete prerequisites and gating conditions: enterprise-only availability and the requirement to call with an admin API key on the organization's root team. It does not, however, explicitly name an alternative tool or state when a sibling (e.g. get_usage for a single team) would be the better choice, so routing is inferred rather than directed.

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