How do I use fal.ai MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@fal.ai MCP Server generate a realistic image of a cat" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

fal.ai MCP Server

by derekalia

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

fal.ai MCP Server

A Model Context Protocol (MCP) server for interacting with fal.ai models and services. This server enables Claude Desktop and other MCP clients to discover, search, and generate content using fal.ai's powerful AI models.

Features

Model Discovery: List and search through fal.ai's model gallery using Platform API v1
Advanced Search: Free-text search with filtering by category, status, and more
Model Lookup: Find specific models by endpoint ID with optional schema expansion
Pricing Information: Get real-time pricing for models (output-based or GPU-based)
Cost Estimation: Estimate costs using historical API pricing or unit pricing
Usage Tracking: Get detailed billing usage records with time-series data
Analytics: Track request counts, latency statistics, and success/error rates
Schema Inspection: Get detailed input/output schemas with inline OpenAPI expansion
Content Generation: Generate images, videos, and other content using AI models
Queue Management: Track generation status, retrieve results, and cancel requests
File Upload: Upload files to fal.ai CDN for use with models
Full TypeScript Support: Type-safe API with comprehensive TypeScript definitions
Cursor-based Pagination: Efficient pagination through large result sets

Related MCP server: fal.ai MCP Server

Installation

Via npm (Recommended)

npm install -g fal-ai-mcp-server

From Source

git clone https://github.com/derekalia/fal-mcp-ts
cd fal-mcp-ts
npm install
npm run build
npm link

Configuration

Get Your API Key

Sign up at fal.ai
Navigate to your API keys page
Create a new API key

Configure MCP Client

Add the server to your MCP client configuration. The API key should be provided via environment variables.

Claude Desktop

Add to your Claude Desktop config file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\\Claude\\claude_desktop_config.json

{
  "mcpServers": {
    "fal": {
      "command": "npx",
      "args": ["-y", "fal-ai-mcp-server"],
      "env": {
        "FAL_KEY": "your-fal-api-key-here"
      }
    }
  }
}

Claude Code

For project-specific configuration, create a .mcp.json file in your project root:

{
  "mcpServers": {
    "fal": {
      "command": "npx",
      "args": ["-y", "fal-ai-mcp-server@latest"],
      "env": {
        "FAL_KEY": "your-fal-api-key-here"
      }
    }
  }
}

Using @latest ensures you always get the newest version automatically!

Security Note: Never commit .mcp.json files containing API keys to version control. Add it to your .gitignore file.

Cursor

Add to ~/.cursor/mcp.json:

{
  "mcpServers": {
    "fal": {
      "command": "npx",
      "args": ["-y", "fal-ai-mcp-server"],
      "env": {
        "FAL_KEY": "your-fal-api-key-here"
      }
    }
  }
}

Other MCP Clients

For other MCP clients, use the command:

FAL_KEY="your-api-key" npx -y fal-ai-mcp-server

Available Tools

`models`

List available models in the fal.ai model gallery using the Platform API v1.

Parameters:

category (optional): Filter by category (e.g., "text-to-image", "image-to-video", "training")
cursor (optional): Pagination cursor from previous response
limit (optional): Models per page (default: 100, max: 100)
status (optional): Filter by status - "active" or "deprecated"
expand (optional): Array of fields to expand. Supported: ["openapi-3.0"] to include full OpenAPI schema

Example:

{
  "category": "text-to-image",
  "status": "active",
  "limit": 50,
  "expand": ["openapi-3.0"]
}

`search`

Search for models using free-text query across name, description, and category.

Parameters:

query (required): Free-text search query
cursor (optional): Pagination cursor from previous response
limit (optional): Results per page (default: 50, max: 100)
category (optional): Filter by category
status (optional): Filter by status - "active" or "deprecated"
expand (optional): Array of fields to expand. Supported: ["openapi-3.0"]

Example:

{
  "query": "flux image generation",
  "status": "active",
  "limit": 20
}

`find`

Find specific model(s) by endpoint ID. Can retrieve single or multiple models.

Parameters:

endpoint_ids (required): Array of endpoint IDs (1-50 models)
expand (optional): Array of fields to expand. Supported: ["openapi-3.0"]

Example:

{
  "endpoint_ids": ["fal-ai/flux/dev", "fal-ai/flux-pro"],
  "expand": ["openapi-3.0"]
}

`schema`

Get the input/output schema for a specific model.

Parameters:

