Skip to main content
Glama
sipyourdrink-ltd

Bernstein - Multi-agent orchestration

bernstein_approve

Approve a task stuck in pending_approval to finish it with your note. Refuses non-pending tasks with a clear error.

Instructions

Sign off a finished result that is waiting on a decision.

The tool reads the task first and acts only on pending_approval: the work has run, the result is held for a decision, and accepting it completes the task with note as the result summary.

Every other status is refused with a structured error naming the current status, and no state-changing request is sent:

  • planned - the task is held by plan mode. That decision is recorded on the plan, not on the task, so approve the plan (bernstein plan approve <plan_id>). Releasing one task would start the work while the plan is still undecided.

  • open, claimed, in_progress, blocked, failed, terminal states, ... - there is no approval to grant. Use bernstein_complete to report work you are executing, bernstein_update to report a blocker on the task mailbox, or cancel the task to abandon it.

Args: task_id: ID of the task to approve. note: Approval note recorded as the result summary.

Returns: JSON with the task id, its new status, and which approval was granted - or a structured refusal naming the current status.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNo
task_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

The description fully discloses behavior: it reads the task first, only acts on pending_approval, refuses others with structured error naming the current status, and sends no state-changing request for refusals. It covers all statuses with detailed explanations.

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?

The description is well-structured with clear sections (purpose, behavior, args, returns). It is front-loaded with the main purpose and then provides detailed but focused information. Every sentence is informative without redundancy.

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?

Given the tool's complexity (multiple status handling, refusals) and absence of annotations, the description is comprehensive. It explains all status cases, the return format (JSON with task id, new status, approval granted), and the conditions for approval. No gaps identified.

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?

Even though schema description coverage is 0%, the description has an Args section explaining both parameters: task_id as 'ID of the task to approve' and note as 'Approval note recorded as the result summary.' This adds context beyond the schema, such as note becoming the result summary.

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 clearly states the tool's purpose: 'Sign off a finished result that is waiting on a decision.' It specifies the verb 'approve' and the resource 'task' with status pending_approval. It distinguishes from siblings by explaining when to use alternative tools like bernstein_complete, bernstein_update, or cancelling.

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?

Explicitly states when to use (only for pending_approval) and when not to use (all other statuses) with structured refusals. It names alternatives for each status: approve plan for planned, bernstein_complete for work execution, bernstein_update for blockers, etc.

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