fal Release Notes

Platform MCP Server

fal's second MCP server — the Platform API MCP — is now available at https://api.fal.ai/v1/mcp/platform. Where the Run MCP lets your AI assistant build with models, this one lets it operate your fal account: connect Claude Code, Cursor, or any MCP-compatible client with your API key and ask "why did my last request to my-app fail?" — your assistant walks the same debugging steps you would.

15 tools: eleven first-class serverless debugging tools covering requests, logs, error analytics, deploy and revision history, runner and queue state, spend, and persistent storage — plus a four-tool discovery gateway that opens up the rest of the Platform API (compute, workflows, keys, account, organization, storage) without bloating your assistant's context.

claude mcp add --transport http fal-platform \
  https://api.fal.ai/v1/mcp/platform \
  --header "Authorization: Key YOUR_FAL_KEY"

• Read-only — it can observe your account but never change it; write operations are listed in the catalog but refuse to execute
• Stateless — your key is sent per-request and never stored, and normal permission and ownership scoping applies
• Free — tool calls are the same Platform API calls you could make directly with your key

Setup guide →

New Serverless Observability APIs

A batch of endpoints rounds out programmatic access to what the dashboard shows about your serverless apps:

• GET /v1/serverless/apps — list your deployed apps with live state: active runners, queue size, machine types, and environment. Add expand=endpoints to include each app's route-level endpoint ids, in the exact form the requests and analytics APIs accept.
• GET /v1/serverless/apps/{owner}/{name}/events — operational event history: deployments, configuration changes, and runner lifecycle transitions — the "what changed around this time?" API. Also surfaced in the dashboard's events timeline.
• GET /v1/serverless/apps/{owner}/{name}/revisions — revision history with deployment status, who deployed, and deploy messages and annotations (the API behind the August 3 entry above) — line revision boundaries up against your error timeline to spot a bad deploy.
• GET /v1/serverless/apps/{owner}/{name}/runners/history — historical runner counts by state (running, idle, pending, draining) for capacity analysis and incident forensics. …

GPU Utilization in Runner Telemetry

Runner telemetry now includes a dedicated GPU Utilization chart alongside the existing CPU, memory, and VRAM charts, so you can see how much compute your GPUs are actually doing -- not just how much memory they hold.

• GPU Utilization reports the average compute utilization across a runner's GPUs over time, surfaced both as a current stat and a time-series chart in the runner side sheet.
• Pair it with VRAM Usage to tell a memory-bound runner apart from a compute-bound one, making it easier to right-size machine types and spot under-utilized GPUs.

Open any runner from the Runners page (Dashboard → Apps → [your-app] → Runners) to view its telemetry. See Runner Analytics for details.

App-Level Retry Configuration

Apps can now register a default per-condition retry budget at deploy time with the new retry_config deployment option, using the same format as the X-Fal-Retry-Config request header.

• Set it as a class attribute on fal.App or under the app's table in pyproject.toml.
• Applies to all queue-based requests to the app; the app owner can still override it per-request with the X-Fal-Retry-Config header.
• Each condition (server_error, timeout, connection_error) keeps an independent budget, bounded by the platform ceiling of 10 total attempts.

See Retries and Error Handling for details.