MCP isn’t just a translator of existing API operations. No, it’s much more than that. MCP is a standard way to expose and consume capabilities. Having a standard interface matters a lot. It means that consumers know what to expect, and there’s a common shared vocabulary of what is possible. MCP excels where REST is too vague. And it opens possibilities that other API styles constrain. Behind the scenes, MCP uses JSON-RPC, which, by definition, exposes operations, not resources or data like other API styles do. Since workflows are sequences of operations, it makes total sense to use MCP tools inside them. Is that already possible? Keep reading to know more.
This article is brought to you with the help of our supporter, n8n.
n8n is the fastest way to plug AI into your own data. Build autonomous, multi-step agents, using any model, including self-hosted. Use over 400 integrations to build powerful AI-native workflows.
With so many MCP servers available, you should be able to use them inside your workflows. Yes, it’s true you can replace some of them with the APIs they represent. However, many more aren’t connected to any APIs. Instead, they directly expose capabilities that had never been publicly available before. That’s because businesses are only starting to see the benefits of publishing MCP servers instead of traditional APIs. MCP server discovery is much better than traditional APIs. And that makes it much easier for end users to consume the capabilities you expose through an MCP server. The natural environment for consuming MCP tools is through an AI agent. But don’t let that demotivate you. You should be able to use any tools an MCP server exposes. Both by making direct HTTP requests and also inside a workflow. But how does MCP use JSON-RPC?
An MCP server is simply a JSON-RPC API. In essence, it offers a standardized interface that exposes a set of input parameters and an output that can be either unstructured text or a fully defined object. Let’s first see how the input parameters work, and then we’ll analyze the output. A JSON-RPC request is an HTTP POST with a JSON body that must include certain attributes. The first attribute you need to add to the body is jsonrpc with the value of 2.0, the version of JSON-RPC that MCP uses. Then you also need to add an id, which can be a numeric or string value, to identify the request. Another attribute identifies the operation you want to call. It’s the method attribute. And, finally, there’s the optional params attribute, which is an object. It’s optional because not all operations have attributes. But knowing what the input parameters are is only half the story. Communicating with an MCP server requires a special type of “dance.” First, you have to make a request to initialize your session. If successful, the server responds with its own information and a session ID in the mcp-session-id header. From this point forward, every request should have this header set to identify that you’re operating in the same session. A subsequent request can, for example, retrieve the list of tools available on the MCP server:
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/list"
}
The server would reply with a list of available tools and their corresponding attributes. Here’s an example of the JSON object that defines a tool (taken from the MCP official documentation):
{
"name": "get_weather",
"title": "Weather Information Provider",
"description": "Get current weather information for a location",
"inputSchema": {
"type": "object",
"properties": {
"location": {
"type": "string",
"description": "City name"
}
},
"required": ["location"]
}
}
As you can see in the example, the input parameters are well defined by the inputSchema attribute. But what about the output definition? There’s nothing about it in the tool definition. Well, that’s because the output of an MCP tool is often unstructured text. Remember that the original clients of MCP tools are AI agents, and they’re able to parse and “understand” unstructured responses. The same thing can’t be said about a procedural workflow step. So, how do we make use of an MCP tool response inside a workflow? We’ll get to that, but first, let’s see how we would map the MCP tool and its inputs to a workflow step.
Making an MCP tool available inside a workflow involves creating a step that can call a JSON-RPC API. It’s as simple as that, really. Each MCP tool input parameter becomes an input of the workflow step. The MCP tool output becomes the output of the workflow step. If the output is structured, it’s available at the outputSchema attribute, which has a format similar to the inputSchema we saw before. In that case, we can map each output field to a workflow step output field. The challenge is understanding how to map the output when it’s unstructured. Here we have two options. We can either just accept the output as a text field and make it available as such. Or, we can try to parse the output and transform it into multiple fields. Parsing a string of text can also be challenging, but it’s often as simple as being able to split the text into several parts. In the example we were seeing before, the output looks like this:
Current weather in New York:
Temperature: 72°F
Conditions: Partly cloudyI’m sure it wouldn’t be hard to write a simple parser that would extract three output fields: location, temperature, and conditions. Yes, I know this is a simple example, but it illustrates the most common scenario you can expect.
So, what do you gain from using an MCP tool inside a workflow? The most important thing is being able to have predictable results. When there’s no room for interpretation, the results must follow the input parameters. Other advantages include traceable execution, easier debugging, better security, and overall better reliability. Yes, adapting MCP tools to the procedural reality of workflows comes at a cost. But that cost can translate into real business benefits if done right. Now, it’s up to you to evaluate if what you’d gain outweighs the effort. If I were you, I’d bet on using workflows to orchestrate MCP tools.
