RELATED 01
Magic Cloud
OFFICIAL SERVERMCP endpoint of a self-hosted Magic Cloud instance: your APIs, SQL, files, tasks and a headless browser
1.2kGitHub stars
27kDocker pulls
73popularity score
Flyto2 Core
Python workflow engine whose browser, file, HTTP and data modules run as traced, replayable steps
By Flyto2 Python Local · stdio Browser automationDeveloper tools
53 popularity score ★ 483 ↓ 1.6k/mo
Connect your client
Local (PyPI)
Add in one click
Opens the app, which asks before it adds the server.
Or add it by command or config
FirstTerminal
pip install flyto-coreClaude CodeTerminal
claude mcp add flyto2-core -- python -m core.mcp_serverClaude Desktopclaude_desktop_config.json
{
"mcpServers": {
"flyto2-core": {
"command": "python",
"args": [
"-m",
"core.mcp_server"
]
}
}
}Cursor~/.cursor/mcp.json
{
"mcpServers": {
"flyto2-core": {
"command": "python",
"args": [
"-m",
"core.mcp_server"
]
}
}
}VS Code.vscode/mcp.json
{
"servers": {
"flyto2-core": {
"type": "stdio",
"command": "python",
"args": [
"-m",
"core.mcp_server"
]
}
}
}Codex~/.codex/config.toml
[mcp_servers.flyto2-core]
command = "python"
args = ["-m", "core.mcp_server"]Gemini CLITerminal
gemini mcp add --scope user flyto2-core python -- -m core.mcp_serverSettings 8
FLYTO_SANDBOX_DIR |
Optional: Directory that all file paths are confined to; defaults to the working directory. |
|---|---|
FLYTO_ALLOWED_HOSTS |
Optional: Comma-separated hosts (wildcards allowed) let through the private-range check; unset by default. |
FLYTO_MCP_ALLOW_LOCALHOST |
Optional: Set to 1 to allow localhost and 127.0.0.1 when FLYTO_ALLOWED_HOSTS is unset. |
FLYTO_ALLOW_PRIVATE_NETWORK |
Optional: Allow targets in private or link-local ranges; false by default. |
FLYTO_ALLOW_ABSOLUTE_PATHS |
Optional: Whether absolute paths may be passed (still kept inside the sandbox). |
FLYTO_MODULE_DENYLIST |
Optional: Glob patterns of blocked modules; replaces the default list, empty string clears it. |
FLYTO_MODULE_ALLOWLIST |
Optional: Glob patterns of the only modules allowed to run. |
FLYTO_GRANTED_PERMISSIONS |
Optional: Grants permissions such as shell.execute or payment.process to the modules that need them. |
What it does
Flyto2 Core is a Python execution engine. It runs automation as a series of named steps (open a browser, load a page, run a script in it, write a file, call an API) and records the input, output and timing of each one. When a step fails, a run can be restarted from that step instead of from the start. The same engine is reachable from a CLI, YAML workflow files, a Python API, a local HTTP API and an MCP server.
The MCP server is a gateway to the module catalogue, not one tool per module. In v2.33.0, src/core/mcp_handler.py registers nine tools: an assistant searches or lists the catalogue (about 480 modules across browser, file, http, data, string, image, crypto, ai, docker, k8s, AWS and more), reads a module's parameter schema and examples, checks its parameters, and then runs it with execute_module or runs one of the bundled recipes. The README and docs page say every module shows up as its own tool, but the code at that tag does not do this.
Browser sessions stay open between calls in the stdio server. The server closes sessions left idle and shuts down any remaining Chromium processes when the client disconnects.
What it needs
| Runtime | Python 3.10+ |
|---|
Python 3.10 or later and `pip install flyto-core` into the Python the client starts. Browser modules need `pip install flyto-core[browser]` and then `playwright install chromium`. Other module groups need their own extras (ai, image, crypto, dns, telegram, vector; `[all]` brings every one). The api.* and ai.* modules need credentials for the services they call (OpenAI, Anthropic, Slack and others). The Streamable HTTP transport needs `pip install flyto-core[api]` and `flyto serve`, which listens on 127.0.0.1:8333 with MCP at /mcp.
Limits
The MCP docs give `flyto-core mcp` as the stdio command, but the v2.33.0 pyproject.toml installs only `flyto`, `flyto-serve` and `flyto-verification`. Use `python -m core.mcp_server` as the README does. Some module groups are blocked by default (shell.*, process.*, sandbox.*, database.*, git.*, k8s.*, ssh.*, docker.run/exec, file.delete, env.*, flow.invoke/subflow/batch) until an operator changes FLYTO_MODULE_DENYLIST or FLYTO_MODULE_ALLOWLIST. Modules that need shell, subprocess, payment, debugger or code-execution permission also need FLYTO_GRANTED_PERMISSIONS. Module counts differ between pages (482 README, 481 PyPI, 452 docs).
Who it suits
Suits developers who want an assistant to do multi-step browser and data work on their own machine (scraping, screenshots, site audits, format conversion) and keep a step-by-step record of each run. It is local and writes files, so it fits someone willing to set a sandbox directory and host allowlist. If you only need a browser driver, a dedicated browser server is simpler: this one adds a catalogue layer the assistant has to search before every action. Its shell, database and container modules are off by default, so it does not suit people who want those without editing the policy settings.
Tools 9
list_modules- Lists the available modules grouped by category, optionally for one category
search_modules- Finds modules by task keyword; 20 results by default, set with limit
get_module_info- Returns one module's full parameter schema and output description
get_capability_manifest- Reports which capabilities this installation has
get_module_examples- Shows worked parameter examples for a module
execute_module- Runs one module with given parameters, reusing a browser session if passed
validate_params- Checks parameters against a module's schema without running it
list_recipes- Lists the bundled workflow recipes
run_recipe- Runs a bundled recipe with the arguments it takes