Floniks MCP Server: Use AI Creation from Claude and Any AI Agent

For most of the last year, "AI creation" has meant a human sitting in front of a canvas, typing prompts and clicking generate. That's a good experience, and we've spent a lot of time making Floniks great at it. But it's not where the world is heading. Increasingly, the thing asking for an image isn't a person — it's an agent. A Claude session planning a launch. A script that turns a blog post into social assets. A multi-step pipeline that storyboards a scene and renders every shot. Those callers don't want a UI. They want tools.

So we built one. Floniks now ships a Model Context Protocol (MCP) server that lets Claude Desktop — or any MCP-compatible client — call our creation capabilities directly. Not a single wrapped model, but the whole platform: single-step generation, multi-step workflows, saved characters, credit checks, and result retrieval. If you've read introducing Floniks, this is the part of that vision where creation stops being something you click through and becomes something you delegate.

What MCP actually gives you

The Model Context Protocol is a small, open standard for connecting AI agents to external systems through structured tools. Instead of teaching an agent to scrape your web UI or hand-roll HTTP calls, you expose a set of named tools with typed inputs and outputs, and the agent decides when to call them. The agent gets a menu; you keep control of the kitchen.

For Floniks, that menu is the creation platform itself. An agent connected to our MCP server can discover what models exist, generate a still or a clip, run a saved pipeline, poll for the result, and check how many credits it has left — all without a human stitching the steps together. The same node graph you'd build by hand in the workflow editor becomes something an agent can author and execute on its own.

The tools we expose

We kept the tool surface close to how the product already works, so there's no impedance mismatch between what you do in the UI and what an agent can do programmatically. The representative tools fall into a few groups.

Single-step generation. single_task is the agent-callable version of the AI Image and AI Video pages — one-shot text_to_image, image_to_image, image_to_video, or text_to_video. get_task polls a running job and returns its status and output URLs when it's done.

Workflows. list_workflows, get_workflow, create_workflow, and update_workflow let an agent inspect and edit the node-based DAGs that power Pro mode. execute_workflow runs one. And generate_workflow is the interesting one: hand it a natural-language description and it returns a workflow graph — an agent can effectively design a pipeline from a sentence and then run it.

Discovery and metadata. list_models, list_model_aliases, and get_model_params tell an agent what's available and what parameters each model accepts, so it can construct valid requests instead of guessing. list_templates surfaces our preset pipelines as starting points.

Assets and account. list_creations pulls back previous outputs. list_characters exposes saved characters for reuse across generations — the same consistency primitive we wrote about in inside the workflow editor. And get_credit_balance lets an agent check it can afford a job before kicking one off.

The important design choice here: these aren't a parallel, watered-down API. They're the same capabilities the product runs on, exposed as machine-callable tools with structured outputs.

A realistic agent loop

The cleanest way to understand the server is to trace what an agent actually does. Say a Claude session has been asked to produce a hero image for a feature announcement. Conceptually, the loop looks like this:

1. Discover. Call list_model_aliases to see which models are available and pick one suited to the task — a strong text_to_image model, for instance. Optionally call get_model_params to learn what aspect ratios or sizes it accepts.
2. Generate. Call single_task with task_type: text_to_image, the chosen model, and a prompt the agent composed from the announcement copy. This returns a task ID.
3. Poll. Call get_task with that ID until the status reaches a terminal state. Because generation is asynchronous, the agent waits on the job rather than blocking a request open.
4. Use the result. On success, get_task returns the output URL. The agent hands that URL back to the user, drops it into a document, or feeds it into the next step.

Notice what's missing: no browser automation, no screen-scraping, no fragile selectors. The agent reasons over typed tool results. And because we don't invent fake credentials here — authentication is handled by your Floniks account through the documented setup at MCP & developer docs — the same loop runs identically whether a person or an agent triggers it.

