Skip to main content
Glama

Organization Usage

get_organization_usage
Read-onlyIdempotent

Retrieve paginated organization-wide usage records across all teams and fal product lines, filtered by team, product, API key, endpoint, and date range.

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.1/5.0
Behavior4/5

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

The description adds critical context beyond annotations: it requires an admin API key on the root team, is for enterprise organizations, and describes attribution via 'username' and 'product' fields. It also explains pagination, but not return format details. Annotations already cover read-only/idempotent safety.

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-loaded with purpose, then breaks down product lines and constraints with bullet-style key features. The >Availability blockquote is clear. It is well-structured but slightly verbose with the example and documentation link.

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?

For a 13-parameter read-only tool with no output schema, the description covers access requirements, product lines, and attribution fields. It misses describing the structure of returned records beyond the two fields mentioned, but annotations and schema fill some gaps.

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 description coverage is 100%, so the schema already documents all 13 parameters thoroughly. The description lists some filterable fields (team_username, product, endpoint, api_key_id, date range, auth method) but doesn't add meaning beyond the schema. Baseline 3 is correct.

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 uses a specific verb and resource ('Returns paginated usage records across all teams and product lines in your organization'), clearly distinguishing it from get_usage (which is presumably single-team/account) and get_organization_teams.

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?

States clear availability constraints ('enterprise customers with organizations enabled', 'admin API key on the organization's root team') and implied usage context. It doesn't explicitly differentiate from the sibling get_usage, though.

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