app_id (required): Model application ID (e.g., "fal-ai/flux/dev")

Example:

{
  "app_id": "fal-ai/flux/dev"
}

`generate`

Submit a generation request to a fal.ai model.

Parameters:

app_id (required): Model application ID
input_data (required): Model-specific input parameters
webhook_url (optional): Webhook for result notification
output_format (optional): "json" or "binary" (default: "json")

Example:

{
  "app_id": "fal-ai/flux/dev",
  "input_data": {
    "prompt": "A beautiful sunset over mountains",
    "image_size": "landscape_4_3",
    "num_inference_steps": 28
  }
}

`result`

Get the result of a generation request.

Parameters:

app_id (required): Model application ID
request_id (required): Request ID from generate()

Example:

{
  "app_id": "fal-ai/flux/dev",
  "request_id": "abc123-def456-ghi789"
}

`status`

Check the status of a generation request without fetching full results.

Parameters:

app_id (required): Model application ID
request_id (required): Request ID to check

Example:

{
  "app_id": "fal-ai/flux/dev",
  "request_id": "abc123-def456-ghi789"
}

`cancel`

Cancel a pending or processing generation request.

Parameters:

app_id (required): Model application ID
request_id (required): Request ID to cancel

Example:

{
  "app_id": "fal-ai/flux/dev",
  "request_id": "abc123-def456-ghi789"
}

`upload`

Upload a file to fal.ai CDN for use with models.

Parameters:

file_path (required): Path to the file to upload
content_type (optional): MIME type (auto-detected if not provided)

Example:

{
  "file_path": "/path/to/image.png"
}

`pricing`

Get pricing information for specific model endpoint(s). Requires authentication.

Parameters:

endpoint_ids (required): Array of endpoint IDs to get pricing for (1-50 models)
cursor (optional): Pagination cursor from previous response

Example:

{
  "endpoint_ids": ["fal-ai/flux/dev", "fal-ai/flux-pro"]
}

Response:

{
  "prices": [
    {
      "endpoint_id": "fal-ai/flux/dev",
      "unit_price": 0.025,
      "unit": "image",
      "currency": "USD"
    }
  ],
  "next_cursor": null,
  "has_more": false
}

`estimate_cost`

Estimate costs for model operations. Requires authentication. Useful for budget planning and cost optimization.

Estimation Methods:

Historical API Price (historical_api_price):
- Based on historical pricing per API call from past usage patterns
- Use when you know the number of API calls you'll make
- Example: "How much will 100 calls to flux/dev cost?"
Unit Price (unit_price):
- Based on unit price × expected billing units (images, videos, etc.)
- Use when you know the expected output quantity
- Example: "How much will 50 images from flux/dev cost?"

Parameters:

estimate_type (required): Either "historical_api_price" or "unit_price"
endpoints (required): Map of endpoint IDs to quantities

Example - Historical API Price:

{
  "estimate_type": "historical_api_price",
  "endpoints": {
    "fal-ai/flux/dev": {
      "call_quantity": 100
    },
    "fal-ai/flux/schnell": {
      "call_quantity": 50
    }
  }
}

Example - Unit Price:

{
  "estimate_type": "unit_price",
  "endpoints": {
    "fal-ai/flux/dev": {
      "unit_quantity": 50
    },
    "fal-ai/flux-pro": {
      "unit_quantity": 25
    }
  }
}

Response:

{
  "estimate_type": "unit_price",
  "total_cost": 1.88,
  "currency": "USD"
}

`usage`

Get usage records for your workspace with detailed billing information. Returns time-series data and/or summary statistics with unit quantities and prices. Requires authentication.

Parameters:

endpoint_ids (required): Array of endpoint IDs to get usage for (1-50 models)
start (optional): Start date in ISO8601 format (e.g., "2025-01-01" or "2025-01-01T00:00:00Z"). Defaults to 24 hours ago
end (optional): End date in ISO8601 format. Defaults to current time
timeframe (optional): Aggregation timeframe - "minute", "hour", "day", "week", or "month". Auto-detected if not specified
timezone (optional): Timezone for date aggregation (e.g., "UTC", "America/New_York"). Defaults to "UTC"
bound_to_timeframe (optional): Whether to align start/end dates to timeframe boundaries. Defaults to true
expand (optional): Array of data to include - "time_series", "summary", "auth_method". Defaults to ["time_series"]
cursor (optional): Pagination cursor from previous response
limit (optional): Maximum number of items to return

Example:

