Robusta MCP server: there isn't one, and why

HolmesGPT's documentation has fifteen MCP-named pages, and every one of them is about calling someone else's server. That is why Robusta publishes none. What that means for your own agent.

Last verified 31 August 2026 · from Robusta and HolmesGPT documentation, their GitHub repositories and the MCP registry

This page is one of 90 in a directory of monitoring and developer tools. Each page checks what an AI coding agent can get out of the tool through its MCP server, the connector that lets the agent query the tool directly.

What is the Robusta MCP server, and is it usable?

Robusta is a Kubernetes observability and automation platform, and HolmesGPT is its open-source investigation agent. HolmesGPT's job is to gather evidence about a failing workload, which is what makes it a natural MCP client.

Its documentation covers toolsets, remote servers and OAuth, all from the calling side. The integrations repository goes further and ships ready-made connections to servers other vendors publish.

What does not exist is the reverse: no tool lets your agent ask Robusta what it found, which alerts fired or what an automation did.

Every one of the 90 vendors in this directory gets the same four checks. Robusta passes 0 of them.

Robusta operates in production observability through HolmesGPT, which ships third-party servers rather than exposing Robusta itself.

Robusta and your coding agent both want to be the investigator. HolmesGPT gathers evidence and reaches conclusions inside Robusta; it does not hand those conclusions to another agent. If your agent needs cluster evidence, it has to gather its own through a different connector.

What can an AI agent do with Robusta?

An agent can call nothing in Robusta: no tool returns its alerts, automations or investigations. The confusion comes from how much MCP documentation Robusta publishes.

How to configure Robusta MCP for agents

1. 1

   Prefer streamable-http

   The documentation marks it recommended for new integrations and marks sse deprecated, so a config written against SSE is being written against the transport on the way out.

2. 2

   Check the transport before you pick a server

   The documentation names Dynatrace MCP as a server that relies exclusively on stdio, which the Holmes container cannot run without a bridge.

3. 3

   Plan a bridge only for stdio on Kubernetes

   The CLI runs stdio servers directly. In a cluster the Holmes container lacks the dependencies to do so, which is what Supergateway is documented to solve.

4. 4

   Decide where the server runs

   The documented options are a local Docker container for CLI use, or a pod and ClusterIP service reached at a cluster-internal address.

5. 5

   Write the description for humans, not the model

   Robusta states in the example comment that the description is not seen by the AI model and is just for users.

Paste this into your agent’s instructions

HolmesGPT reaches only the servers named in its own configuration. A tool can therefore be missing because its server speaks stdio and was never bridged, which is a configuration gap rather than an absence of data.

When HolmesGPT answers using a remote MCP server, state:
- Which configured server the evidence came from.
- That HolmesGPT reads only the servers listed in its
  config, so other sources may exist and be unreachable.
Never state that data does not exist. State which servers
are configured, and that others may not be connected.
Write your answer in ASD-STE100 Simplified Technical
English. Use short sentences with one idea in each.

Do you need the MCP server at all?

No. Robusta consumes servers rather than publishing one. For an agent that queries Kubernetes directly, Dynatrace exposes Kubernetes events as tools and Grafana reaches cluster metrics and logs through its datasources.

For cluster logs specifically, OpenSearch and Elastic search whatever your pipeline ships them.

HolmesGPT remains worth running on its own terms. It is open source, it investigates well, and its answers live in Robusta rather than in your editor.

Run HolmesGPT for its own investigations. Connect an observability server when your agent needs to gather cluster evidence itself.

Robusta MCP server setup

Nothing here installs a Robusta server, because there is none. This is how a remote MCP server is attached to HolmesGPT, which is the question a reader on this page actually has.

HolmesGPT reads three transports. streamable-http is the recommended one for new integrations, stdio is supported, and sse is deprecated. The constraint is narrower than a transport limit: on Kubernetes, stdio cannot run inside the Holmes container, so a stdio server needs a bridge pod in front of it.

Credentials never sit in the server list itself. They travel either as headers referencing HolmesGPT environment variables, or as environment variables on the bridge process.

holmes:
  mcp_servers:
    mcp_server_2:
      description: "MCP server that runs in my cluster"
      url: "http://<service>.<namespace>.svc.cluster.local:<port>"
      config:
        headers:
          key: "{{ env.my_mcp_server_key }}"

