Skip to main content
Glama

aiworkhub_manager_loop_continue

MANAGER WRITE: continue one saved manager conversation.

Instructions

MANAGER WRITE: continue one saved manager conversation.

Synchronous and provider-free. The chosen record becomes the active session and the persisted selection. A picked backend_id/model is authorized and pinned on it without starting it; the pick renews the manager seat. Refused while a turn is running.

Input Schema

NameRequiredDescriptionDefault
modelNo
backend_idNo
session_idYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the full behavioral burden and does well: it discloses that the operation is synchronous and provider-free, changes the active session and persisted selection, authorizes and pins a backend/model without starting it, renews the manager seat, and refuses while a turn is running. It does not fully discuss permission/auth requirements beyond the 'MANAGER WRITE' label.

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 front-loaded with the core action and then uses short sentences to add only relevant behavioral context. Each sentence contributes useful information without repetition.

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

Completeness4/5

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

For a manager write operation with no annotations and an output schema, the description gives substantial side-effect and constraint context. It is complete enough for selection and invocation, though the lack of explicit sibling routing and fuller parameter semantics leaves a minor gap.

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

Parameters3/5

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

Schema description coverage is 0%, so the description must compensate. It names backend_id and model and explains their pinning/authorization behavior, and implies session_id through 'the chosen record,' but it does not explicitly explain the required session_id or clarify expected formats/defaults.

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

Purpose4/5

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

The description states a specific verb and resource: continue one saved manager conversation. It clarifies that the chosen record becomes the active session, which distinguishes it from adjacent loop operations like new or send, though it does not explicitly name those siblings.

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

Usage Guidelines3/5

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

Usage is implied by 'continue one saved manager conversation,' and there is one explicit guardrail: 'Refused while a turn is running.' However, it does not explicitly say when to choose this over loop_new, loop_send, loop_rotate, or similar siblings.

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

Deploy Server

Other Tools