maestro
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_profilesA | List the agent profiles a session can be launched with (name, role, model, effort). |
| get_profile_detailsB | Return a profile's full system prompt and settings. |
| launch_sessionA | Start a new session: one full Claude Code process in its own tmux window. Blocks until Claude shows its input box (up to ~90 s) so a failed start is
reported here rather than discovered later.
|
| send_session_messageB | Queue a message for a terminal; it is pasted as soon as the terminal is idle. |
| get_terminal_statusB | Live status of one terminal: idle, processing, completed, waiting_user_answer, error. |
| get_terminal_outputB | Read a terminal's output. |
| read_session_outputB | Read output by terminal id, or by session name when the session has one terminal.
|
| list_sessionsB | All running sessions with their terminal counts. |
| get_session_infoC | A session and every terminal in it, with live statuses (oldest terminal first). |
| list_worktreesA | Every live terminal that runs in its own git worktree: what there is to merge. Each entry has terminal_id, status, repo, path and branch. Merge a finished
one with |
| remove_worktreeA | Remove an orphaned checkout listed by list_worktrees (leftovers are committed first; the branch stays if unmerged). |
| shutdown_sessionB | Close every terminal of a session and the session itself. |
| answer_promptA | Answer the question a terminal is blocked on. Only valid while its status is waiting_user_answer.
|
| interruptA | Stop a terminal's current turn (Escape), e.g. when a worker is going in circles. Only while its status is processing or waiting_user_answer (an idle prompt has nothing to interrupt and is refused). Returns the status observed ~2 s later (normally idle or completed); queued messages are then delivered as usual. |
| restart_terminalA | Replace a terminal's Claude with a fresh one: same id, profile, model, directory and inbox. Use when its status is |
| fleet_statusA | The whole fleet in one call: every session, every terminal, and who needs you. Prefer this over list_sessions plus a get_session_info per session: it is
one call and one block of context instead of one per session. Each terminal
carries status, progress, stuck, model, profile, working directory,
worktree and pending_messages. |
| wait_forA | Block until a terminal finishes, asks something or dies -- instead of polling. This holds your conversation until it returns. From Claude Code, prefer a
background watch on Returns as soon as one watched terminal reaches one of This is the loop to use while a fleet runs: wait, act on what came back (read its output, answer its question, restart it), wait again. Polling get_terminal_status in a loop costs a call and a turn every few seconds and tells you nothing in between. |
| launch_sessionsA | Launch several sessions at once, in parallel. One call for a whole fleet. Each entry takes the same fields as launch_session: Ten sessions launched one by one cost ten calls and several minutes of waiting; this is one call and about as long as the slowest one. |
| broadcast_messageA | Queue one message for many terminals at once (the whole fleet when none is named). For the things you say to everyone: a change of plan, "commit what you have and report", a constraint you forgot. Each terminal receives it when it is next idle, exactly as send_session_message does. |
| get_usageA | How much of the Claude subscription is left: the 5-hour and weekly windows. Worth a look before opening a large fleet, and when deciding whether to run
the stronger model everywhere. Percentages are utilisation, so 100 means
spent; |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 20 tools
Several tools overlap: get_terminal_output and read_session_output both read terminal output, get_terminal_status/list_sessions/get_session_info/fleet_status all report status, and send_session_message vs broadcast_message differ only in cardinality. The descriptions do a good job steering the agent toward the aggregate tools (fleet_status, wait_for, launch_sessions), which mitigates but does not eliminate the ambiguity.
Mostly consistent verb_noun snake_case (list_profiles, launch_session, send_session_message, shutdown_session, remove_worktree). A few outliers break the pattern: interrupt, wait_for, and fleet_status are not verb_noun, but naming remains readable and predictable overall.
20 tools for an agent-fleet orchestration server is on the heavy side but justified by the breadth of the domain (profiles, launch, messaging, monitoring, worktrees, usage). Aggregate tools like launch_sessions, broadcast_message, and fleet_status absorb many one-off calls, so the count is mostly earned.
The surface covers the full lifecycle: profile discovery, session/terminal launch, messaging, monitoring, interruption, restart, shutdown, worktree management, and usage. Minor gaps like an explicit kill/delete-terminal tool (only shutdown_session exists) and worktree merge automation are workable around with plain git.