Execution engine for AI agents. 412 modules: browser, file, Docker, data, crypto.
io.github.flytohub/flyto-core (MCP Server)
The io.github.flytohub/flyto-core server is an execution engine for AI agents. It provides a Python-based system that runs browser and API work as explicit steps, records the results of each step, and can replay from the point where a step failed.
๐ ๏ธ Key Features
Execution engine for AI agents
Runs browser and API work as explicit steps
Records what each step did
Replays from the step that failed
Public inventory: 480 registry-backed modules across 88 catalog categories
Module inventory includes triggers, queue modules, workflow versioning, metering hooks, browser automation, API calls, data transforms, verification, files, and crypto
๐ Use Cases
Agent workflows that require step-by-step browser automation
Agents that perform API calls and data transforms
Debugging by replaying from failed steps instead of rerunning the whole job
โก Developer Benefits
Step-level execution trace via recorded step outputs
Faster iteration through failure replay
Broad module coverage across automation, workflow, and verification needs
โ ๏ธ Limitations
The provided description does not enumerate specific MCP tools beyond the execution/step model and module inventory.
A Python execution engine for AI agents. It runs browser and API work as
explicit steps, records what every step did, and replays from the step that
failed โ instead of re-running the whole job.
The current public inventory is 480 registry-backed modules across 88
catalog categories, including triggers, queue modules, workflow versioning,
metering hooks, browser automation, API calls, data transforms, verification,
files, and crypto.
Every run produces an execution trace and state snapshots. If step 3 fails, replay from step 3 โ no re-running the whole thing.
Usage
CLI โ run workflows from the terminal
bash
# Run a built-in recipe
flyto recipe site-audit --url https://example.com
# Run your own YAML workflow
flyto run my-workflow.yaml
# List all recipes
flyto recipes
Execution Trace โ structured record of every step: input, output, timing, status
Replay โ re-execute from any step with the original (or modified) context
Breakpoints โ pause execution at any step, inspect state, resume
Evidence Snapshots โ full state before and after each step boundary
Data Lineage โ track data flow across steps, build dependency graphs
Timeout Guard โ configurable workflow-level and per-step timeout protection
Architecture
CLI, MCP, HTTP, Python, and packaged recipes converge on the same workflow
engine, module registry, policy, trace, evidence, and replay boundaries. Start
with the Technical Whitepaper, then use the
Architecture Map and exhaustive
source reference for implementation detail.
Report security vulnerabilities via security@flyto2.com.
See SECURITY.md
for the security policy and the environment variables that define the filesystem
and outbound-network boundaries.
SECURITY_STATUS.md
lists every published advisory with its severity, affected range, fixed-in
version, and the regression test that covers it. Two boundaries are enforced
registry-wide by tests that fail the build โ every module taking a
caller-supplied path must reach the filesystem sandbox helper, and every module
taking a caller-supplied URL or host must reach an SSRF guard โ so coverage is a
CI property rather than a convention.
Also known as: open source AI agent framework for production workflows ยท Python AI workflow automation with Playwright ยท MCP server automation with trace and replay ยท browser automation that can resume from a failed step