Results and MCP tools

An automation can answer. Declare a Result in its settings, put a Result step where the answer is known, and whatever waited on the run reads it when the run completes: an Automation step with Wait For Completion on, an Automation Completed trigger, or an AI agent that called the automation as a tool.

That last reader is new. Each workspace has an MCP server, and an On Demand trigger can be offered on it as a tool. An agent connected to the server sees the tools the person it acts for may run, calls one with the trigger's inputs, and gets the run's result back.

The Result

The Result is declared once, in the automation's settings, as a Custom Shape: named, typed fields, each with an optional description. It is the one contract every Result step in the graph fills, however many there are, so a flow that branches and answers on each branch still has one shape, and one result for callers to read.

An automation with no Result declared answers with nothing. Its runs still complete, and callers still learn that they did; there is just no value to read.

Result steps

A Result step captures the answer where it sits. Its Value is a variable holding an object an earlier step built, or an object built in the step field by field, and it must match the declared Result: the step's form lists the Result's fields and warns while a required one is missing, and the step fails at run time if the value does not fit.

A run keeps one answer. The first Result step to complete gives it; any other that runs afterwards fails, naming the one that answered. That decides what to do with the two shapes that would otherwise answer twice:

• Branches—join them before a single Result step rather than putting one on each branch. A Result on each side of a condition is fine, because only one side runs.
• Loops—a Result inside a loop answers on the first iteration and fails on the next. Collect what each iteration produced with the Loop End and put the Result after it.

Where the step sits decides only when the value is captured, not when it is delivered. The steps after it still have to succeed before anyone reads the answer: a failure after the Result fails the run, and a step that pauses for a person holds the answer until they act. Those later steps can read the Result's output themselves, like any other step's.

Verify notes a Result placed where it would fail—inside a loop, after another Result, or on a branch that runs beside another Result's—and an automation that holds a Result step but declares no Result. These are notes, not errors: the graph saves and runs, and the step itself is what refuses a second answer.

Offering a trigger as a tool

An On Demand trigger that starts the flow can be offered to agents. On its Advanced tab, add an MCP Tool and give it:

• Name—what agents call the tool by. A lowercase letter, then lowercase letters, digits and underscores, up to 40 characters, unique in the workspace. Left empty, it is filled in with the automation's name in that form when you save. Either way the name is stored, so renaming the automation later does not break the agents already calling the tool.
• Description—what an agent reads to decide whether to call the tool, and how. It defaults to the automation's description.
• Wait For Completion—off, a call answers as soon as the run has started, with the run's handle. On, a call waits up to 10 seconds for the run and answers with its result when it completes in time: for an automation that answers quickly, such as a lookup. Only a few calls may wait at once, server-wide; the rest answer with the handle as if the setting were off, so agents can never hold the CMS's request threads.

Nothing is a tool until it has one. A trigger in the middle of a flow is never offered, since it waits for a person rather than starting runs, and the field is hidden there. A trigger whose payload is a Content Type, or whose Custom Shape holds a File field, cannot be offered, because an agent has nothing to send for either; the form says so.

Deleting a trigger that is offered, or switching it to another trigger type, asks for confirmation first, the way it does for a trigger other automations call, and the trigger's Used By tab names the tool.

What an agent sees

The server has two modes, chosen by the URL an agent connects to, and the Settings page shows every URL with a copy button. Run mode is for an agent acting as a person: a workspace's own server at /automation/mcp/<workspace code> offers that workspace's automations as tools, named as their triggers name them, and the root server at /automation/mcp offers the tools of every workspace the person may run automations in, each tool's name prefixed with its workspace's code (wdrt_summarize_article) and its title and description naming the workspace, since tool names are unique only within a workspace. Manage mode, at /automation/manage/mcp[/<workspace code>], is for an agent building automations: it offers the tools to read, check, rehearse, change and publish them, and none of the automations themselves, so a building agent can never run one for real. Capabilities say what the person may do; the mode says what the agent is there to do. Someone with one workspace can use either address; someone with several chooses, per agent, between one workspace and all of them.

A workspace keeps agents out until it says otherwise: Allow AI Agents to Connect, on the Settings page's MCP Server tab, is off until an Owner turns it on; off, every agent is refused at the workspace's addresses and the workspace is left out of the root servers, whatever its members may do by hand. An agent connects with OAuth, consenting as a person, and from then on acts as that person: it is offered the tools of the automations they may run, and nothing it does exceeds what they could do in the tool themselves. A token is bound to the URL it was issued for, so one for a workspace's server is no good at another's, or at the root.