{
  "endpoint_ids": ["fal-ai/flux/dev", "fal-ai/nano-banana"],
  "start": "2025-10-01",
  "end": "2025-10-31",
  "timeframe": "day",
  "expand": ["time_series", "summary"]
}

Response:

{
  "time_series": [
    {
      "bucket": "2025-10-23T00:00:00+00:00",
      "results": [
        {
          "endpoint_id": "fal-ai/flux/dev",
          "unit": "shared_gateway_request",
          "quantity": 8,
          "unit_price": 0.025
        }
      ]
    }
  ],
  "summary": [
    {
      "endpoint_id": "fal-ai/flux/dev",
      "unit": "shared_gateway_request",
      "quantity": 15,
      "unit_price": 0.025
    }
  ]
}

`analytics`

Get analytics data for model endpoints with time-bucketed metrics. Returns request counts, latency statistics (avg, p50, p95, p99), and success/error rates. Requires authentication.

Parameters:

endpoint_ids (required): Array of endpoint IDs to get analytics for (1-50 models)
start (optional): Start date in ISO8601 format. Defaults to 24 hours ago
end (optional): End date in ISO8601 format. Defaults to current time
timeframe (optional): Time bucket size - "hour", "day", "week", or "month". Auto-detected if not specified
timezone (optional): Timezone for date aggregation. Defaults to "UTC"
bound_to_timeframe (optional): Whether to align start/end dates to timeframe boundaries. Defaults to true
metric (optional): Filter to return only specific metric - "total_requests", "successful_requests", "failed_requests", or "avg_latency_ms"
cursor (optional): Pagination cursor from previous response
limit (optional): Maximum number of items to return

Example:

{
  "endpoint_ids": ["fal-ai/flux/dev"],
  "start": "2025-10-01",
  "timeframe": "day"
}

Response:

{
  "time_series": [
    {
      "bucket": "2025-10-23T00:00:00+00:00",
      "results": [
        {
          "endpoint_id": "fal-ai/flux/dev",
          "request_count": 19
        }
      ]
    }
  ]
}

Usage Examples

With Claude Desktop

Once configured, you can use natural language to interact with fal.ai:

Model Discovery:

"Search for active flux models"

"Find the model details for fal-ai/flux/dev"

Pricing & Cost Management:

"Get pricing information for fal-ai/flux/dev and fal-ai/flux-pro"

"Estimate the cost of generating 50 images using fal-ai/flux/dev"

"How much would 100 API calls to flux/dev cost based on historical pricing?"

Usage & Analytics:

"Show me my usage for fal-ai/nano-banana in the last 2 weeks"

"Get analytics for fal-ai/flux/dev for the past month"

"What's my total spending on flux/dev this month?"

Content Generation:

"Generate an image of a cat wearing a hat using fal-ai/flux/dev"

"Check the status of my last generation request"

"Upload this image to fal.ai CDN: /path/to/image.png"

Programmatic Usage

You can also use the server programmatically:

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
// ... server setup

Development

Prerequisites

Node.js 18 or later
npm or yarn
fal.ai API key

Setup

# Clone the repository
git clone https://github.com/derekalia/fal-mcp-ts
cd fal-mcp-ts

# Install dependencies
npm install

# Build
npm run build

# Run in development mode with watch
npm run watch

Project Structure

fal-mcp-ts/
├── src/
│   ├── index.ts           # Main server entry point
│   ├── client.ts          # Fal.ai client wrapper
│   └── tools/
│       ├── models.ts      # Model discovery tools
│       ├── generate.ts    # Generation and queue tools
│       └── storage.ts     # File upload tools
├── dist/                  # Compiled output
├── package.json
├── tsconfig.json
└── README.md

Troubleshooting

"FAL_KEY environment variable is not set"

Make sure you've set the FAL_KEY in your MCP client configuration. The API key must be set as an environment variable.

"HTTP 401" or "Unauthorized"

Your API key may be invalid or expired. Check your API key at fal.ai/dashboard/keys.

Build Errors

Try removing node_modules and reinstalling:

rm -rf node_modules package-lock.json
npm install
npm run build

Contributing

Contributions are welcome! Please feel free to submit a Pull Request.

License

MIT

Credits

This project was inspired by the Python fal MCP server and built using:

@modelcontextprotocol/sdk - MCP TypeScript SDK
@fal-ai/client - Official fal.ai TypeScript client

Available Tools

12 tools

analyticsA

