Skip to main content
Glama

Usage

get_usage
Read-onlyIdempotent

Retrieve paginated workspace usage records filtered by endpoint, user, date range, or auth method to build cost reports, track patterns, and monitor API consumption.

Instructions

Returns paginated usage records for your workspace with filters for endpoint, user, date range, and auth method. Each item includes the billed unit quantity, the pre-discount unit price and cost_subtotal, any percentage discount applied, and the final cost_total (cost_subtotal − cost_discount).

Key Features:

  • Usage data for all endpoints or filtered by specific endpoint(s)

  • Flexible date range filtering

  • User-specific usage tracking

  • Detailed usage line items with unit quantity, price, and discount breakdown

  • Paginated results for large datasets

Common Use Cases:

  • Generate usage reports for all endpoints or specific models

  • Track usage patterns

  • Monitor endpoint usage across different auth methods

  • Build usage dashboards and visualizations

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' to include a formatted authentication method label, and 'auth_method_structured' to include 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.
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
login_usernameNoFilter by team member login username(s) (nickname). Accepts 1-50 usernames. Supports comma-separated values: ?login_username=alice,bob or array syntax: ?login_username=alice&login_username=bob
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

A3.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds genuinely useful behavior: what each line item contains (unit quantity, price, discount, cost_total formula), that results are paginated, and that defaults apply to the date range. It does not mention rate limits or cursor expiry, but the added detail is meaningful.

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 opening sentence is well front-loaded, but the 'Key Features' and 'Common Use Cases' bullets largely restate the same filter and pagination facts, and the external docs link adds little for an agent. It is not egregious, but several lines do not earn their place.

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 12-parameter read tool with no output schema, the description does a good job describing the shape of returned records and the pagination model, which compensates for the missing output schema. It is slightly thin on how expansion interacts with returned fields, but overall sufficient to call the tool correctly.

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 12 parameters including defaults and enum semantics. The description only gestures at filters (endpoint, user, date range, auth method) without adding syntax or constraints beyond what the schema provides, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence names a specific verb (returns) and resource (paginated usage records) scoped to 'your workspace', which usefully distinguishes it from organization-wide siblings like get_organization_usage. However, it does not differentiate itself from adjacent tools such as get_analytics, get_billing_events, or list_requests_by_endpoint, which an agent could easily confuse with it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'Common Use Cases' block implies when the tool is useful (reports, dashboards, tracking), but it never states when NOT to use it or names an alternative sibling. An agent must infer the boundary against get_organization_usage and get_analytics on its own.

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