How it works
Where a request actually goes
No cloud builds your model for you. FLOW runs through a hosted endpoint and a connector on your machine, shows what a change would do when the call asks for a preview, and tells you what it read back afterwards.
Four hops between prompt and model
The assistant never talks to Revit directly. Three pieces sit in between — the hosted endpoint, the account hub and the connector inside Revit — and only the last one runs on your machine.
The assistant you use
Sends a request over MCP to FLOW's hosted endpoint. It does not know the Revit API — only the list of tools FLOW lets it see.
The hosted endpoint
765tflow.com/mcp authenticates the call and checks it against the declared tool surface. This is where the tool list the assistant sees is decided.
The account hub
Routes the checked call to the connector the account's machine opened, as a signed command.
The connector inside Revit
Receives the signed command on the outbound connection it opened — nothing on your machine listens on a port. It verifies it and calls the Revit API on a valid thread; it is the only thing here that touches the model.
The model stays on your machine. FLOW sends only the context the job needs.
Preview, run, read back
The assistant you connected decides — none of these beats waits on a human click. A write commits inside one named transaction and reads back after; a dry-run preview is an optional first beat when the call asks for one.
Preview
When the call asks for it, the tool runs dry and reports what it would change — how many elements, which parameters, which values — without touching the model.
Run
The change is committed inside one named Revit transaction, so Undo takes back one step rather than several hundred.
Verify
FLOW reads each changed element back out of the model and reports what it found — not what it intended.
This is how FLOW works with you. It is not a promise about other software already running on the same machine.
One tool surface, declared per tool
There is one MCP surface: the 464 tools that actually register at runtime. A signed-in account sees all of it — reading and writing sit on the same list.
Every tool on that surface is allow-listed by its own registration. A tool that does not declare itself does not exist as far as the assistant is concerned — there is no deny list, only an allow list.
Tools that accept executable content are refused outright on this surface, whatever their registration declares.
That list is served from the hosted side with the catalog — not a configuration file on your machine, and not a setting you have to go and switch on.
464 tools across 15 groups
This is the number of tools that actually register at runtime, not the number of names declared in the source. Those two numbers differ, and we print the smaller one.
This figure is checked against the real tool registry automatically.
Not done until it has been read back
Once a change is committed, FLOW reads each changed element back out of the model.
What you get is what it found in the model, not what the tool intended to do. A dry run reads nothing back, because nothing happened yet.
When the list is too long to return in full, the result says it was truncated. A list that cannot admit it is incomplete is worse than no list.
What it runs on
What the machine needs before FLOW can do any work.
- Windows 10 or 11
- Best supported on Revit 2021 and later
- An AI app that supports MCP connectors
Screenshots from real Revit
We publish real captures, not mock-ups. Screenshots from a live Revit session will appear here when we have them.