Get analytics data for model endpoints with time-bucketed metrics. Returns request counts, latency statistics (avg, p50, p95, p99), and success/error rates. Requires authentication.

ParametersJSON Schema

Name	Required	Description	Default
`endpoint_ids`	Yes	Endpoint ID(s) to get analytics for (e.g., ['fal-ai/flux/dev']). Must provide at least 1, maximum 50 endpoint IDs.
`start`	No	Start date in ISO8601 format (e.g., '2025-01-01T00:00:00Z' or '2025-01-01'). Defaults to 24 hours ago.
`end`	No	End date in ISO8601 format (e.g., '2025-01-31T23:59:59Z' or '2025-01-31'). Defaults to current time.
`timezone`	No	Timezone for date aggregation (e.g., 'UTC', 'America/New_York'). Defaults to 'UTC'.	UTC
`timeframe`	No	Time bucket size for aggregation. Auto-detected from date range if not specified.
`bound_to_timeframe`	No	Whether to align start/end dates to timeframe boundaries. Defaults to true.
`metric`	No	Optional: Filter to return only specific metric in response.
`cursor`	No	Pagination cursor from previous response.
`limit`	No	Maximum number of items to return.

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions authentication and the type of data returned but does not discuss rate limits, pagination behavior, data retention, or error handling. The description is adequate but not thorough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences long, front-loads the action and resource, lists key metrics, and notes authentication. Every sentence adds value with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 9 parameters (including cursor/limit for pagination) and no output schema, the description covers the core purpose and metrics but omits mention of pagination, timezone handling, or auto-detection of timeframe. The schema fills some gaps, but the description could be more complete for a tool of this complexity.

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 coverage is 100%, so the schema documents all parameters. The description adds context about the return metrics (latency percentiles, success/error rates) but does not provide additional meaning for individual parameters beyond the schema. Baseline 3 is appropriate.

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?

The description clearly states the action ('Get analytics data'), the resource ('for model endpoints'), and specifies the returned metrics (request counts, latency statistics, success/error rates). It distinguishes itself from sibling tools like 'usage' by focusing on time-bucketed metrics and latency percentiles.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives, no exclusion criteria, and no context about prerequisites beyond authentication. The sibling tools list (e.g., 'estimate_cost', 'generate') suggests different use cases, but the description does not help the agent differentiate.

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

cancelB

Cancel a pending or processing generation request.

ParametersJSON Schema

Name	Required	Description	Default
`app_id`	Yes	The model application ID
`request_id`	Yes	The request_id to cancel

TDQS

B3.4/5.0

Behavior2/5

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

No annotations provided, and the description fails to disclose behavioral traits such as whether cancellation is reversible, immediate, or requires specific permissions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with clear action and object; efficient but could include context without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a simple tool with 2 required params, but lacks explanation of 'pending or processing' meaning or cancellation behavior, and no output schema or annotations compensate.

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 covers both parameters with descriptions, so baseline is 3; the description adds no additional meaning beyond what schema already provides.

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?

The description uses a specific verb 'cancel' and clearly identifies the resource as 'generation request', differentiating it from sibling tools like 'generate' or 'status'.

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?

No explicit guidance on when to use versus alternatives like 'status' to check request state before canceling; the context is implied but not stated.

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

estimate_costC

Estimate costs for model operations using historical API pricing or unit pricing. Requires authentication. Useful for budget planning and cost optimization.

ParametersJSON Schema

Name	Required	Description	Default
`estimate_type`	Yes	Estimation method: 'historical_api_price' (based on API call history) or 'unit_price' (based on billing units like images/videos)
`endpoints`	Yes	Map of endpoint IDs to quantities. For 'historical_api_price': use {endpoint_id: {call_quantity: number}}. For 'unit_price': use {endpoint_id: {unit_quantity: number}}

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It only discloses that authentication is needed. It does not mention whether the tool is read-only, destructive, rate limits, or other side effects. More behavioral context is needed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, front-loaded with the purpose, and contains no fluff. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having nested objects and an enum, the description does not explain the output/return value, which is critical for a cost estimation tool. It also lacks examples or usage scenarios. For the complexity, this is incomplete.

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 coverage is 100%, so the baseline is 3. The description adds minimal extra meaning beyond the schema (e.g., 'Requires authentication' is not parameter-specific). It restates the enum values but does not explain the return format or constraints.

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 description clearly states the verb 'estimate' and the resource 'costs for model operations', and provides context for budget planning. However, it does not explicitly differentiate from sibling tools like 'pricing' or 'usage', which might also involve cost estimation.

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

