Skip to main content
Glama

Browser rehearsal range for agents

rehearse

Rehearse a workflow against the clone; scored on prohibited effects; a pass earns a signed promotion receipt. $1.50/rehearsal after the one-time free rehearsal; included on Operator/Fleet plans.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
agentYes
actionsNo
variantNo
mirror_idYes
task_classNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

C2.9/5.0
Behavior3/5

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

With no annotations, the description carries the full burden but does disclose meaningful behavior: runs are scored on prohibited effects, a pass yields a signed promotion receipt, and pricing/cost model is given. It omits failure behavior, side effects on the clone, and auth/plan prerequisites beyond cost, so it is only partially transparent.

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

Conciseness4/5

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

Two tight sentences with the purpose front-loaded ahead of the commercial detail. The pricing clause is useful but slightly dilutes focus; nothing is redundant.

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

Completeness2/5

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

No annotations, no output schema, and zero parameter documentation for a 5-param tool. The description covers outcome and cost but leaves the agent without enough to invoke it correctly, particularly on mirror_id/agent/actions semantics.

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

Parameters2/5

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

Schema coverage is 0% and five parameters (mirror_id, agent, actions, variant, task_class) are completely undocumented in both schema and description. The words 'workflow' and 'clone' offer only the faintest mapping to actions/mirror_id, leaving the agent to guess formats and meanings.

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?

States a specific verb+resource ('Rehearse a workflow against the clone') and describes the outcome ('scored on prohibited effects; a pass earns a signed promotion receipt'). It loosely ties to siblings via 'clone' (create_mirror) and 'receipt' (verify_receipt) but never names or contrasts them explicitly.

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

Usage Guidelines2/5

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

There is no when-to-use, when-not, or alternative guidance. The pricing sentence implies a pre-promotion rehearsal step, but the agent gets no signal on how this relates to drift_check or verify_receipt, which is exactly where routing guidance is needed.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources