Skip to main content
Glama
thenavidm

fal.ai MCP Server

by thenavidm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Model search

search_models
Read-onlyIdempotent

Find, list, or filter fal.ai model endpoints by ID, category, status, or keyword; expand OpenAPI schemas or enterprise readiness for integration.

Instructions

Unified endpoint for discovering model endpoints. Supports three usage modes:

1. List Mode (no parameters): Paginated list of all available model endpoints with minimal metadata.

2. Find Mode (endpoint_id parameter): Retrieve specific model endpoint(s) by ID. Supports single or multiple IDs.

3. Search Mode (search parameters): Filter models by free-text query, category, or status.

Expansion: Use expand to include additional data in each model object:

  • openapi-3.0 — full OpenAPI 3.0 schema in the openapi field

  • enterprise_status — enterprise readiness status (ready or pending) in the enterprise_status field

Examples of endpoint_id values:

  • fal-ai/flux/dev

  • fal-ai/wan/v2.2-a14b/text-to-video

  • fal-ai/minimax/video-01/image-to-video

  • fal-ai/hunyuan3d-v21

See fal.ai Model APIs for more details.

Authentication: Optional. Providing an API key grants higher rate limits.

Common Use Cases:

  • Browse available models for integration

  • Retrieve metadata for specific endpoints

  • Search for models by category or keywords

  • Get OpenAPI schemas for code generation

  • Build model selection interfaces

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNoFree-text search query to filter models by name, description, or category
limitNoMaximum number of items to return. Actual maximum depends on query type and expansion parameters.
cursorNoPagination cursor from previous response. Encodes the page number.
expandNoFields to expand in the response. Supported values: 'openapi-3.0' (includes full OpenAPI 3.0 schema in 'openapi' field), 'enterprise_status' (includes enterprise readiness status)
statusNoFilter models by status - omit to include all statuses
accountNoExact private account key profile label, not an authenticated provider owner ID.
categoryNoFilter by category (e.g., 'text-to-image', 'image-to-video', 'training')
endpoint_idNoEndpoint ID(s) to retrieve (e.g., 'fal-ai/flux/dev'). Can be a single value or multiple values (1-50 models). When combined with search params, narrows results to these IDs. Use array syntax: ?endpoint_id=model1&endpoint_id=model2

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, open-world behavior, so the bar is lower. The description adds real value beyond them: optional API key for higher rate limits, cursor-based pagination, and how `limit` interacts with query/expansion. It does not describe what happens on invalid IDs or the error model.

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?

Front-loaded with the three modes, which is exactly the right ordering, and headings make it scannable. It loses a point for mild redundancy against the schema (expansion values, endpoint_id examples appear twice) and a 'Common Use Cases' block that is largely restatement.

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, the description does enough by describing the paginated list shape, minimal metadata, and the expanded fields. Missing pieces are return-value details for find/search modes and error behavior, but for a read-only discovery endpoint this is close to complete.

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 baseline is 3, but the description goes beyond it with concrete `endpoint_id` examples, the 1-50 array limit, the interaction between `endpoint_id` and search params, and the expansion field semantics. It edges above baseline by adding mode-based interpretation the schema does not spell out.

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 gives a specific verb+resource ("discovering model endpoints") and enumerates three distinct operating modes, so an agent immediately understands the tool's surface. It falls short of a 5 because it never differentiates itself from the sibling `get_model_info`, which plausibly overlaps with the 'Find Mode' by ID.

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?

Usage is genuinely mapped to parameters: no params = list, `endpoint_id` = find, search params = filter. It also notes `expand` conditions and auth context. However, it names no alternative tool (e.g., `get_model_info` or `run_model`) so the agent has no cross-tool routing guidance.

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