Usage Guidelines2/5

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

The description mentions 'Requires authentication' but gives no guidance on when to use this tool versus alternatives (e.g., when to use 'pricing' instead). No explicit when-not-to-use or alternative tool names are provided.

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

findA

Find specific model(s) by endpoint ID. Can retrieve single or multiple models (1-50). Useful for looking up exact models by their stable identifiers.

ParametersJSON Schema

Name	Required	Description	Default
`endpoint_ids`	Yes	Endpoint ID(s) to retrieve (e.g., ['fal-ai/flux/dev', 'fal-ai/flux-pro']). Can specify 1-50 models.
`expand`	No	Fields to expand in response. Supported: 'openapi-3.0' (includes full OpenAPI schema)

TDQS

A4.1/5.0

Behavior3/5

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

With no annotations, the description covers the retrieval nature and batch size (1-50), but lacks details on error handling, authorization requirements, or rate limits. It's adequate for a simple read tool but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no extraneous information; the key purpose and constraint are presented upfront, achieving high efficiency.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Without an output schema, the description does not explain the response structure (e.g., model details, pagination). For a retrieval tool, this leaves a gap in completeness, though siblings like 'search' might offer more context.

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?

The schema covers both parameters fully (100% coverage), but the description adds value by specifying the allowed range (1-50) for endpoint_ids and providing an example format, going beyond the schema alone.

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?

The description clearly states the tool retrieves models by endpoint ID, distinguishes from fuzzy search by emphasizing 'exact models' and 'stable identifiers', and specifies the range of 1-50 models.

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?

The description indicates use for exact lookup via endpoint IDs ('Useful for looking up exact models'), but does not explicitly contrast with sibling tools like 'search' or 'models' for alternative usage.

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

generateC

Submit a generation request to a fal.ai model. This queues the request and returns immediately with a request_id for tracking.

ParametersJSON Schema

Name	Required	Description	Default
`app_id`	Yes	The model application ID (e.g., 'fal-ai/flux/dev')
`input_data`	Yes	Dictionary of input parameters for the model (model-specific)
`webhook_url`	No	Optional webhook URL for result notification
`output_format`	No	Output format (default: 'json')	json

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It only mentions queueing and returning a request_id. It omits important details like authentication needs, rate limits, potential delays, cost implications, or how to handle failures. The sibling 'estimate_cost' suggests cost context could be relevant.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences with no wasted words. It front-loads the purpose and key behavior (queueing, immediate return, request_id).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an async AI generation tool with no output schema and no annotations, the description is too brief. It fails to explain how to use the returned request_id (e.g., with status or result tools), what happens on failure, or any validation constraints. The complexity of the operation demands more context for a correct invocation.

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 baseline is 3. The description adds no additional meaning beyond what the schema already provides for parameters like app_id, input_data, webhook_url, and output_format. The description's mention of 'request_id' concerns the return, not parameters.

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 description clearly states the verb 'Submit' and the resource 'generation request to a fal.ai model', and explains that it queues the request and returns a request_id. However, it does not explicitly differentiate from sibling tools like 'search' or 'find', though the purpose is distinct enough.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus its siblings (e.g., cancel, status, result). It lacks prerequisites, alternatives, or context about the async workflow.

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

modelsA

List available models in the fal.ai model gallery. Supports optional filtering by category, status, and cursor-based pagination. Can expand OpenAPI schemas inline with expand parameter.

ParametersJSON Schema

Name	Required	Description
`category`	No	Optional category to filter models (e.g., 'text-to-image', 'image-to-video', 'training')
`cursor`	No	Pagination cursor from previous response (for next page)
`limit`	No	Number of models per page (default: 100, max: 100)
`status`	No	Filter by model status - 'active' or 'deprecated' (omit to include all)
`expand`	No	Fields to expand in response. Supported: 'openapi-3.0' (includes full OpenAPI schema)

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses read-only behavior (listing) and optional filtering but lacks details on authentication, rate limits, or what happens if no models match. The behavior is straightforward but minimally transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, using two sentences to cover purpose and key capabilities without any unnecessary words. Every sentence is valuable.

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?

