Skip to main content
Glama

Usage

get_usage
Read-onlyIdempotent

Retrieve paginated workspace usage records filtered by endpoint, user, date range, or auth method, including billed quantities, discounts, and final costs.

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 real behavioral value on top: it discloses the response fields (billed unit quantity, pre-discount price, cost_subtotal, discount, cost_total with its formula) and pagination, which matters because there is no output schema. It stops short of describing pagination limits or rate behavior.

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 paragraph is well front-loaded and earns its place, but the 'Key Features' bullets largely restate that same paragraph (filters, pagination, line-item detail), and the 'Common Use Cases' list is padding. Roughly half the text is redundant with the intro.

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, zero-required read tool with no output schema, the description compensates well by spelling out the returned cost/quantity fields and noting pagination. It is not fully complete because it omits the sibling disambiguation against get_organization_usage/get_analytics and says nothing about page-size limits despite the 'limit' parameter.

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 the endpoint/user/date/auth filters. The description only echoes those same filter categories ('filters for endpoint, user, date range, and auth method') without adding format, defaulting, or interaction detail, so baseline 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?

States a specific verb+resource ('Returns paginated usage records for your workspace') and enumerates the filterable dimensions, so the agent knows this is a read/list tool. However, it never differentiates itself from close siblings such as get_organization_usage, get_analytics, or get_billing_events, all of which plausibly return overlapping usage/cost data.

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 this tool is useful (usage reports, dashboards, auth-method monitoring), which is a step above nothing. But it gives no when-not guidance and never names an alternative tool, leaving the agent to guess whether get_organization_usage or get_analytics is the right sibling for a given query.

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