Skip to main content
Glama
thenavidm

fal.ai MCP Server

by thenavidm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Analytics

get_analytics
Read-onlyIdempotent

Retrieve time-bucketed metrics for model endpoints, including request counts, success/error rates, and latency percentiles, to monitor performance 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

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so safety is covered. The description adds real behavioral context beyond them: only metrics named in 'expand' are populated, and it explains the semantic difference between prepare_duration (queue time) and duration (execution time).

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 metric enumeration earns its place, but the 'Key Features' and 'Common Use Cases' sections largely restate what the metric list and opening paragraph already said, adding bulk rather than new information.

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?

With no output schema and 10 parameters, the description is largely sufficient: it explains metric selection, latency semantics, and time bucketing. Minor gaps remain around pagination (cursor/limit) usage and multi-endpoint behavior, but nothing critical for a read-only analytics call.

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 goes further by enumerating every valid 'expand' metric value by category, which the schema's generic expand description does not provide. This materially improves correct metric selection.

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: time-bucketed metrics (request counts, success/error rates, latency percentiles) per model endpoint. An agent can tell this is a read-only performance analytics tool, though it never names siblings like get_usage or get_billing_events to sharpen the boundary.

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?

Provides clear context ('Use with the Queue/Webhooks flow to monitor SLAs') and a list of common use cases (dashboards, latency trends, error tracking). However, it offers no exclusions or explicit routing away from overlapping siblings such as get_usage or get_billing_events.

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