Given no output schema and no annotations, the description covers the essential purpose, supported filters, pagination, and expand option. It could mention output format or pagination details, but the schema handles cursor and limit. Mostly complete for a list tool.

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%, with clear descriptions for all five parameters. The description adds little beyond summarizing the expand parameter capability, so it meets the baseline for high coverage but does not significantly enhance understanding.

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?

Description clearly states the tool lists models in the fal.ai gallery, distinguishing it from siblings like 'search' or 'generate' by focusing on browsing the full list. The verb 'list' is specific and the resource 'models' is clear.

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 description implies usage for listing models with optional filters, but does not explicitly state when to use this tool versus siblings like 'search' or 'find'. No exclusions or alternatives are mentioned.

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

pricingB

Get pricing information for specific model endpoint(s). Returns unit pricing with currency. Requires authentication. Most models use output-based pricing (per image/video).

ParametersJSON Schema

Name	Required	Description	Default
`endpoint_ids`	Yes	Endpoint ID(s) to get pricing for (e.g., ['fal-ai/flux/dev']). Must provide at least 1 endpoint ID (1-50 models).
`cursor`	No	Pagination cursor from previous response (for next page)

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations provided, the description bears full responsibility. It discloses authentication requirement and notes that most models use output-based pricing, which adds behavioral context. However, it lacks details on rate limits, pagination behavior beyond cursor, or any side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise with four short sentences. The key verb 'Get' is front-loaded, and every sentence contributes meaning without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While adequate for a simple read tool, the description lacks details on the return format or structure (e.g., what keys are in the response). Since there is no output schema, the agent may need more information to process the result correctly.

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 description coverage is 100%, and the description adds value by clarifying constraints: 'Must provide at least 1 endpoint ID (1-50 models)' and 'for next page' on cursor. This goes beyond the schema's basic descriptions.

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 description clearly states the tool retrieves pricing information for model endpoints, including unit pricing and currency. It distinguishes itself from sibling tools like 'estimate_cost' and 'usage' by focusing on endpoint-specific pricing. However, it could be more specific about the exact fields returned.

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

Usage Guidelines2/5

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

The description mentions authentication is required but provides no guidance on when to use this tool versus alternatives like 'estimate_cost' or 'usage'. There is no mention of when-not-to-use or context for selection.

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

resultB

Get the result of a generation request.

ParametersJSON Schema

Name	Required	Description	Default
`app_id`	Yes	The model application ID used for generation
`request_id`	Yes	The request_id returned from generate()

TDQS

B3.4/5.0

Behavior2/5

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

No annotations provided. The description does not disclose whether the operation is read-only, what happens if the request is still processing, or any other behavioral constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, no redundant information. Highly concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Missing output schema; description does not indicate what the result contains or how it relates to the generation lifecycle. Sibling tools suggest a workflow but description lacks this context.

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 baseline is 3. The description adds no additional meaning beyond the schema descriptions.

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?

The description uses a specific verb ('Get') and resource ('result of a generation request'), clearly distinguishing from siblings like generate (starts a request) and cancel (cancels).

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 description implies usage after a generation request (requires request_id from generate), but does not explicitly state when to use this tool vs alternatives or prerequisites.

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

searchA

Search for models in the fal.ai gallery using free-text query across name, description, and category. Supports filtering and cursor-based pagination.

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Free-text search query (searches name, description, category)
`cursor`	No	Pagination cursor from previous response (for next page)
`limit`	No	Number of results per page (default: 50, max: 100)
`category`	No	Optional category to filter results (e.g., 'text-to-image', 'image-to-video')
`status`	No	Filter by model status - 'active' or 'deprecated' (omit to include all)
`expand`	No	Fields to expand in response. Supported: 'openapi-3.0' (includes full OpenAPI schema)

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It discloses that the tool supports filtering and cursor-based pagination, which are key behaviors. However, it omits details like rate limits or data freshness, but the provided info is sufficient for a search tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: first sentence defines purpose, second adds features. No redundant words. Front-loads key information. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 6 parameters and no output schema, the description could explain the return format (e.g., list of models with pagination metadata). It mentions cursor-based pagination but does not describe the response structure. Adequate but leaves gaps for a fully autonomous agent.

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 coverage is 100%, so baseline is 3. The description adds little beyond the schema: it restates that query searches name, description, and category (already in schema) and mentions filtering/pagination (already implied by parameters). No additional semantic value.

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?

