That is the whole trade: filter_tools returns a bounded, ranked page so finding a tool costs a few hundred tokens, and call_tool runs whatever it found. Once a sequence works, promoting it to a workflow makes the next run deterministic — the agent stops rediscovering the path every time.
A control plane for MCP servers. It manages their processes, aggregates their tools, and presents your agent with a small set of meta-tools for discovery and execution — plus workflows that turn a sequence that worked into a repeatable definition.
- list_tools, describe_tool, list_core_tools — enumerate what is available and read one tool's full schema
- filter_tools — cheap ranked discovery by glob pattern, description substring, natural-language query or label facets, paginated with total and truncated in the response
- call_tool — execute any aggregated tool by name, so client context holds the meta-tools rather than the whole catalogue
- list_resources, describe_resource, get_resource and list_prompts, describe_prompt, get_prompt — the same pattern for resources and prompts
- core_mcpserver_list, create, get, update, delete, validate — register and manage downstream MCP servers
- core_service_list, start, stop, restart, status — lifecycle control over those server processes
- core_workflow_list, create, get, available, update, delete, validate — define workflows that chain tool calls with templated arguments
- core_workflow_execution_list and core_workflow_execution_get — what ran, and what each step returned
- core_config_get, save, reload and the aggregator config pair — read and hot-reload configuration
- Destructive tools are blocked by default; --yolo overrides
Install with Homebrew from the giantswarm tap, or build from source with Go. Run muster serve to start the control plane, register each downstream server with a small YAML file, and point your IDE at muster as an MCP server. No credentials of its own — each downstream server keeps its own.
One command — brew tap giantswarm/muster && brew install muster