list_toolsLABSCO SUMMARY
Your agent sees a handful of meta-tools instead of hundreds of definitions.
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.
What it is
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.
What you get
- 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
Requirements
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.
Setup effort
One command — brew tap giantswarm/muster && brew install muster
USE CASES
Finding the right tool without loading every catalogue
Search by intent, pattern or label, then read the chosen tool's full schema before calling it.
Turning servers on only when needed
Start a downstream server for the task at hand and stop it when the investigation is over.
Adding a new server to the fleet
Validate the definition, register it, and confirm it appears in the aggregated catalogue.
Making a debugging path repeatable
Capture the sequence as a workflow so the next incident runs it deterministically instead of re-deriving it.
Checking what a workflow actually did
List executions and read the per-step results of the one you care about.
11 tools
Listed in project docs. Your client may show a different list.
describe_toolfilter_toolslist_core_toolscall_toollist_resourcesdescribe_resourceget_resourcelist_promptsdescribe_promptget_promptBEFORE YOU INSTALL
What to know first
Tools you get
11 tools named in the project's documentation.
Requires
muster on PATH
Where it runs
Both documented clients run the server on your machine.
INSTALLATION
Connect your client
Server setup
brew tap giantswarm/muster && brew install musterMCP Clients
Cursor
{
"mcpServers": {
"muster": {
"command": "muster",
"args": [
"standalone"
]
}
}
}VS Code
{
"servers": {
"muster": {
"command": "muster",
"args": [
"standalone"
]
}
}
}