Description
The native agent's MCP client supports Streamable HTTP transport, but the HTTP server config schema (openab-agent/src/mcp/config.rs) has no way to attach custom HTTP headers to MCP requests — it only supports URL, OAuth, tool filters, timeouts, and logging. dial constructs the transport directly from the URI (plus optional OAuth client), so a header-authenticated MCP endpoint cannot be used.
Proposed: add an optional headers map to the HTTP server config, e.g.
{
"mcpServers": {
"github": {
"url": "http://ghpool.openab.local:8080/mcp",
"headers": { "X-Octobroker-Key": "..." }
}
}
}
applied to every request the transport sends (rmcp supports header injection on the Streamable HTTP client). Env-var expansion for header values (e.g. ${OCTOBROKER_KEY}) would avoid persisting key material in the config file, since the agent process already receives [agent].env.
Use Case
The OAB fleet routes all GitHub access through a broker (octobroker) that authenticates agents with an X-Octobroker-Key header on /mcp. Every backend CLI in the fleet (codex, claude, opencode, kimi, devin, grok, antigravity, mimo) supports custom headers for remote MCP servers and is now migrated — the native-agent bot (b7) is the only one that cannot connect and still requires a long-lived GITHUB_TOKEN PAT in its environment. Custom header support closes the last zero-credential gap in the fleet.
Workaround considered: a stdio bridge (npx mcp-remote <url> --header ...) works but adds a node dependency and a second process for something the native HTTP client already does 95% of.
Description
The native agent's MCP client supports Streamable HTTP transport, but the HTTP server config schema (
openab-agent/src/mcp/config.rs) has no way to attach custom HTTP headers to MCP requests — it only supports URL, OAuth, tool filters, timeouts, and logging.dialconstructs the transport directly from the URI (plus optional OAuth client), so a header-authenticated MCP endpoint cannot be used.Proposed: add an optional
headersmap to the HTTP server config, e.g.{ "mcpServers": { "github": { "url": "http://ghpool.openab.local:8080/mcp", "headers": { "X-Octobroker-Key": "..." } } } }applied to every request the transport sends (rmcp supports header injection on the Streamable HTTP client). Env-var expansion for header values (e.g.
${OCTOBROKER_KEY}) would avoid persisting key material in the config file, since the agent process already receives[agent].env.Use Case
The OAB fleet routes all GitHub access through a broker (octobroker) that authenticates agents with an
X-Octobroker-Keyheader on/mcp. Every backend CLI in the fleet (codex, claude, opencode, kimi, devin, grok, antigravity, mimo) supports custom headers for remote MCP servers and is now migrated — the native-agent bot (b7) is the only one that cannot connect and still requires a long-livedGITHUB_TOKENPAT in its environment. Custom header support closes the last zero-credential gap in the fleet.Workaround considered: a stdio bridge (
npx mcp-remote <url> --header ...) works but adds a node dependency and a second process for something the native HTTP client already does 95% of.