The description clearly states the tool's purpose: 'Search for models in the fal.ai gallery using free-text query across name, description, and category.' This is a specific verb ('Search') and resource ('models'), and it differentiates from siblings like 'find' or 'models' by detailing the search scope.

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 description implies usage for searching models with free-text and filtering, but it does not explicitly state when to use this tool versus alternatives (e.g., 'find' or 'models'). No exclusions or prerequisites are mentioned, so guidance is minimal.

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

statusA

Check the status of a generation request without fetching full results.

ParametersJSON Schema

Name	Required	Description	Default
`app_id`	Yes	The model application ID
`request_id`	Yes	The request_id to check

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description bears full responsibility. It indicates a read-only operation, but does not disclose additional behaviors like error handling or whether the request must be owned by the user. More detail would be beneficial.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, tightly focused sentence with no extraneous words. Every part adds value, making it highly concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description does not explain return values or possible status codes. Although the tool is simple, this omission limits an agent's understanding of how to interpret the response.

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 coverage is 100%, so the schema already documents both parameters. The description adds no additional semantic meaning beyond what the schema provides, so a baseline score of 3 is appropriate.

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?

The description uses a specific verb ('Check') and resource ('status of a generation request'), and explicitly distinguishes from 'result' tool by noting 'without fetching full results'.

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?

The description implies this tool is for lightweight status checks, contrasting with full result retrieval. However, it does not explicitly name alternatives or provide when-not-to-use guidance.

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

uploadA

Upload a file to fal.ai CDN for use with models. Returns a URL that can be used as input to generation requests.

ParametersJSON Schema

Name	Required	Description	Default
`file_path`	Yes	Path to the file to upload
`content_type`	No	Optional MIME type (auto-detected if not provided)

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It discloses the basic action (upload) and return value (URL), but lacks details on file persistence, size limits, authentication, or error scenarios.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences that are direct and front-loaded with the core action. Every word adds value, with no redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description covers the basic input/output but omits important context such as file size limits, whether the URL is temporary, and error handling. It is adequate but not fully comprehensive.

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%, with both parameters already documented. The description does not add new meaning beyond the schema. It confirms the purpose of file_path and notes auto-detection for content_type, but no additional constraints or examples.

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?

The description clearly states the action ('Upload a file'), the target ('fal.ai CDN'), and the purpose ('for use with models'). It distinguishes itself from sibling tools by being the only upload-focused tool.

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?

The description provides clear context on when to use this tool (to upload files for model inputs) and what the return value is (a URL for generation requests). However, it does not explicitly mention when not to use it or alternatives.

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

usageB

Get usage records for workspace with detailed billing information. Returns time series data and/or summary statistics with unit quantities and prices. Requires authentication.

ParametersJSON Schema

Name	Required	Description	Default
`endpoint_ids`	Yes	Endpoint ID(s) to get usage for (e.g., ['fal-ai/flux/dev']). Must provide at least 1 endpoint ID (1-50 models).
`start`	No	Start date in ISO8601 format (e.g., '2025-01-01T00:00:00Z' or '2025-01-01'). Defaults to 24 hours ago.
`end`	No	End date in ISO8601 format (e.g., '2025-01-31T23:59:59Z' or '2025-01-31'). Defaults to current time.
`timezone`	No	Timezone for date aggregation (e.g., 'UTC', 'America/New_York'). Defaults to 'UTC'.	UTC
`timeframe`	No	Aggregation timeframe for timeseries data. Auto-detected from date range if not specified.
`bound_to_timeframe`	No	Whether to align start/end dates to timeframe boundaries. Defaults to true.
`expand`	No	Data to include: 'time_series' for time-bucketed data, 'summary' for aggregates, 'auth_method' for auth tracking. Defaults to ['time_series'].
`cursor`	No	Pagination cursor from previous response.
`limit`	No	Maximum number of items to return.

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden. It only notes authentication requirement. There is no mention of rate limits, idempotency, pagination behavior, or data freshness. The return types are described but not in detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences and contains only essential information. It starts with the action and resource, then adds key return details. No redundant or irrelevant text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description should explain return values more thoroughly. It mentions time series and summary statistics but lacks specifics on structure or pagination. For a tool with 9 parameters, this is adequate but not comprehensive.

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 baseline is 3. The description adds no additional meaning beyond what the schema already provides for parameters like 'endpoint_ids' or 'expand'. It does not explain parameter interactions or edge cases.

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?

