Add a new `MCP` call task

[cdavernas]

What would you like to be added?

Add a new call task for the Model Context Protocol (MCP), thus enabling agentic calls and AI toolset invocations within workflows. This task should allow workflows to interact with MCP-compliant endpoints, supporting:

• Invocation of AI agents or tools via MCP,
• Input/output handling according to the MCP spec,
• Optional streaming support,
• Error propagation and response normalization.

This will allow seamless integration of agent-based capabilities into declarative workflows.

Proposal(s):

Introduce a new call type, e.g. mcp, designed to support both MCP transport protocols: STDIO (for local command invocation) and HTTP (SSE) (for networked agent endpoints).

The task definition should adapt its configuration based on the chosen transport:

For STDIO-based invocation:

• A command field specifying the executable and arguments to launch the local MCP-compliant process.
• An optional input payload conforming to the MCP input schema, passed via STDIN.
• An optional directory and environment to control the execution context.

For HTTP (SSE)-based invocation:

• A uri field pointing to the MCP-compliant HTTP endpoint.
• Optional headers to customize the HTTP request.
• Optional input payload conforming to the MCP input schema.

The runtime should:

• Detect the transport protocol
• Handle invocation according to the MCP specification
• Normalize the response (including streamed output if applicable)
• Map MCP errors into workflow errors consistently

This proposal ensures that both local and remote AI agent/tool invocations are supported seamlessly within the workflow system.

Alternative(s):

No response

Additional info:

No response

Community Notes

• Please vote by adding a 👍 reaction to the feature to help us prioritize.
• If you are interested to work on this feature, please leave a comment.

[geomagilles]

Can you please provide an example of use-case - it's unclear to me. If I understood correctly, you are proposing to add the capability to act as a MCP client, but MCP client are usually LLM runtimes themselves, so I'm not sure how this new feature would be used by an end-user.

[cdavernas]

@geomagilles One could indeed argue that MCP client is strictly restricted to agents, but that's not necessarily the case. Although it is indeed intended to be used in that particular context, MCP is but yet another protocol to describe and document features exposed by an application. As a matter of consequence, one could want to use said features, exposed through that protocol, because the server app does not define any other interfaces.

As for a2a, it is used to enable standardized communication with agents, thus opening the door to agentic workflows, empowered by a well-known discovery protocol.

[geomagilles]

@cdavernas My experience in product management convinces me that a good idea to be able to describe a concrete use case before developing (and maintaining) a feature. At least to check that - once developed, the proposal makes a new usage possible. In this example, I do not see yet how it can be use in a practice case, even for agentic workflows as the MCP servers would be defined at the IA level in a serveless workflow (I do not talk about a2a that I have not looked at yet). But Maybe I'm missing something, that's why I am asking.

[cdavernas]

@geomagilles I actually have such use cases with one of my clients, where we need access to applications that only offer an MCP interface.

A sample use case would be to use fetch without having to create some kind of adapter API.