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.

  1. 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.

  2. 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.

  3. The account hub

    Routes the checked call to the connector the account's machine opened, as a signed command.

  4. 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.

  1. 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.

  2. Run

    The change is committed inside one named Revit transaction, so Undo takes back one step rather than several hundred.

  3. 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.