Chain a few of these together and the examples get more ambitious. An agent that turns a blog post into a set of social images: read the post, call single_task once per platform with sized prompts, collect the URLs. Or a Claude workflow that storyboards a script — generate_workflow to design a shot pipeline, execute_workflow to render it, get_task to gather every shot. The agent owns the orchestration; Floniks owns the generation.

Three ways in, not one

The MCP server is the headline for agent builders, but it's one of three integration paths, and they're meant to be mixed.

• The MCP server is for agents. If you're building on Claude or any MCP client, this is the native way to give your agent creation abilities.
• The REST API is for everything else — scripts, backends, cron jobs, your own product. Same capabilities, plain HTTP. If you'd rather call Floniks from a service than from an agent, this is the path.
• Public Skills package common flows as reusable units for developers who want a higher-level building block than raw tool calls.

All three are documented in one place at MCP & developer docs. You don't have to commit to one. A common shape is an agent that uses the MCP server for interactive work and a backend that uses the REST API for scheduled batch jobs, both hitting the same workflows.

Why workflows are the unit that matters

It would have been easier to ship a single generate_image tool and call it a day. We didn't, because the most valuable thing Floniks has isn't any one model — it's the composable pipeline. We've made the full argument for that in why workflows beat one-off prompts, but the short version is this: a one-off prompt is a result, while a workflow is a capability you can rerun with new inputs forever.

Exposing workflows over MCP means an agent inherits that leverage. A talking-avatar pipeline you built once in the editor — character image into image-to-video into lip-sync — becomes a single execute_workflow call an agent can make a thousand times with different scripts. The DAG you author visually and the tool an agent calls are the same object. That's the payoff of keeping the agent surface aligned with the product surface instead of building a separate, thinner API.

Reliability the agent can trust

Autonomous callers raise the stakes on failures, because there's no human watching to catch a charge for a result that never arrived. Our answer is the same one the rest of the platform runs on: if a generation fails, your credits are automatically refunded, across every failure path. An agent can call get_credit_balance to budget before it starts, and it doesn't have to defensively account for paying on failed jobs — that's handled. Structured statuses from get_task mean an agent can branch cleanly on success, failure, or still-processing, rather than parsing prose.

Built for the agent era

There's a broader bet here. As AI agents and answer engines become the front door to more of the internet, the systems that win are the ones that are machine-callable and return structured outputs — the same generative-engine-optimization (GEO) logic that applies to content applies to capabilities. A creation platform an agent can drive, with typed tools and predictable results, fits exactly where this is going. We'd rather be the tool an agent reaches for than a UI it can't use.

If you're building agents, AI engineers wiring up pipelines, or a technical creator who'd rather script your generations than click them, the MCP server is ready. Point your MCP client at Floniks, open MCP & developer docs, and let your agent make something.

Frequently Asked Questions

What is the Model Context Protocol (MCP)?

MCP is an open standard for connecting AI agents to external systems through structured, typed tools. Instead of an agent scraping a UI or hand-rolling API calls, the system exposes named tools the agent can call and reason over. Floniks ships an MCP server so any MCP-compatible client can use its creation capabilities directly.

Can Claude generate images with Floniks?

Yes. With the Floniks MCP server connected to Claude Desktop (or any MCP client), Claude can call single_task for text_to_image or image_to_image, poll with get_task, and return the output URL — generating images autonomously as part of a larger task.

What can an agent actually do through the MCP server?

An agent can discover models (list_models, list_model_aliases, get_model_params), run single-step generation (single_task), build and run multi-step pipelines (generate_workflow, create_workflow, execute_workflow), reuse saved characters (list_characters), fetch results (get_task, list_creations), and check its credit balance (get_credit_balance).

Is there an option besides MCP?

Yes. Floniks offers three integration paths: the MCP server for agents, a REST API for scripts and backends, and public Skills for higher-level reusable flows. All three share the same capabilities and are documented at MCP & developer docs.