August 11, 2026 · The MCPCloud team

One workflow, two servers, one trace

A skill that reads a charge from one MCP server and opens an issue on another — and how we proved the second step actually consumed the first.

skillsmcpworkflows

Generating an MCP server from a spec is the easy part, and by now it is close to a commodity. The interesting question starts one step later: your agent needs to read a failed payment from your billing API and open a ticket in your issue tracker. Those are two different servers, two different credentials, two different rate limits. Something has to hold that workflow, run it, and be able to tell you afterwards what actually happened.

That is the part we think is the product. Not the generator — the place the servers live, where a workflow across them has auth, limits, metering and a trace.

The demo, concretely

We run two showcase servers against real APIs on separate infrastructure: a Stripe surface in test mode, and Forge, a code-and-issues API. They know nothing about each other. Neither was built for this demo.

The skill is two steps. Step one calls a tool on the Stripe server to fetch the most recent charge for a customer. Step two calls a tool on the Forge server to open an issue about it. One skill, two servers, one invocation.

The runjson

{
  "isError": false,
  "executedSteps": 2,
  "skipped": 0,
  "durationMs": 4380
}

Why "two steps ran" is not the claim

A green result with two executed steps proves almost nothing. Two calls can both succeed while the second ignores everything the first returned — which is the failure mode you would never notice from a status field, and exactly the one that matters in a chained workflow.

So the assertion is on the data, not the status. The issue that step two created carries the charge id from step one as its title, and that charge’s status as its body. Those values existed nowhere until step one returned them. If the chain had been two independent calls wearing a trench coat, the issue would have been empty.

The general rule

When you test a chained workflow, assert that a value which could only have come from step one appears in step two’s output. Anything weaker — exit codes, step counts, durations — is satisfied by a chain that silently dropped its input.

What the platform is actually doing here

Each step is an ordinary MCP tool call against a deployed server, which means it inherits everything those servers already have rather than a parallel path built for skills:

Credentials stay with the server that owns them — the skill never sees a Stripe key or a Forge token.
Each server’s own rate limits and access rules still apply; being called by a skill is not a bypass.
Both calls are metered against the org, per deployment, so a two-server workflow costs what its parts cost.
The whole invocation lands in one trace, with per-step timings and the actual arguments and results.

That last one is why the proof above was possible at all. We did not have to instrument anything to check that step two consumed step one — the trace already held both payloads.

Where this is honest about its limits

A skill orchestrating calls across servers is a different thing from one server serving another server’s tools under a single endpoint. We are building the second as well, and it is not finished: it runs today in our own environments and is marked beta on the capabilities list until it has run in production. We would rather say that than let a demo imply a shipped feature.

The workflow above uses what is live: skills, deployed servers, and the dispatch layer that already sits in front of every tool call.