helm upgrade robusta robusta/robusta \
  --values=generated_values.yaml \
  --set clusterName=<YOUR_CLUSTER_NAME>

docker run --env-file .env -it --rm -p 8003:8003 \
  supercorp/supergateway \
  --stdio "npx -y @dynatrace-oss/dynatrace-mcp-server@latest /" \
  --port 8003 --logLevel debug

mcp_servers:
  mcp_server_1:
    description: "Dynatrace observability platform."
    url: "http://localhost:8003/sse"

Every other client

Each block below is the configuration for one client, with the file path and the key that client expects.

env:
  - name: OAUTH_CLIENT_SECRET
    valueFrom:
      secretKeyRef:
        name: dynatrace-credentials
        key: client_secret

holmes ask -t custom_toolset.yaml \
  "Using dynatrace what issues do I have in my cluster?"

Read-only access, permissions and security

• Check which documentation you are reading

  docs.robusta.dev now serves a redirect stub, and the page it points at returns 404. The maintained source is the remote-mcp-servers.md file in the HolmesGPT repository, which is where the transport designations above come from.

• Credentials belong in environment variables, not the values file

  Header values are documented as "{{ env.my_mcp_server_key }}", referencing a HolmesGPT environment variable rather than an inline secret.

• A bridge holds the real credentials

  When Supergateway fronts a stdio server, the upstream API keys live in that process, passed by --env-file locally or by secretKeyRef in a cluster.

• The bridge example disables CORS and health endpoints

  Supergateway's startup log shows CORS: disabled and Health endpoints: (none). Do not treat an in-cluster deployment of it as a hardened service.

• Descriptions are not a control

  Robusta notes the description is not seen by the model, so it cannot be used to constrain behavior.

• stdio needs a bridge in a cluster

  The Holmes container cannot run a stdio server directly, so Supergateway fronts it, which limits the surface but also means the bridge becomes the trusted component.

Troubleshooting

You cannot find a Robusta MCP server to install

There is not one. HolmesGPT is a client. Its documentation covers connecting to other people's servers, and robusta-dev/holmes-mcp-integrations packages third-party servers for it to call.

The MCP server will not connect to HolmesGPT

Check the transport. streamable-http is the recommended route and sse is deprecated. A stdio server such as Dynatrace MCP cannot be attached from a cluster without a bridge in front of it.

A stdio-only server needs to be used anyway

On Kubernetes, put a bridge in front of it: the Holmes container cannot run stdio directly. Robusta documents Supergateway for this, run as a pod with a ClusterIP service. The CLI needs no bridge.

The bridge starts but HolmesGPT still sees nothing

Confirm the URL points at the SSE path. Supergateway logs its SSE endpoint as http://localhost:8003/sse, and the config URL must match that rather than the bare host and port.

A header credential is not reaching the server

Header values use HolmesGPT environment variables through {{ env.name }} interpolation. The variable must exist in the HolmesGPT environment for the substitution to produce anything.

Helm values were edited but nothing changed

The values need applying. Robusta documents helm upgrade robusta robusta/robusta --values=generated_values.yaml --set clusterName=<YOUR_CLUSTER_NAME>.

Robusta MCP server: Reference

What engineers report

There is no server to review, so this section records what the repositories and documentation show.

Robusta and HolmesGPT documentation, their GitHub repositories and the official MCP registry checked on 24 August 2026. The HolmesGPT repository now resolves to its own organization rather than robusta-dev.

Should you connect an agent to Robusta?

There is nothing to connect: this is the agent side of MCP. Best for running HolmesGPT alongside a separate observability connector for your own agent.

Strongest fit

Teams who want an open-source Kubernetes investigation agent that can call the tools they already run.

Main advantage

HolmesGPT connects out to other people's servers, and holmes-mcp-integrations ships those connections ready-made.

Main weakness

Nothing exposes Robusta to your agent, so its investigations cannot be queried from outside.

Operational risk

On Kubernetes a stdio server needs a bridge process, which then holds the upstream credentials. Robusta's own published docs URL redirects to a page that no longer exists.

Frequently asked questions