MCP
Your whole project, one MCP connection away.
One MCP connection gives Claude Code, Codex, Cursor, Gemini CLI or Grok your project's roadmap, boards, docs and workflows, with no engine to install. It is how your agent reaches the context layer and the workflows ctxflows keeps for your project.
Connect any coding agent
Each ctxflows project is one MCP server, and any coding agent that speaks MCP connects to it with the project's address and a sign-in in your browser.
Each agent connects the same way and reads the same project, so you can mix them per task. Each keeps its own sign-in, good for that one project and nothing else.
Every part of ctxflows, as an operation
Your agent can do everything you do in the web app, because its tools are the same operations the web app uses.
A person and an agent asking the same thing get the same answer. When your agent can't do something, it's told why, such as a permission you withheld, so it corrects course instead of guessing.
Oriented from the first call
Your agent's first call answers what this project is, how work is done in it, the current goal and how to find and start its workflows.
You write that orientation once, in ctxflows, and every session reads the same text, whichever agent runs it.
Only what you allow
Each agent can do only what you allow, and every change is recorded: who made it, when and why.
Set it per project, once for your own agents and once for the runs the engine starts unattended. Deleting for good and changing project settings stay off until you turn them on.
Start and follow workflows
Your agent starts a workflow in your own session and follows it node by node, while ctxflows holds the run and says what comes next.
Your agent picks the workflow that fits what you asked and asks you before starting it. A node closes only once its outputs exist, and an approval waits for you.
A Claude Code session, from first call to a closed node
You ask Claude Code to add ranked search to your project's pages. This is what the session does in ctxflows while it builds the change on your machine.
It starts oriented
The first call returns the project's orientation, its current goal, the next milestone and how to start a workflow.
It finds the work
It reads the goal and its milestone, finds the Implementation board and creates the item, linked to the milestone it serves and the requirements page it came from.
It starts the workflow
It lists the workflows, picks the one for building a feature by its sentence, asks you, and starts it in your session with your request as its purpose.
It works each node
At each node ctxflows says what to read and which outputs to leave. The session reads the requirements page, finds every line about visibility, and writes and checks the code on your machine.
It closes the node
The last agent node closes once its outputs exist. The run moves to its approval and waits for you there.
It keeps what it learned
Before it ends, the session writes its finding as a knowledge record linked to the item, so the next session starts from it.
Your code stayed on your machine. The item, the run, its outputs and the finding are in ctxflows, where the next session and everyone on the project read them.
The same session, call by call
Pick a tool to see the call the session made and what ctxflows answered, from its first orientation to the finding it kept.
Questions about MCP
Is ctxflows an MCP server for documentation?
Which coding agents can connect?
Do I need the engine?
What can my agent change?
How does my agent find the right workflow?
Does my code go through the MCP connection?
Connect your agent to your project
One address, one sign-in, and every session starts oriented.