# muster [Health: Active]

**Category:** 🔗 Aggregators  
**Repository:** https://github.com/giantswarm/muster  
**GitHub Stars:** 39  
**Views:** 0  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/muster

## Description
Aggregating MCP server: one authenticated endpoint for every MCP server a platform runs, with meta-tool discovery, toolsets, OAuth 2.1 and SSO through Dex, and Kubernetes custom resources

## Claude Desktop Quick Installation
Remote MCP endpoint (confidence: high). Install path detected from listing signals. Add as a URL/SSE server in your client:

```json
"mcpServers": {
  "muster": {
    "url": "http://localhost:8090/mcp"
  }
}
```

## Documentation

## What muster does

The muster MCP server provides one MCP endpoint for multiple downstream servers. It can connect to servers using stdio, streamable HTTP, or SSE, then expose their tools through a shared interface. Registered servers are health-checked and reconnected when needed. Tool names are namespaced in the form `x_<server>_<tool>`, while servers with equivalent tools for different targets can be grouped into a family with an instance argument.

Rather than sending an entire catalogue to an MCP client, muster provides meta-tools for listing, filtering, describing, and calling tools. Resource and prompt operations have corresponding discovery and invocation support. Results are paged and summarised, and relevance-based filtering helps an agent locate a tool with a smaller context budget.

The project fits the 🔗 Aggregators category because its primary role is to combine MCP services behind a common gateway. It also supports access control, workflow execution, Kubernetes resources, and operational telemetry.

## How it works

An MCP client connects to `/mcp` and receives the meta-tool surface. The client can filter or inspect the catalogue, then request a call by tool name. muster resolves that name to the registered downstream server, attaches the session credentials where applicable, and forwards the request.

Toolsets define which servers or tools a request may see and invoke. They can use built-in presets such as `read-only`, administrator-defined presets, or inline selectors based on servers, patterns, workflows, and labels. This lets an agent operate against a deliberately limited tool surface.

OAuth 2.1 protects the endpoint, with Dex used for SSO. A user’s identity token can be forwarded to downstream MCP servers that accept it. Remote servers with separate OAuth requirements support browser-based sign-in, and AWS-hosted servers can use SigV4 signing. OpenTelemetry traces, Prometheus metrics, and structured logs cover sessions, servers, and calls.

## Setup and configuration

Install the muster MCP server from a Homebrew tap, download a release binary, or use `go install github.com/giantswarm/muster/v5@latest`. Running `muster serve` starts the HTTP endpoint at `http://localhost:8090/mcp`. Servers can be registered from the CLI, including stdio commands with arguments and automatic startup.

For desktop or IDE use, `muster standalone` runs the aggregator and a stdio bridge in one process. A running local or remote instance can instead be connected through `muster agent --mcp-server`. Remote OAuth sessions are initiated with `muster auth login`; browserless environments can print the sign-in URL for manual completion.

Kubernetes deployment uses the published Helm chart. The chart includes custom resource definitions, RBAC, network policies, Prometheus rules, and a Grafana dashboard. `MCPServer`, `Workflow`, and `WorkflowExecution` resources configure registered servers and durable workflow execution.

## Tools and capabilities

- Aggregate stdio, streamable HTTP, and SSE MCP servers.
- Discover and call tools through `list_tools`, `filter_tools`, `describe_tool`, and `call_tool`.
- Expose resource and prompt meta-tools.
- Apply presets and selectors through the `X-muster-Toolset` header.
- Define deterministic workflows with templates, conditions, `forEach`, and parallel steps.
- Provide OAuth 2.1, Dex SSO, token forwarding, and SigV4 support.

## Limitations and notes

The README does not specify downstream compatibility beyond MCP transport types and the authentication options described above. OAuth-protected deployments may need Dex and, for multiple replicas, Valkey-backed sessions. Client connections to a remote protected instance require an authentication step. Kubernetes mode requires Helm and the cluster resources described by the chart.

The muster MCP server does not replace the downstream systems it connects to; it routes discovery and calls to registered MCP servers. Its available tools therefore depend on those registrations, their health, and the toolset assigned to the request.

_Full upstream README: https://allmcps.com/mcp/muster/readme_