The Flux server enables AI-driven AO tool calling and integration with existing tools and editors via an MCP server. With it, you can:
Run AO code using natural language instructions
Create and test custom AO code/blueprints with natural language
Integrate with AI dev tools like Cursor, Windsurf, and Claude
Perform operations like adding numbers, spawning processes, sending messages, and managing handlers
Install APM packages and load blueprints
Execute Lua code and run handlers in AO processes
List, create and manage SQLite-based handlers in the AO environment
Supports running Lua code in AO processes through the MCP server, enabling handler creation and management.
Enables running AO code and blueprints through natural language commands, supporting code testing and complex handler creation.
Offers a remote setup option through Render's hosting platform, allowing users to use Flux without local installation.
Used for integration with AO ecosystem tools and code generation capabilities.
Click on "Deploy 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., "@Flux create a handler that responds with 'Hello World' when it receives a 'Greet' action"
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.
AI based AO tool calling on steroids that integrates with your existing tools and editor using a MCP server.
https://github.com/user-attachments/assets/3484e2db-e7cb-479a-84a2-0b399e1149ac
Run AO code using just natural language
Create and run custom AO code/blueprints completely using natural language
Integrates with your existing AI dev tools like Cursor, Windsurf, Claude, and anything that supports MCP tool calling
Can test out all the code it pushes to an process
Can create and test complex handlers
Related MCP server: Processing MCP Server
Inetgration with AO ecosystem tools
Better code generation capabilities by adding more context about AO
AO
Arweave
MCP typescript sdk
Typescript
Node.js
There are currently two ways to install and use Flux, right now it has been tested significantly only on Cursor so we will be showing how to install FLux in Cursor -
Local Setup - For users who want everything to be present locally, no remote servers involved
Make sure you have latest stable version of NODE.js installed - Node.js download
Open Cursor and go to Settings > Cursor Settings > MCP > Add new MCP tool
Paste this code in the file
"mcpServers": {
"flux": {
"command": "npx",
"args": ["-y", "flux-ao@latest"],
}
}if you did everything correctly you will be able to see the flux MCP loaded with all the tools, and its ready to be used in Cursor (PS: You might have to reload the MCP multiple times or restart Cursor)!
Remote Setup - For users who want to use Flux without installing anything locally
Open Cursor and go to Settings > Cursor Settings > MCP > Add new MCP tool
Paste this code in the file
"mcpServers": {
"flux": {
"url": "https://flux-2esw.onrender.com/sse",
}
}if you did everything correctly you will be able to see the flux MCP loaded with all the tools, and its ready to be used in Cursor (PS: You might have to reload the MCP multiple times or restart Cursor)!
We would suggest you add the llms.txt for AO docs in cursor first and use it as a context before you start using the MCP server. If you don't know how to do it, checkoout this documentation on how to add docs to cursor.
The more context you give to cursor, the more acurate the responses will be.
Now add these custom rules in your Cursor project to make sure Cursor doesn't hallucinate or give wrong responses. You can add these rules in the Settings > Cursor Settings > Rules > Add new rule.
For adding json capabilities ONLY IF NEEDED, you need to add a line "local json = require("json")" on top of file. BUT DONT USE IT UNLESS NEEDED. SIMPLE THINGS CAN BE DONE USING AO PROCESS STATE
Always use Send instead of msg.reply
Always make sure a handler is sending out a response/reply (using Send) and send it as data as well instaed of just returning using tags
Never add any tags by yourself, always add tags when needed or instructed by user, also {"Action":"Eval"} tag is for running lua in an ao process and {"Action" : "action_name"} is for running a handler
Never add the "Type" tag to anything, thats reserved for internal ao specifications
Always use Handler.utils whever possible when creating a handler, for example --
Handlers.add(
"pingpong",
Handlers.utils.hasMatchingTag("Action", "Ping"),
function (msg)
Handlers.utils.reply("Pong")(msg) -- or use Send() here
end
)Now you can start using the Flux MCP server in Cursor Agents.
If you find any issues with the Server or encounter any bugs, please let us know by opening an issue or mailing us @ flux.mcp@gmail.com
Inputs: a (required), b (required).
Inputs: packageName (required), processId (required).
Inputs: handlerCode (required), processId (required).
Inputs: handlerCode (required), processId (required).
Inputs: processId (required).
Inputs: processId (required), url (required).
Inputs: blueprintCode (required), processId (required).
Inputs: blueprintName (required), processId (required).
Inputs: processId (required).
Inputs: data (required), handlerName (required), processId (required).
Inputs: code (required), processId (required), tags.
Inputs: data (required), processId (required), tags.
Inputs: tags (required), needsSqlite.
Inputs: transactionId (required).
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 14 tools
Multiple tools have unclear boundaries and overlapping purposes. For example, 'load-blueprint', 'load-local-blueprint', 'load-official-blueprint', and 'load-token-blueprint' all seem to handle blueprint loading but with unspecified distinctions, while 'create-handler' and 'create-sqlite-based-handler' appear to be variants of handler creation without clear differentiation. The lack of descriptions exacerbates ambiguity, making it difficult for an agent to reliably choose between these tools.
The naming conventions are mixed but still readable. Most tools use kebab-case (e.g., 'apm-install', 'list-available-handlers'), which is consistent, but there are deviations like 'add' and 'spawn' which are single words without hyphens, and 'run-handler-using-handler-name' is overly verbose. While not chaotic, the pattern is inconsistent, affecting predictability.
With 14 tools, the count is reasonable for a server likely focused on process or workflow management, as inferred from tool names like 'spawn', 'run-lua-in-process', and 'send-message-to-process'. It's slightly on the higher side but not excessive, suggesting a well-scoped set that covers various operations without being overwhelming.
Significant gaps exist due to the lack of descriptions, making it impossible to fully assess coverage. Inferred from tool names, the domain seems to involve handlers, blueprints, and processes, but there's no clear CRUD lifecycle—for example, tools like 'add' and 'transaction' are vague, and operations like updating or deleting handlers or blueprints are missing. This incompleteness will likely cause agent failures in handling common workflows.
MCP server that lets your AI assistant build and deploy apps, hosting each one at a live URL.
MCP server for building and testing AI agents with multi-model experimentation and insights.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
MCP server for AI dialogue using various LLM models via AceDataCloud
