[FEATURE] Generic remote MCP server integration for MCP gateways

Problem statement

Many organisations expose their internal systems through one MCP gateway: one HTTPS endpoint, one bearer token, and logs, metrics, dashboards, tickets, and in-house APIs behind it as MCP tools. The gateway is the sanctioned path to those systems because it already handles auth, audit, and allowlisting.

OpenSRE has no way to connect to a server like that. All of its MCP integrations are tied to one vendor (GitHub, PostHog, Sentry, X, groundcover); none accepts an arbitrary MCP server given only a URL and a token. So a backend the gateway already exposes as a tool, Splunk for example, is unreachable from OpenSRE unless someone writes a dedicated Splunk integration, duplicating what the gateway already provides.

The workaround is to point a vendor MCP integration at the gateway. I did this with sentry_mcp and SENTRY_MCP_URL. The connection works: opensre integrations verify sentry_mcp passes and the tool executor can call gateway tools. The problem is everything the agent and the operator see:

• The model believes it is talking to Sentry. The tools are list_sentry_tools and call_sentry_tool, the source is sentry_mcp, and their descriptions and use cases say "the configured Sentry MCP server". Asked to search Splunk, the model does not reach for them. It only does so when the prompt states explicitly that Splunk sits behind that server, and that steering has to be repeated in every turn. A scheduled run has nobody to do that.
• Error hints are Sentry's. A 401/403 tells the user to check SENTRY_MCP_AUTH_TOKEN for org:read scope, and a server that needs no token cannot be configured at all, because sentry_mcp requires one in HTTP mode.
• The Sentry slot is used up. sentry_mcp resolves to one catalog entry, so the real Sentry MCP server can no longer be connected alongside the gateway.
• The operator surface says Sentry. opensre integrations, the setup prompts, and the docs all describe Sentry, and nothing documents this configuration, so it is unsupported.

This is not a roadmap item on its own, but it gates scheduled tasks for these organisations: a scheduled agent that should check logs or metrics on a cron cannot reach them when they sit behind a gateway.

Proposed solution

Add one generic integration, working name remote_mcp, that connects to any MCP server speaking Streamable HTTP. It mirrors the existing x_mcp bridge shape (one discovery tool plus one named-call tool, connection settings injected from the verified integration) so the model and the reviewers already know the pattern.

Configuration

REMOTE_MCP_URL=https://mcp-gateway.example.internal/mcp
REMOTE_MCP_AUTH_TOKEN=your-token        # optional, sent as Authorization: Bearer

or interactively:

opensre integrations setup remote_mcp     # prompts for URL and optional token
opensre integrations verify remote_mcp    # connects, initializes, lists tools
# Remote MCP connected to https://mcp-gateway.example.internal/mcp; discovered 14 tool(s).

Store record shape, for the persistent store path:

{ "service": "remote_mcp", "status": "active",
  "credentials": { "url": "https://mcp-gateway.example.internal/mcp", "auth_token": "…", "timeout_seconds": 30 } }

Tools exposed to the agent

The URL and token are injected from the verified integration and hidden from the model's schema, so the model can only choose the tool name and arguments.

Example turn

user:  which tools does the gateway expose for logs?
agent: list_remote_mcp_tools(name_filter="logs search")
       -> splunk_search, loki_query
agent: call_remote_mcp_tool(tool_name="splunk_search", arguments={"query": "index=prod status=500", "earliest": "-15m"})
       -> {"text": "3 events …", "structured_content": {"count": 3, …}}

Behaviour

• Timeout bounds connect, initialize, and the call together, so a server that accepts a connection but never completes the handshake cannot hang a turn.
• 401/403 returns a hint naming REMOTE_MCP_AUTH_TOKEN; 404 hints that many servers serve MCP under /mcp; connection errors hint at URL and network. The mcp 2.x client's stand-in "Server returned an error response" is mapped to the same token hint.
• The token never appears in tool output, logs, or traced kwargs. A leading Bearer in the configured token is stripped.
• Registered like every other integration: catalog, registry, effective-integrations model, setup and verify commands, tool discovery, .env.example, env-var reference, and a docs page.

Out of scope for a first version (can follow if wanted): stdio and legacy SSE transports, custom headers other than Authorization: Bearer, and a named multi-server map.

Acceptance criteria

• opensre integrations setup remote_mcp and verify remote_mcp work against a Streamable HTTP server with and without a bearer token.
• The agent can discover and call a gateway tool in a chat turn without any vendor wording in the loop.
• Unit tests cover config normalisation, pagination, the wrapped-401 and mcp 2.x error paths, and that the model cannot override the injected URL or token.
• An env-gated live suite runs against a real server with a credential-free local fixture.

An implementation following this shape is ready on a branch and will be opened as a PR referencing this issue.