A tool's inputs are its trigger's Custom Shape fields, with their descriptions. Arguments are checked against the shape before anything runs, and an argument the shape does not declare is refused rather than ignored.

A call starts the run and answers as soon as it has started, or, when the tool's Wait For Completion is on, waits up to 10 seconds for it. The answer carries:

Field	What it says
status	completed, working, input_required, failed, or cancelled.
result	The Result the run answered with, once it has completed, when the automation declares one.
prompt	What the run is waiting on, when status is input_required.
stepId	The step that is waiting, as get_run_steps names it. A run whose parallel branches each wait on a person is parked on several steps; the envelope describes the one parked longest, and an answer names the step it is for.
answerWith	When status is input_required and an agent may relay the person's answer: answer_approval for an Approval, answer_run for anything else. Absent when a person has to answer in the tool.
answerSchema	The JSON Schema of the answer answer_run takes, when answerWith is present.
error	Why the run failed or was cancelled.
run	The run's id, its number in the automation's history, where a person can open it, whether it rehearsed, and, while it is working, checkBackInSeconds.

A run that is still working, or parked on a person, is not over: the agent reads it back with the server's own get_run tool and the id in the run handle, until the status is one of the three that end a run. get_run finds only the runs the calling person started in a workspace the server serves. It never waits: a run still working carries checkBackInSeconds in its handle, drawn from how long the automation's recent runs spent working, not counting time spent waiting on a person, so the agent knows how long to give it before reading it back rather than reading it in a loop. Values in a result are redacted the way the run view redacts them, so a secret the run saw never leaves.

Two more tools of the server's own, scoped the same way: list_runs lists the runs the person started through the server, newest first, each with its status, handle and tool, narrowed by status or tool—for a handle the agent lost, or to see what is still working or waiting on a person; cancel_run stops a run that is still going, as the run page's Stop does.

get_run_steps and get_run_step are the run pane, for an agent: every step of a run in the order it started, then those that never did, with its node, status, timing, iteration (its index in each loop, from 0) and error, and one step in full with its resolved inputs, outputs and payload, its earlier attempts, and its timeline of status changes and log lines. Values are redacted the way the run view redacts them. In run mode the run-following tools see the runs the person started through the server; in manage mode they see every run of the workspaces the person may build in, as the Runs page shows a builder. list_runs narrows by status, tool, automation and start time in either mode.

When the run is parked on an Approval, the server's answer_approval tool lets the agent relay the person's decision—approve or reject, with a comment, which the approval may require—as that person, exactly as if they had answered in the tool or on Slack or Teams. The tool is offered only to a person who holds the Approve capability, and the answer is recorded as theirs, via an AI agent. An Approval with People Only on refuses the tool, and the agent is told a person has to answer it. A run parked on more than one step refuses an answer that doesn't say which, by stepId, and names them.

Anything else a run is parked on—an AI Agent step's question, a form—is relayed with answer_run, which takes the answer in the shape the run's answerSchema describes and holds it to that shape exactly as the form would. It answers approvals too, in their own terms. list_pending_approvals lists every run waiting on a person in the workspaces the server serves where the person may answer—the Approvals page, for an agent—each with its question, answerWith and answerSchema, so an agent can tell the person what is waiting and relay their answers. Both are offered only to a person who holds the Approve capability.

preview_automation, in both modes, answers with a picture: the automation's flow drawn as the editor's canvas draws it, every step's card, the edges between them and the notes, in the light or dark theme. With a run's id it draws that run as the run view shows it: each step in its status's color, green where it completed and red where it failed, a skipped step dashed and faded, a step waiting on a person ringed, and the edges the run crossed in its colors. In run mode it draws the automations the server offers as tools, by id or by tool name; in manage mode, any automation the person may build, a draft or revision included. The same picture is served to a person at /automation/api/flow-image?automationId=…, with executionId, theme and scale.

An automation that is off, or archived, is not offered. A draft that is turned on is: its runs rehearse, every answer says dryRun, and the tool's description says so, which is how you test a tool end to end before publishing. A revision is never offered; the live automation is the tool.

Building with an agent

In manage mode the server offers a person who holds the Build capability the tools to build with, so an agent can create an automation, try it and publish it in one connection. The tools follow the capability the way the pages do: someone without Build is refused at the door, someone without Approve or Turn On / Off doesn't see those tools, and get_settings takes Configure as the Settings page does. Capabilities are what the tools check; the areas a role may hide, such as Connections or Executions, aren't, so a builder whose role hides a page can still read what it shows through the matching tool. The run-following tools—get_run, list_runs, cancel_run—and the answering tools are offered in both modes, since a rehearsal is a run like any other.