The description clearly states the tool retrieves usage records with billing information, specifying verb 'Get', resource 'usage records', and additional context about time series and summary data. This distinctly communicates the tool's function and differentiates it from siblings like 'pricing' or 'analytics'.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives such as 'analytics' or 'pricing'. It does not mention any prerequisites, exclusions, or scenarios where this tool is preferred, leaving the agent without decision support.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

12 tool updatesv2.1.4Jun 15, 2026
- First observedanalytics
- First observedcancel
- First observedestimate_cost
- First observedfind
- First observedgenerate
- First observedmodels
- First observedpricing
- First observedresult
- First observedsearch
- First observedstatus
- First observedupload
- First observedusage

Deploy Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Scored 2026-06-15 02:46 across 12 tools

Disambiguation5/5

Each tool targets a distinct operation or resource, such as generation, status checking, cost estimation, model search, and usage analytics. There is no overlap in purpose, and even related tools like 'find' and 'search' or 'status' and 'result' are clearly differentiated.

Naming Consistency3/5

Tool names mix verbs (cancel, find, generate, search, upload) and nouns (analytics, models, pricing, result, status, usage). While all are lowercase single words or underscore-separated, the lack of a consistent verb-noun pattern reduces predictability.

Tool Count5/5

With 12 tools, the server covers the key interactions for a model inference platform without being bloated. Each tool serves a clear purpose, from generation to analytics, making the surface well-scoped.

Completeness4/5

The set covers generation, result retrieval, cancellation, model discovery, cost estimation, usage tracking, and file uploads. Minor gaps exist, such as missing direct model deployment or detailed model metadata endpoints, but core workflows are supported.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

Writingmate MCPOAuth
ai.writingmate
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
AI & Machine Learning Image & Video Processing
1
SandBase
io.github.sandbaseai
Connect MCP clients to 2,000+ AI models without managing provider API keys.
AI & Machine Learning Agent Orchestration
1116
dora-mcp AOAuth
io.github.Saga-Labs
Multi-model AI image and video generator. 14 models behind one OAuth-secured MCP endpoint.
AI & Machine Learning Image & Video Processing
42
Workflow A
io.github.Jonnyton
Create, browse, remix, collaborate on, and run durable AI workflow nodes from MCP hosts.
Autonomous Agents App Automation Workplace & Productivity
21

Related MCP Servers

Fal.ai MCP Server
Image & Video Processing Audio Processing Text-to-Speech
luminarylane
A
license
A
quality
D
maintenance
Enables Claude Desktop and other MCP clients to generate images, videos, music, and audio using Fal.ai models. Supports text-to-image generation, video creation, music composition, text-to-speech, audio transcription, and image enhancement through natural language prompts.
Updated 4 months ago (2026-05-04 07:32 UTC)
18
52
MIT
fal.ai MCP Server
Cloud Platforms
M1Vision
A
license
Not graded
quality
D
maintenance
Enables interaction with fal.ai AI models through MCP, supporting model discovery, content generation, queue management, and file uploads to the fal.ai platform.
Updated 10 months ago (2025-11-10 17:28 UTC)
MIT
fal.ai MCP Server
enescanguven
A
license
Not graded
quality
D
maintenance
Provides access to over 600 AI models on fal.ai for generating and editing images, videos, music, and speech directly within Claude. It supports high-performance models like FLUX, Kling, and Whisper for various creative and analytical tasks.
Updated 6 months ago (2026-03-07 03:38 UTC)
595
1
MIT
falai-mcp-server
AI & Machine Learning Developer Tools
berkbirkan
A
license
Not graded
quality
D
maintenance
A FastMCP server that exposes core fal.ai model API operations, enabling model catalogue browsing, search, schema retrieval, inference, queue management, and CDN uploads through natural language.
Updated a year ago (2025-10-07 17:18 UTC)
4
MIT

fal.ai MCP Server

Features

Installation

Via npm (Recommended)

From Source

Configuration

Get Your API Key

Configure MCP Client

Claude Desktop

Claude Code

Cursor

Other MCP Clients

Available Tools

models

search

find

schema

generate

result

status

cancel

upload

pricing

estimate_cost

usage

analytics

Usage Examples

With Claude Desktop

Programmatic Usage

Development

Prerequisites

Setup

Project Structure

Troubleshooting

"FAL_KEY environment variable is not set"

"HTTP 401" or "Unauthorized"

Build Errors

Contributing

License

Credits

Links

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

`models`

`search`

`find`

`schema`

`generate`

`result`

`status`

`cancel`

`upload`

`pricing`

`estimate_cost`

`usage`

`analytics`