Roder
Capabilities

MCP integration

MCP is the language-agnostic path for tool servers that should stay outside the Roder process. roder-ext-mcp connects to configured streamable HTTP MCP servers at startup, lists their tools, and registers each remote tool through the same ToolRegistry and policy path as native tools.

Runtime model

  • Connect to configured streamable HTTP MCP endpoints during registry construction.
  • Discover tool schemas through the MCP tool listing flow.
  • Register MCP tools as remote tools with namespaced identities.
  • Route calls through Roder policy, approval, event, and result handling.
  • Skip offline servers with a warning in discovery mode, or fail startup in required-discovery mode.

Naming

MCP tools should be namespaced so provider-visible names do not collide with built-ins or native extension tools.

mcp.<server-name>.<tool-name>

Per-thread bearer identity

Remote clients can include mcpAuthToken when they callthread/start. Roder keeps that short-lived token in memory for the thread and forwards it as the bearer credential for MCP tool calls, falling back to the process-level MCP credential when a thread has no override.

This lets one shared Roder app server call the same MCP service on behalf of different users or organizations without placing identity tokens in global config. Clients should re-supply the token on each thread/start and rotate it with the upstream capability lifetime.

When to use MCP vs native extensions

  • Use MCP when a tool server already speaks MCP or should ship/deploy separately.
  • Use a native Roder extension when you need direct Rust integration, tighter lifecycle control, or hot-path performance.
  • Use process extensions when the external process needs to provide services beyond tools, such as inference engines, task executors, or subagent dispatchers.