Provides access to Fal.ai's image generation platform with 600+ AI models including Flux and Stable Diffusion, enabling image generation, workflow execution, and real-time progress tracking for AI-powered visual content creation.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Fal.ai MCP Server generate a cyberpunk cityscape with neon lights using flux"
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.
An MCP (Model Context Protocol) server that provides seamless integration with Fal.ai's image generation models and workflows.
🎨 Image Generation - Access 600+ Fal.ai models including Flux, Stable Diffusion, and more
🔄 Workflow Support - Run pre-built pipelines like sdxl-sticker
🚀 Streaming - Real-time progress updates for long-running operations
📦 Simple API - Unified interface for all models and workflows
⚡ Queue Management - Built-in status tracking for async operations
Related MCP server: fal.ai MCP Server
npm install -g fal-mcp-servergit clone https://github.com/yourusername/fal-mcp-server.git
cd fal-mcp-server
npm install
npm run build
npm linkSign up at fal.ai and get your API key from the dashboard.
claude mcp add fal --env "FAL_KEY=your-api-key-here" -- npx -y fal-mcp-serverclaude mcp listYou should see:
fal: npx -y fal-mcp-server - ✓ Connectedgenerate_imageGenerate images using any Fal.ai model.
Parameters:
prompt (required): Text description of the image
model: Model ID (default: "fal-ai/flux/schnell")
image_size: "square", "landscape_4_3", or "portrait_3_4"
num_images: 1-4 images
seed: For reproducible generation
Example:
{
"prompt": "a cyberpunk cat in neon city",
"model": "fal-ai/flux/dev",
"image_size": "landscape_4_3",
"num_images": 2
}run_modelRun any Fal.ai model with custom parameters.
Parameters:
model_id (required): The model endpoint ID
input (required): Model-specific input parameters
stream: Enable streaming for real-time updates
Example:
{
"model_id": "fal-ai/stable-diffusion-v3-medium",
"input": {
"prompt": "professional portrait photo",
"negative_prompt": "low quality, blurry"
}
}run_workflowExecute Fal.ai workflows (multi-step pipelines).
Parameters:
workflow_id (required): The workflow ID
input (required): Workflow input parameters
stream: Stream workflow events
Example:
{
"workflow_id": "workflows/fal-ai/sdxl-sticker",
"input": {
"prompt": "cute puppy mascot"
}
}list_popular_modelsGet a list of popular Fal.ai models.
check_statusCheck the status of an async request.
Parameters:
request_id (required): The request ID to check
fal-ai/flux/schnell - Fastest Flux model (4 steps)
fal-ai/flux/dev - High quality Flux model
fal-ai/flux-pro - Professional Flux model
fal-ai/fast-sdxl - Fast Stable Diffusion XL
fal-ai/stable-diffusion-v3-medium - Latest SD3
fal-ai/recraft-v3 - Artistic style generation
workflows/fal-ai/sdxl-sticker - Generate → Remove BG → Sticker
Once installed, you can use natural language to interact with Fal.ai:
"Generate a cyberpunk cityscape using Flux"
"Create a sticker of a cute robot"
"Run the sdxl-sticker workflow with a puppy prompt"
"List available image models"
FAL_KEY (required): Your Fal.ai API key
# Install dependencies
npm install
# Build TypeScript
npm run build
# Watch mode for development
npm run watch
# Run locally
FAL_KEY=your-key node dist/index.jsMIT
Contributions welcome! Please submit PRs to improve the server.
Check the status of a Fal.ai request
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | Yes | The request ID to check |
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 states the tool checks status but doesn't explain what 'status' entails (e.g., pending, completed, failed), whether it's a read-only operation, potential rate limits, or error handling. This leaves significant gaps for an agent to understand how to use it effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that efficiently conveys the core purpose without unnecessary words. It is front-loaded with the essential information, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't cover what the tool returns (e.g., status details, error messages), behavioral aspects like idempotency or side effects, or how it integrates with sibling tools. For a status-checking tool in a workflow context, this leaves critical information missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'request_id' parameter clearly documented. The description adds no additional meaning beyond this, such as format examples or context about where to obtain the request ID. Given the high schema coverage, a baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Check') and the resource ('status of a Fal.ai request'), making the purpose understandable. However, it doesn't differentiate this tool from potential siblings like 'run_model' or 'run_workflow' that might also involve status checking, leaving room for ambiguity in a multi-tool context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention prerequisites (e.g., needing a request ID from another operation), exclusions, or how it relates to sibling tools like 'run_model', which might handle status as part of its execution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an image using Fal.ai models like Flux or Stable Diffusion
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Text description of the image to generate | |
| model | No | Model to use (default: fal-ai/flux/schnell) | fal-ai/flux/schnell |
| image_size | No | Image size preset | landscape_4_3 |
| num_images | No | Number of images to generate (1-4) | |
| seed | No | Seed for reproducible generation |
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 using Fal.ai models but doesn't describe what happens during generation (e.g., processing time, cost implications, rate limits, authentication needs, or what happens if generation fails). For a tool that likely involves external API calls and resource consumption, this is a significant gap in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized for a tool with good schema documentation. However, it could be slightly more structured by front-loading the core purpose more explicitly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an image generation tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (image data, URLs, metadata), doesn't mention potential costs or limitations, and provides minimal behavioral context. Given the complexity of image generation and lack of structured metadata, the description should do more to help agents understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 5 parameters thoroughly with descriptions, defaults, and constraints. The description adds no additional parameter semantics beyond what's in the schema. The baseline score of 3 is appropriate when the schema does all the parameter documentation work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'generate' and resource 'image', specifying it uses Fal.ai models like Flux or Stable Diffusion. It distinguishes from siblings like 'check_status' or 'list_popular_models' by focusing on image generation rather than status checking or listing. However, it doesn't explicitly differentiate from 'run_model' which might also generate images, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'run_model' or 'run_workflow'. It mentions specific models (Flux, Stable Diffusion) but doesn't explain why to choose this tool over others for image generation tasks. There are no explicit when/when-not instructions or prerequisites stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List popular Fal.ai models for image generation
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 states it's a list operation, implying read-only behavior, but doesn't cover aspects like rate limits, authentication needs, pagination, or what 'popular' means (e.g., by usage, ratings). This leaves gaps in understanding how the tool behaves beyond basic listing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without any wasted words. It's appropriately sized for a simple tool with no parameters, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks context on usage, behavioral traits, or output format, which could help an agent use it more effectively in a workflow with siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here, earning a baseline score of 4 for not introducing unnecessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('popular Fal.ai models for image generation'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its siblings like 'run_model' or 'generate_image', which might also involve models, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context (e.g., before selecting a model for generation), or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run any Fal.ai model with custom parameters
| Name | Required | Description | Default |
|---|---|---|---|
| model_id | Yes | The Fal.ai model endpoint ID | |
| input | Yes | Input parameters for the model | |
| stream | No | Whether to stream results |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't mention critical aspects like authentication requirements, rate limits, error handling, or whether this is a synchronous/asynchronous operation. The mention of 'custom parameters' is vague about constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 8 words with zero wasted language. It's front-loaded with the core purpose and efficiently communicates the essential function without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, no output schema, and nested objects in the input, the description is insufficient. It doesn't explain what kind of response to expect, error conditions, or important behavioral aspects needed for proper tool invocation in a complex AI model execution context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 three parameters thoroughly. The description adds minimal value beyond what's in the schema - it mentions 'custom parameters' which aligns with the 'input' parameter but doesn't provide additional context about parameter formats or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Run') and resource ('any Fal.ai model'), specifying it's for models with custom parameters. However, it doesn't distinguish this from sibling tools like 'run_workflow' or 'generate_image', which might have overlapping purposes in the same AI platform context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'run_workflow' or 'generate_image'. It mentions 'any Fal.ai model' but doesn't clarify if this is the primary tool for model execution or when other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a Fal.ai workflow (e.g., sdxl-sticker pipeline)
| Name | Required | Description | Default |
|---|---|---|---|
| workflow_id | Yes | The workflow ID | |
| input | Yes | Input parameters for the workflow | |
| stream | No | Whether to stream workflow events |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Run') but doesn't mention whether this is a read or write operation, what permissions are needed, if it's rate-limited, or what happens upon execution (e.g., asynchronous processing, costs). The example adds some context but lacks critical behavioral details for a tool with potential 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose with a clarifying example. There's no wasted verbiage or redundant information, making it easy for an agent to parse quickly and understand the tool's intent without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of running a workflow (likely involving asynchronous execution, side effects, or costs), the lack of annotations and output schema means the description should do more. It doesn't cover behavioral aspects like error handling, response format, or dependencies, leaving significant gaps for an agent to use this tool effectively in context with its siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the three parameters. The description doesn't add any semantic details beyond what's in the schema—it doesn't explain what a 'workflow ID' entails, what typical 'input parameters' might be, or when to use 'stream'. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Run') and resource ('a Fal.ai workflow'), with a specific example ('sdxl-sticker pipeline') that helps illustrate the type of workflow. However, it doesn't explicitly differentiate this tool from sibling tools like 'run_model' or 'generate_image', which might have overlapping functionality in AI image generation contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'run_model' or 'generate_image'. It mentions an example workflow but doesn't specify prerequisites, constraints, or scenarios where this tool is preferred over siblings, leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The tools have some overlap that could cause confusion, particularly between 'generate_image', 'run_model', and 'run_workflow'. While 'generate_image' is specific to image generation models, 'run_model' is a generic version that could handle the same task, and 'run_workflow' might also involve image generation. However, the descriptions provide enough context to differentiate them in most cases.
The naming follows a consistent verb_noun pattern with snake_case throughout (e.g., check_status, generate_image, list_popular_models). The only minor deviation is that 'run_model' and 'run_workflow' use 'run' while others use more specific verbs like 'check' or 'generate', but this is still readable and logical.
With 5 tools, this server is well-scoped for interacting with Fal.ai services. Each tool serves a distinct purpose in the workflow, from checking status and listing models to generating images and running custom models or workflows, making the count appropriate and efficient.
The toolset covers core operations for Fal.ai, including status checks, model listing, image generation, and running custom models or workflows. A minor gap is the lack of tools for managing or deleting requests, but agents can likely work around this given the server's focus on execution and monitoring.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Image, video, music and text generation across 100+ models through one endpoint.
One API for 100+ AI video, image, music and speech models.
Best Image and video generation: 20+ models (Kling, Seedance, Veo, NB, FLUX.2), OAuth, pay-per-use.
Generate images, video, music, voice and 3D through one API. 30 tools, 200+ models.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/gravicity-archive/fal-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
