Updated Oct 25, 2026

Connect MCP Server

Use this action when you want an agent to discover and use the tools exposed by an external MCP server during the current conversation.

Best for

• Giving an agent tools hosted on your own MCP server without changing the agent's permanent configuration
• Sending authentication headers whose values come from earlier steps (for example workflow.step(0).jwt from a Generate JWT token step)
• Connecting to AutoTalk's own MCP endpoint after generating a JWT

Main fields

Field	What it does
Server URL	The full HTTP endpoint of the MCP server (Streamable HTTP transport). Only public HTTP(S) URLs are accepted: private and internal network addresses are rejected when the action is saved, and the URL is SSRF-checked again at run time
Headers	Optional request headers sent to the server. Each Header key and Header value is a CEL expression evaluated at run time, so a value can reference earlier step outputs such as workflow.step(0).jwt

What later steps can use

Connection details are available at:

• workflow.step(N).url
• workflow.step(N).toolCount

The step registers the server; the actual connection and tool discovery happen right afterwards, while the agent prepares its next model call. Because discovery completes after the step finishes, workflow.step(N).toolCount reports 0 at that point.

Tips

• Use this action as an agent pre-action so the server's tools are already available when the model responds.
• Discovered tools are offered to the agent for the current run only — the server is not saved to the agent configuration.
• Treat tokens passed in header values as sensitive data: prefer a Generate JWT token or Resolve Variables step over hardcoding secrets.
• Missing/invalid URL or registration validation errors fail the step (mcp_missing_url or mcp_connect_failed in workflow.step(N).executionContext.safeError.code). Registration adds the server to this run; it does not guarantee later tool discovery succeeds. Discovery errors can be logged and that server's tools skipped.