Can You Use an RLM Through an MCP Server?

The short version: yes, in two directions. You can put an RLM behind an MCP tool, so a host such as Claude Code calls it. You can also give the RLM's REPL access to MCP tools. Neither main RLM library ships an MCP server, so you write a thin wrapper. Pass the large context by path or URI, give the server its own model key, and plan for long tool calls.

What does "an RLM through MCP" mean?

The Model Context Protocol (MCP) connects an AI application (the host) to servers that expose tools, resources and prompts. A Recursive Language Model is an inference loop. The RLM paper describes a paradigm that "treats long prompts as part of an external environment." The model writes code in a REPL to inspect the prompt and call itself on pieces of it.

The two fit together in two ways:

• RLM as a tool. An MCP server exposes a tool such as rlm_query. The host model calls it when an input is too large for its window.
• MCP tools inside the RLM. The RLM is the application. Its REPL code calls MCP tools as Python functions.

The first direction is what most people mean. It is also the one with more design traps.

Do the RLM libraries ship an MCP server?

No. We read both on October 12, 2026. The README of the reference RLM library does not mention MCP. It lists REPL environments (local, ipython, docker, modal, prime, daytona, e2b) and model clients. The dspy.RLM API page does not mention MCP either.

Community projects fill the gap. One example is rlm-mcp, a small MIT-licensed repository with six tools, including rlm_load_file and rlm_execute_code. Its README says "Claude is the brain, RLM is the hands." The host model writes the Python, and the server runs it. The README describes no sub-model calls from the server.

That design is closer to a persistent REPL tool than to the loop in the paper. In the paper, code inside the REPL calls the model again. If you want that behavior, the server must run the full loop and hold a model client. Our post on dspy.RLM and the reference library covers which library to wrap.

Can the server borrow the host's model through MCP sampling?

It could, but do not build on it now. Sampling is the MCP feature that lets a server ask the client's model for a completion. The 2025-06-18 spec says the flow enables servers to use the model "with no server API keys necessary." For an RLM server, that looked ideal: each llm_query sub-call would become one sampling/createMessage request.

Three facts work against it:

• Sampling is deprecated. The 2026-07-28 changelog deprecates the Roots, Sampling and Logging features. The suggested migration is to "integrate directly with LLM provider APIs instead of Sampling." The deprecated features registry gives the earliest removal as the first revision released on or after 2027-07-28.
• The request shape changed. The same revision replaces server-initiated requests such as sampling/createMessage with a Multi Round-Trip Requests pattern. The server returns an input_required result, and the client retries the original request with the answers. An RLM run with dozens of sub-calls would need dozens of retries of one tool call.
• The spec asks for a human check. The sampling page says "there SHOULD always be a human in the loop with the ability to deny sampling requests." It also says model hints are advisory: "clients make final model selection." You cannot be sure which model answers a sub-call.

Client support was never certain either. A client must declare the sampling capability. The Claude Code MCP page documents elicitation and resources. We found no sampling section on it.

So give the server its own model client and API key. This also lets you choose a cheaper model for sub-calls than the host model.

How should the large context reach the RLM?

By reference. This is the most important design decision. If the host model passes a 2 MB log as a tool argument, the host model must first write those tokens. The text is then in the host's context window, and the RLM has no purpose.

Use one of these instead:

• A file path. The tool takes path and question. The server reads the file and stores it as the REPL variable. The community server above works this way with rlm_load_file("/var/log/app.log").
• A resource URI. The tool takes a URI, and the server resolves it. The 2026-07-28 changelog recommends tool parameters and resource URIs as the way to pass files, now that Roots is deprecated.
• A server-side handle. One tool loads the data and returns a short handle. Later calls pass the handle. The 2026-07-28 changelog describes "server-minted handles passed as ordinary tool arguments" for state across calls.

The return value needs the same care. Claude Code warns when an MCP tool output exceeds 10,000 tokens and limits output to 25,000 tokens by default. Return the final answer and a short trace summary. Write the full trajectory to a file and return its path.

What about timeouts on long RLM runs?

An RLM run can take minutes. A tool call that looks hung gets cancelled. The 2025-06-18 lifecycle page says implementations "SHOULD establish timeouts for all sent requests." It adds that they "MAY choose to reset the timeout clock when receiving a progress notification," but "SHOULD always enforce a maximum timeout."

Progress is opt-in. Per the progress page, the caller includes a progressToken in the request, and the receiver may send notifications/progress. Send one after each root iteration, with a message such as "iteration 4 of 30." Do not depend on it to extend the limit. The Claude Code docs say the per-server timeout is "a hard wall-clock limit per tool call, and progress notifications from the server don't extend it."

Three controls help:

1. Set the RLM's own limit below the client limit. The reference library has max_timeout, which stops the run and returns the "best answer if available." It also has max_budget in USD.
2. Cap the loop. See our post on max_iterations.
3. For long jobs, split the tool: one call starts the run and returns a handle, and a second call polls it. The MCP tasks feature does this at protocol level. It was experimental in 2025-11-25, and 2026-07-28 moved it into an official extension, so check your client first.

Can the RLM's REPL call MCP tools?

Yes, through the tool hooks that both libraries have. The reference library's constructor takes custom_tools, a dict of functions available in the REPL, and custom_sub_tools for sub-calls. dspy.RLM takes tools, described as "tool functions or dspy.Tool objects callable from interpreter code."

DSPy has a converter. Its MCP tutorial builds tools with dspy.Tool.from_mcp_tool(client, tool). The tutorial uses ReAct, not RLM, and notes that "MCP tools are async by default." Test an async MCP tool from the RLM interpreter before you depend on it. A plain sync wrapper function is the safe path.

Two cautions apply. In an isolated environment, the reference README says custom tools must be "Python code strings or JSON-serializable values," because host callables cannot cross the process boundary. A live MCP client session is a host callable. Also, every MCP tool you add is a new action for model-written code. Our REPL sandbox post explains why that matters for untrusted input.

The bottom line

You can use an RLM through an MCP server, but you build the server yourself. Wrap the reference library or dspy.RLM in one tool that takes a path and a question. Give the server its own model key, because MCP sampling is deprecated as of the 2026-07-28 revision. Keep the big input out of the tool arguments and the big trace out of the result. Set the RLM timeout below the client's tool timeout, and send progress after each iteration.