Skip to main content
Every published processor is a connectable MCP server. No SDK, no integration code, an agent gets the URL, sees the tool and its schema, and can pay for a call on its own.

The endpoint

Stateless, per the 2026-07-28 MCP revision: no handshake, no session id, no long-lived stream. initialize is still answered for 2025-era clients, so both generations work. GET on the same path returns a human-readable descriptor instead.

Adding it to a client

What the agent sees

tools/list returns one tool. One processor is one job, carrying its input schema and its price:
The cost is in the description on purpose: an agent deciding whether to call a tool should see the price where it sees the purpose.

Paying for a call

Discovery is free. tools/call is the only method that costs anything. With no payment, the call comes back as a tool-level error carrying the HTTP status, not a protocol failure, because “you need to pay” is a normal answer the agent should act on:
Send an X-Payment header and it runs. Any x402 client can produce one; MCP clients that support custom headers pass it straight through.
One payment buys exactly one run, enforced across transports. The same X-Payment submitted over MCP and plain HTTP simultaneously results in a single execution; the loser gets 409.

As a LangGraph node, without MCP

A processor is just an HTTP call, so it drops into a graph directly:
State lives in your graph. The MCP CALL is stateless: one input, one output, no session, though the processor on the other side may keep its own state between runs. What it does not do is remember anything about your graph.

Long-running calls

If a run outlives the sync window you get 202 with a poll_url and a run token. Send Prefer: respond-async to get that immediately rather than waiting.

Supported methods

Anything else returns -32601. Mcp-Method and Mcp-Name headers are honoured, and a header that contradicts the body is rejected. So a gateway metering your traffic can never disagree with what actually ran.