MCP workflow automation for governed agents

Before MCP, giving an agent a new tool meant writing a connector for that agent framework. MCP defines one way for a tool provider to describe what it offers and for an agent to call it, so a tool written once can be used by many agents.

In a workflow tool there are two directions. In the client direction, an agent or workflow step calls tools hosted on an MCP server, such as a CRM, a ticketing system or an internal API. In the server direction, the workflow tool publishes its own workflows or connectors as MCP tools, so that outside agents such as a desktop assistant can trigger them.

The difference matters when you buy. A product can be strong in one direction and absent in the other.

MCP makes tools easy to attach, which is exactly why it needs controls. The recurring problems are about authority, not protocol.

• Over-broad credentials. An agent that holds one key for every tool turns a single bad instruction into access to everything.
• No per-tool policy. If any agent can call any tool on a server, a research agent can reach the same functions as a finance agent.
• Untrusted tool output. Text returned by a tool can contain instructions. Treat it as data, and never as authority to act.
• Silent changes. A tool server can change what a tool does after you approved it. Pin and review.
• Thin audit. A log that records only that a call happened, not who made it or with what arguments, is of little use after an incident.

Studio agents can call tools on external MCP servers over HTTP, server-sent events or streamable HTTP, with custom headers. Workflow tool steps use the same route. Connecting an external server is a Pro feature in Studio.

The MCP gateway endpoint checks that the caller has an API key with the right scope for that MCP server and that the workspace matches. Each call is logged with the workspace, the server, the method, the outcome and the time. It does not record the tool arguments or the calling person, so it is a thin audit record and not a full one.

What is not built: a per-tool allow or deny rule on the gateway, and exposing your own agents or workflows as an MCP server. Policy applied while an agent runs, through Nexus, can limit which tools an agent may use for runs that are enrolled in a policy, and each agent has its own tool allowlist. For the wider picture of how Swfte treats MCP, see the MCP gateway page and the MCP security guide.

A pattern we would use for a first MCP workflow.

• Start with read-only tools. Let the agent search and summarise before it can change anything.
• Give each agent its own scoped credential, not a shared key, and name an owner.
• Put a person in the flow for any step that writes, sends or spends, and record the approval.
• Keep an allowlist of the tools each agent may use, and review it when a tool server changes.
• Log every call with the caller and the arguments, and test that you can reconstruct an incident from the log.
• Cap steps and spend per run so a loop cannot run away.

If your aim is to let an outside assistant such as a desktop agent trigger your automations, you need the server direction, and the vendors in the table above publish it. If your aim is to let your own agents use tools hosted elsewhere, you need the client direction, which Swfte Studio offers. Many teams need both. In that case, check this against each vendor’s own documentation and ask for a demonstration with your tools.

Facts about other vendors on this page were read on their own sites on 6 October 2026. Check the vendor’s page before you buy, because plans change.