• list_workspaces names the workspaces the server serves, by the code the other tools take as workspace, with what the person may do in each. On the root server a build tool needs that code when the person may build in more than one workspace; on a workspace's own server it is implied.
• list_automations and get_automation read what is there. get_automation returns the automation's document—the same export the UI produces and imports—with its validation and the version a write names, so an existing automation is the worked example of the format.
• get_guide returns the guide to building automations that every agent building them reads: how automations work and how data passes from step to step, with a topic each on the graph, variables, mappings, loops, results, scripts and the document format.
• describe_node_types returns the node catalog: every node type the node picker offers, by category, with its typename, which is a node's _type in a document, and what it is for.
• validate_automation checks a document without saving it: what blocks a run or a publish, what Verify would note, and what an import review would ask a person to look at; and, node by node, what a save would refuse, what the node's card says needs attention, and the references on it that no longer resolve or can't be checked. It names each node by the id the document gives it.
• test_automation runs an automation the person may build as a dry run, always—nothing it does reaches outside, test targets stand in, and the answer says dryRun. It is the only way to run anything from manage mode, and never a real run: a real run is the automation's own tool in run mode, which exists because its author offered it.
• get_stats reports a workspace's runs, success rate, execution time, cost and tokens over a window against the window before, or one automation's runs by status.
• create_automation makes a draft, off, from a document—through the same import the UI runs, so the review's findings come back as data—or a blank one from a name. update_automation replaces an automation's working copy from its document: a draft is changed in place; a published automation gets a revision, and the live one runs unchanged until publish_automation puts the revision over it. Nodes keep their ids, so runs and versions keep pointing at the same steps; a node new to the automation gets an id of its own, and both tools answer with where each node of the document landed. A definition field the document leaves out keeps its value. update_automation requires the version it read, of the copy it changes, so nobody's change is overwritten: a published automation's revision, when it has one, is read by its own id.
• publish_automation is the editor's Publish: a draft goes live and turns on, unless the workspace is at its limit of automations that are on; a revision goes over its live automation. A graph that couldn't run is refused. archive_automation and restore_automation do what the list page does; set_automation_enabled, for a person who may turn automations on and off, is its switch.
• describe_node_type returns one node type in full: its typename, its category, what it is for, the fields it may set as a JSON Schema with every type embedded in them under $defs, and the handles its edges leave by. describe_node_types is the overview; this is the detail.
• describe_type returns any other type a document holds, by its typename: the automation's own definition, an edge, a note, an input or output mapping and its transforms, or a type a schema names with $ref. It answers one level at a time, naming each embedded type by $ref to describe the same way, since the definition and a mapping each reach whole families of types.
• get_field_values lists what one field of a saved automation may hold, as the editor offers it to a person: the variables it may bind, each as the {"$variable": …} object a document writes, and the choices its own dropdown offers, such as connections or saved scripts. A source with more fields than it lists at first says so, and naming it lists them all, as Show Full List does in the Add Variable modal.
• list_templates and get_template list what an automation can start from—the built-in templates and the workspace's saved recipes—and return one as a document. create_automation takes a template's key to start from it.
• list_connections, list_models, list_variables, list_content_types and get_settings read what a node refers to: the workspace's connections and MCP servers by id, type and state, never a credential; the models each AI provider connection offers right now; variables with their values and secrets by name only; the workspace's content types, or one in full as a JSON Schema; and the settings and limits, with any limit the workspace is at.
• list_versions and restore_version are the editor's history pane: each saved version, newest first, and a rollback that becomes a new version and keeps a trigger's identity as senders know it. discard_revision throws a revision away and leaves the live automation untouched. export_automations is the export the list page produces, for several automations together with the references between them.
• list_deliveries is a webhook trigger's Deliveries tab: what the automation's triggers received, newest first, each with its origin, signature check and outcome—ran, gated, or skipped and why—and the run it started; or one delivery in full with its body. A delivery's headers, which carry what the sender authenticated with, are never returned.
• list_agents, create_agent, update_agent, archive_agent and restore_agent are the Agents page: each agent in full, with its model, standing instructions and the MCP servers it draws tools from, and the fields to make or change one. list_scripts, get_script, create_script, update_script, archive_script and restore_script are the Scripts page, and check_script parses code in the sandbox a Script step runs it in and says what is wrong with it, without running it. As on those pages, an agent or script is archived rather than deleted: the lists leave it out unless asked to include archived ones, a step that runs as an archived agent fails until it is restored, and a step that runs an archived script still runs it. set_variable and delete_variable are the Variables page for variables; secrets are set by a person in the tool, never through an agent, so a value never sits in its transcript.