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.