Documentation

Why ReadyAgents?

MCP connectivity is not durable orchestration.

This page records two public reports about gaps between MCP wiring and durable workflow execution, plus one design note about how modern MCP asks a question. It states plainly what ReadyAgents 2.0.6 does and does not do. Each verdict is about our own software only.

If you are evaluating a LangGraph or n8n MCP surface for durable HITL, this page is the honest comparison: ReadyAgents 2.0.6 is a self-hosted alternative when you need local persist/resume, and it is still only PARTIAL on hosted recovery.

Verdicts as of 15 September 2026. Cells match the cited sections below.
Capability	ReadyAgents 2.0.6	LangGraph MCP	n8n MCP Trigger
Stateful MCP-exposed runs	Partial	No	No
HITL on the MCP trigger surface	Partial	No	No
Retry-shaped elicitation (MRTR)	No	—	—
Self-hosted / BYOK	Yes	Yes	Yes

LangGraph MCP surface: MCP-exposed runs remain stateless

Sources (as of 15 September 2026): langchain-ai/langgraph issue 8725 and LangSmith server MCP docs

Quote issue 8725:

When a LangGraph Platform deployment is exposed as an MCP server, every tool call is executed as a temporary run: no durable state exists even while it runs (checkpointer=None), and its auto-created thread is deleted on completion.

Quote LangSmith docs:

The current LangGraph MCP implementation does not support sessions. Each /mcp request is stateless and independent.

ReadyAgents 2.0.6: PARTIAL. We persist local workflow state and support resume/approval pauses. Opt-in loopback Streamable HTTP implements MCP 2026-07-28 tasks (start/poll/decide/cancel), but there is still no hosted recovery surface. This comparison is about the MCP surface, not LangGraph's other surfaces.

n8n MCP Server Trigger: a long synchronous call can lose the result, and HITL is unsupported

Sources (as of 15 September 2026; thread dated 2026-08-25): n8n community thread on MCP Server Trigger 502 after ~125s and n8n MCP Server tools reference

Quote the 2026-08-25 thread:

MCP request starts → long-running subworkflow continues → MCP request/connection times out after about 120 seconds → external caller receives 502 → n8n subworkflow continues and eventually succeeds

Quote the reply:

A tool that legitimately runs 2 to 4 minutes cannot answer synchronously.

Quote the current MCP tools reference:

Executing workflows with multi-step forms or any kind of human-in-the-loop interactions isn't supported.

ReadyAgents 2.0.6: PARTIAL. We checkpoint locally and have an approval node. Loopback MCP tasks (and deprecated /runs) exist for explicitly started HTTP, but that is not a networked public MCP Server Trigger, so we still do not solve the networked MCP Server Trigger case end-to-end. n8n's instance-level execute_workflow already returns an execution ID immediately; this page is only about the MCP Server Trigger surface.

Note

Design note: modern MCP uses retry-shaped multi-round trips

Sources (as of 15 September 2026; spec dated 2026-07-28): MCP specification: Multi Round-Trip Requests (MRTR) and Python SDK elicitation handlers

Quote the spec:

Multi Round-Trip Requests (MRTR) was introduced in this version of the MCP specification. This replaces the previous approach of sending server-initiated requests.

Quote the Python SDK:

A resolver works on every connection. For a client on a legacy connection the SDK sends it the question directly; on a 2026-07-28 connection the SDK returns the question from the call, and the client's next attempt carries the answer.

This is a design note, not a competitor gap. The ask is now a stateless retry-shaped resolver; ReadyAgents sidesteps it with a persisted approval node, and does not implement MRTR or protocol elicitation.