Skip to main content
Glama
thenavidm

fal.ai MCP Server

by thenavidm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Analytics

get_analytics
Read-onlyIdempotent

Retrieve time-bucketed performance metrics per model endpoint to monitor request counts, success/error rates, latency percentiles, and SLAs.

Instructions

Time-bucketed metrics per model endpoint, including request counts, success/error rates, and latency percentiles. prepare_duration reflects queue/prepare time before execution; duration is request execution time. Use with the Queue/Webhooks flow to monitor SLAs.

Metric Selection: You must specify which metrics to include using the expand query parameter. Only requested metrics will be populated in the response, allowing you to optimize query performance and data transfer.

Available Metrics:

The expand parameter accepts these values, grouped by category:

Volume

  • request_count: Total number of requests in the time bucket

  • success_count: Successful requests (2xx responses)

  • user_error_count: User errors (4xx responses)

  • error_count: Server errors (5xx responses)

Error type breakdown

  • startup_error_count: Startup errors (startup timeout, scheduling failure)

  • connection_error_count: Connection errors (timeout, disconnected, refused)

  • timeout_error_count: Request timeout errors

  • runtime_error_count: Runtime errors (internal error, server error)

Queue / prepare latency

  • p50_prepare_duration, p75_prepare_duration, p90_prepare_duration, p95_prepare_duration, p99_prepare_duration: Time from request submission until execution starts

Request execution latency

  • p25_duration, p50_duration, p75_duration, p90_duration, p95_duration, p99_duration: Time spent processing the request

Cold boot

  • cold_boot_count: Requests with cold boot (startup > 1s)

  • p50_cold_boot_duration, p75_cold_boot_duration, p90_cold_boot_duration: Cold boot duration percentiles

Billing

  • total_billable_duration: Aggregate billed execution time

Key Features:

  • Selective metric inclusion via expand parameter

  • Performance metrics (latency percentiles, duration stats)

  • Reliability metrics (success/error rates, request counts)

  • Error type breakdown (startup, connection, timeout, runtime)

  • Cold boot metrics (count, latency percentiles)

  • Billing duration tracking

  • Time-bucketed data for trend analysis

  • Single or multi-model analytics

  • Flexible date range and timeframe options

Common Use Cases:

  • Monitor model performance and reliability

  • Generate performance dashboards

  • Analyze latency trends and patterns

  • Track error rates and success metrics

See Queue API 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 and metrics to include in the response. Use 'time_series' for time-bucketed data, metric names for specific metrics in time series, and 'summary' for aggregate statistics. At least one of 'time_series' or 'summary' and at least one metric are 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).
endpoint_idYesFilter 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
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/5.0
Behavior4/5

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

Annotations already establish the safe read-only, idempotent, non-destructive profile, so the bar is lower. The description still adds meaningful behavior: preparation vs execution duration semantics, the requirement that metrics be explicitly requested via expand, and defaults/cursor pagination context, none of which the annotations convey.

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?

Well front-loaded with the core semantics and a clear metric catalog, but the 'Key Features' and 'Common Use Cases' blocks largely restate material already covered above (selective metrics, latency percentiles, error breakdown), inflating length without adding decisions the agent needs.

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?

No output schema exists, so the description carries return-value burden, and it adequately describes the metric shape and bucketing options. It is close to complete for a 10-parameter analytics tool, with only mild gaps around pagination behavior and the account parameter's meaning beyond the schema.

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 coverage is 100% so the baseline is 3, but the description earns more by enumerating the full set of valid expand metric values grouped by category (volume, error type, latency, cold boot, billing) and clarifying the prepare/duration distinction, which the schema's coarser expand description does not.

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+resource with scope: 'Time-bucketed metrics per model endpoint, including request counts, success/error rates, and latency percentiles.' It clearly differentiates from nearby siblings like get_usage and get_billing_events by being per-endpoint performance/latency analytics.

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?

Gives a usage context ('Use with the Queue/Webhooks flow to monitor SLAs') and lists common use cases, and the expand section implies when metric selection matters. However it never names an alternative tool (e.g. get_usage or get_billing_events) or states when NOT to use this tool, so the agent must infer the boundary.

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

Deploy Server

Other Tools