Skip to main content
Glama
Sign In
fal.ai MCP Server

fal.ai MCP Server

by thenavidm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Read queue status once

get_job_status
Read-onlyIdempotent

Retrieve the status of a fal.ai generation job using its model and request IDs. One-time read; no polling or resubmission.

Instructions

One read using the SDK-compatible owner/app root, not the full model subpath. No auto-polling, paid re-submission or arbitrary status URL.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "model_id": "<model_id>",
      "request_id": "<request_id>"
    },
    "name": "get_job_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
logsNoInclude native provider logs only when requested.
accountNoExact configured isolated API-key profile label.
model_idYesExact current catalog endpoint ID. Never guess model names or parameter mappings.
request_idYesExact queue receipt ID; status/result/cancel use its owner/app root, without inference subpaths.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

B3.3/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely new behavior: this is a one-shot read with no automatic polling, it does not trigger a paid re-submission, and it will not fetch an arbitrary status URL. Those cost/side-effect disclosures go beyond the annotations, though the response shape and failure modes remain unstated.

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?

Two tight sentences with the core constraint (one read, no polling) front-loaded and no filler. The compression is aggressive enough that the implementation jargon slightly obscures rather than clarifies, but nothing is wasted.

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?

With no output schema, the description should carry the burden of explaining what a status read returns (queued/running/succeeded/failed) and any throttling expectations for repeated calls; it does not. It covers scope and side effects well but leaves the agent guessing about the payload it will receive.

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 model_id, request_id, account and logs are already documented in the schema; that sets the baseline at 3. The 'owner/app root, not the full model subpath' clause adds a little context on how request_id/model_id are interpreted, but it is not a material gain over the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The title plus 'One read' conveys that this is a single status fetch, and the negatives (no polling, no paid re-submission, no arbitrary URL) hint it is not submit_job or get_job_result. However, the description never plainly states 'returns the queue status of a previously submitted request_id'; it leans on jargon like 'SDK-compatible owner/app root' and 'full model subpath' that an agent must decode.

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 auto-polling' implies the agent must re-call this itself to track progress, which is real usage guidance, and 'no paid re-submission' warns against using it as a resubmit path. It never names the alternatives (get_job_result, cancel_job) or states when status-checking is appropriate versus fetching a result, so guidance remains implied rather than explicit.

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