Bernstein - Multi-agent orchestration
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 |
|---|---|
| tasks | {
"list": {},
"cancel": {},
"requests": {
"tools": {
"call": {}
}
}
} |
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| bernstein_runA | Start an orchestration run. A run does real work and takes minutes to hours; the call returns once the run is queued, not when it finishes. Do not re-issue it while waiting, that starts a second run. Follow the run with bernstein_run_status, passing either the returned task_id or the returned run_id, after waiting the returned poll_after_ms. Pass parent_task_id to create the run as a subtask of an existing task. The queued orchestration writes project state and starts agent work. Host effects: writes files; spawns agent processes; makes network requests. Set template=administrative to create an empty audited manual container without a planner or agent processes; goal may be omitted for this template. |
| bernstein_subscribeB | Wait for one future role task notification over authenticated SSE, then unsubscribe. Host effects: makes network requests. |
| bernstein_statusA | Liveness, task counts, and cost in one read. Pass status to include the matching tasks; pass detail=true for full per-role and per-task rows. Retrieves data from the Bernstein server without changing it. Host effects: makes network requests. |
| bernstein_claimA | Claim the next eligible task for an agent. This changes task assignment state on the Bernstein server. Host effects: makes network requests. |
| bernstein_create_taskA | Create a bare task without triggering orchestration or spawning agents. The task enters the backlog and is immediately claimable via bernstein_claim by any session matching its role. Host effects: writes files; makes network requests. |
| bernstein_post_messageB | Post a progress message to a task mailbox on the Bernstein server. Host effects: makes network requests. |
| bernstein_post_artifactC | Post a versioned artifact to a task on the Bernstein server. Host effects: makes network requests. |
| bernstein_cancelA | Cancel one task and its subtask tree; the orchestrator keeps running. Cancellable statuses: open, claimed, in_progress, blocked, waiting_for_subtasks, planned. An already-terminal task is reported, not treated as an error. This changes task state on the Bernstein server. Host effects: makes network requests. |
| bernstein_shutdown_orchestratorA | Shut down the ENTIRE Bernstein orchestrator for this project, including every run and worker; use bernstein_cancel to stop one task while the orchestrator keeps running. Writes the local SHUTDOWN signal file. Host effects: writes files. |
| bernstein_approveA | Sign off a finished result only when the task is in pending_approval; every other status is refused. This completes the task on the Bernstein server. Host effects: makes network requests. |
| bernstein_completeA | Report a task result only from a worker-held state: open, claimed, or in_progress; every other status is refused. This completes the task on the Bernstein server. Host effects: makes network requests. |
| bernstein_run_statusA | Poll a verifiable handle for a run started with bernstein_run. Accepts either identifier that call returned: the task_id or the run_id. Reads the local run journal and audit evidence without changing them. Host effects: reads files. |
| bernstein_task_capsuleA | Read a task capsule together with its local journal and audit evidence. With verify=true, verification may create the install audit key if it is absent. Host effects: reads files; writes files. |
| load_skillA | List available skills when name is omitted, or load a named skill body, reference, or script file contents. Returns file contents as text; executes nothing. Host effects: reads files. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| orchestrate_goal | Plan a Bernstein orchestration run for a single goal. |
| triage_failed_tasks | Triage the most recent failed tasks and propose next actions. |
| cost_recap | Summarise Bernstein cost by role for a stated window. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| bernstein_capability | Runtime capability card: transports, auth, tiers, meter, spec rev. |
| skill_index | Compact index of loadable Bernstein skills and their content hashes. |
| lineage_stats | Summary counts over the entire lineage log. |
TDQS
Scored across 14 tools
Each tool targets a distinct action+state, and the descriptions explicitly cross-reference the confusing neighbors (e.g. bernstein_run vs bernstein_run_status vs bernstein_status; bernstein_cancel vs bernstein_shutdown_orchestrator; bernstein_complete vs bernstein_approve gated by task status). Genuinely ambiguous pairs are pre-empted in the text, so an agent can reliably select. The only overlap is status-read surfaces (run_status, status, task_capsule), and those are separated by what they read.
Most tools use a bernstein_ prefix with a verb or verb_noun form (create_task, post_message, post_artifact, cancel, claim, approve, complete), which is predictable. Deviations exist: bernstein_task_capsule is noun-only, load_skill drops the server prefix, and bare verbs sit beside verb_noun forms. Still readable and largely systematic.
14 tools for an orchestration server that must cover run lifecycle, task lifecycle, messaging, and artifacts is well-scoped. No tool looks redundant enough to be dropped, and nothing essential is obviously missing from the count.
The surface covers the main lifecycle: queue a run, create/claim/complete/approve/cancel tasks, post messages and artifacts, poll status, shut down, and inspect capsules. Gaps remain around reading existing mailbox messages (post_message and subscribe exist but no explicit mailbox fetch) and releasing/reassigning a claimed task. These are workable but could force agent workarounds.