MCP agent runtime

The protocol is the easy half

MCP solved a real problem: before it, every agent framework had its own tool interface, and connecting a model to a system meant writing an adapter for that particular pair. A shared protocol means a tool server written once is callable from anything that speaks it.

What the protocol deliberately does not specify is everything around the call. Which of these tools may this agent use. Should this particular invocation run now or wait for a person. What did the tool actually return, and how long did it take. What happens when it fails halfway through a longer run. Those are runtime questions, and they arrive the moment MCP tools touch anything that matters.

A runtime sits on both sides of the protocol

Heym is an MCP client and an MCP server, which are two genuinely different jobs.

As a client

An Agent node connects to external MCP servers and picks up their tools automatically, with no per-tool configuration. One agent can consume several servers at once, alongside its inline Python tools, its skills, and other Heym workflows called as tools.

As a server

A workflow containing an Agent node can publish its own tools as an MCP server on its own endpoint, so Claude, Cursor, or any other MCP client can call your workflows directly. The workflow becomes the tool.

Transports

Endpoints support the SSE transport and the Streamable HTTP transport, and agents can also connect to servers over stdio. Clients that support OAuth 2.1 with PKCE sign in that way.

Scoped access

A session token issued during the handshake is scoped to one named server, so a token for one server cannot reach another.

The part that only a runtime can do

An MCP tool call is an action taken by a model against a real system. That makes the controls around it the interesting part, and it is where a runtime earns its place.

Approval scopes per tool

Written review guidelines are interpreted into approval scopes, so a read-only lookup auto-approves and a write escalates to a person. The agent keeps moving on the safe calls and stops on the consequential ones.

A trace of every call

Tool names, arguments, results, and the time spent listing tools versus calling them are recorded per invocation, so a wrong answer can be traced to the tool that produced it.

Failure that stays on the canvas

A failing tool call is a workflow error like any other, routable through an Error Handler node rather than surfacing as an opaque agent stall.

Cost attribution

Tool calls extend a run and consume tokens on every loop. Because cost is tracked per execution in USD, a chatty MCP server shows up as a number rather than as a surprise.

Questions worth asking before you commit

These apply to any candidate, Heym included. They are the questions whose answers are hard to change later.

1. 1

   Can it be both client and server?

   Consuming MCP tools and publishing your own are separate capabilities. Needing a second system for the other direction is a real cost.

2. 2

   Which transports are supported?

   Check for SSE and Streamable HTTP for remote servers and stdio for local ones, since client support varies and you do not control what your users run.

3. 3

   Are tool calls individually approvable?

   MCP servers advertise whatever tools they have. Without per-tool scoping, connecting one server is an all-or-nothing grant.

4. 4

   Is the tool call in the trace?

   Arguments and results, not just the tool name. A tool that returned the wrong row is invisible otherwise.

5. 5

   How are server tokens scoped?

   A token that works across every server you publish is one leak away from being a general-purpose key.

6. 6

   Can one agent hold several servers?

   Real work usually needs a few. Check whether adding a second server requires configuration per tool.