Skip to main content
Glama
sipyourdrink-ltd

Bernstein - Multi-agent orchestration

bernstein_run

Submit a goal to queue a multi-agent orchestration run and receive IDs to poll until completion.

Instructions

Start an orchestration run by posting a task to the Bernstein server.

A run executes real work and takes minutes to hours. This call returns as soon as the run is queued, not when it finishes. Do not re-issue it while waiting: that starts a second run. To follow the run, wait poll_after_ms and then call bernstein_run_status, passing either the returned task_id or the returned run_id. Poll it until status is terminal (completed, failed or cancelled).

Args: goal: Description of what you want Bernstein to accomplish. role: Specialist role to assign (backend, frontend, qa, security, …). priority: 1=critical, 2=normal, 3=nice-to-have. scope: Task scope - small, medium, or large. complexity: Task complexity - low, medium, or high. estimated_minutes: Rough time estimate in minutes. parent_task_id: When set, the run is created as a subtask of this task, and the parent transitions to waiting_for_subtasks.

Returns: JSON with the created task ID, title and status, plus the run_id naming the run journal and the advisory poll_after_ms delay before the first poll. When the call itself is task-augmented (the client sent task in the request params), a Tasks-extension CreateTaskResult is returned instead so the client can poll the run.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
goalYes
roleNo
scopeNo
priorityNo
complexityNo
parent_task_idNo
estimated_minutesNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
_meterYes
resultYes
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses the asynchronous nature, the fact that it returns when queued, and details about parent_task_id and return formats. Warns against re-issuing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

All sentences are meaningful; the description is well-organized into a summary, behavioral notes, Args, and Returns sections. No redundant content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers all aspects: async behavior, polling instructions, parent-child task relationship, terminal statuses, and return format. The complexity of 7 parameters and async execution is fully addressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema description coverage, the description includes a thorough Args section that explains every parameter (goal, role, priority, scope, complexity, estimated_minutes, parent_task_id), adding critical meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states 'Start an orchestration run', which is a specific verb+resource. It distinguishes from siblings like bernstein_run_status and bernstein_cancel by explaining follow-up and cancellation behavior.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear when-to-use (post a task to start a run) and when-not-to (do not re-issue while waiting). Suggests alternative bernstein_run_status for polling and explains the flow.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sipyourdrink-ltd/bernstein'

If you have feedback or need assistance with the MCP directory API, please join our Discord server