claude-sonnet-4-5-20250929 hardcoded in btw_tool_agent_subagent?

[Tarzno]

I have installed R with mcptools and btw in a pixi venv, and have linked this as an MCP server to Claude Desktop running Claude Sonnet 4.6 and to LM Studio running a local LLM. Everything is working as expected except for the btw_tool_agent_subagent. It seems that this tool has claude-sonnet-4-5-20250929 hardcoded. If I set the actual model in btw.md, this is ignored.

I am also wondering, if something as complex as a subagent in a dedicated environment is implemented, why then is there no simple tool to just execute R code (btw_tool_run_rscript). It seems as if I am getting something conceptually wrong.

[Tarzno]

I now see that execution of custom Rscript code can be implemented by a server.R file using ellmer. For my use case that will make the btw_tool_agent_subagent obsolete. Still, it seems that this tool has an older Claude Sonnet version hardcoded. At least this is what my active R session reports when Claude Desktop with Claude Sonnet 4.6 tries to call this tool, after which to tool call fails. But again, maybe I do not fully grasp the concept behind this.

[Tarzno]

Thank you for the quick fix @gadenbuie!

After some tinkering, I realized that there is actually a tool named btw_tool_run_r, which however does not seem to be part of the standard btw tools that are exposed with mcptools::mcp_server(tools = btw_tools().

For those, who are struggling with the same problem:
My makeshift solution is a server.R script that I load with R that lives in a pixi venv. This provides control over which tools are actually exposed. This script also tackles a conversion problem to S7 objects that I encountered. The script is attached (remove the txt extension and modify the working directory at the beginning of the script.

server.R.txt

The json to actually use this in LM Studio or Claude Desktop in my case is:

"r-mcptools": {
  "command": "pixi",
  "args": [
    "run",
    "--manifest-path",
    "/Volumes/scratch/AI/mcp/R",
    "Rscript",
    "/Volumes/scratch/AI/mcp/R/server.R"
  ]
}

Since my R installation lives in a pixi venv in /Volumes/scratch/AI/mcp/R, you will obviously need to adapt this to point to your own R working directory with the server.R script.

If somebody has a more direct and elegant solution, please let me know. I am just beginning with this and still have not fully understood, how all of this is supposed to work.

[gadenbuie]

After some tinkering, I realized that there is actually a tool named btw_tool_run_r, which however does not seem to be part of the standard btw tools ... exposed with btw_tools()

Hi @Tarzno, that's right, btw_tools() doesn't include the btw_tool_run_r() tool unless you explicitly ask for it, either by including it by name, e.g. btw_tools("run_r"), or by setting an R option or environment variable. For your use case, I'd recommend directly requesting the tool, but you can find more details about how to enable the tool here: https://posit-dev.github.io/btw/reference/btw_tool_run_r.html#enabling-this-tool

---

For your use case, though, you might want to check out another package by a Posit open source dev called mcp-repl. It provides a stateful REPL for execution of R code in one long-lived process.

---

Thanks for reporting the issue with the subagent tool. It should be fixed by #186 which I'll merge soon. I just released btw 1.2.1, so it won't make it to CRAN for at least another two weeks.

[Tarzno]

@gadenbuie: Thank you for bringing mcp-repl to my attention. That is indeed a much more straight-forward and cleaner solution with the added benefit of persistent sessions / object persistence. Hence I decided to run R code via repl, while keeping btw with its standard set of tools for all of its nice convenience functions (browsing CRAN and help pages etc.). Initial test of this setup worked great. Thanks again!