Skip to main content
Glama
thestandard-production

openmausbot-cua-mcp

openmausbot_run_routine_now

Execute a specified routine immediately using its exact ID or name. Start automation tasks right away with optional dry-run validation.

Instructions

Plan or start one routine immediately.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dry_runNo
routineYesExact routine id or name.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.2

TDQS

C2.6/5.0
Behavior2/5

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

Annotations already mark the tool as non-read-only and non-idempotent, so the description's job is to add behavioral context. It discloses that a routine can be started (a side effect) but does not explain that dry_run defaults to true (so a bare call plans rather than starts), nor what happens when a run is started. The description is not misleading but is thin.

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?

A single, front-loaded sentence with no filler. It is concise to the point of underspecification, but structurally it is exactly what a short description should look like.

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?

For a tool that can either dry-run or execute, alongside siblings like openmausbot_plan, openmausbot_cancel_run, and openmausbot_status, this description leaves crucial selection and invocation details implicit. The existence of an output schema covers return values, but the dual-mode behavior and default dry_run need to be stated.

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?

The schema describes 'routine' as an exact id or name, and the tool description's 'Plan or start' hints that dry_run switches between modes. However, the description doesn't explicitly say which value of dry_run triggers planning versus execution, and dry_run has no schema description. With 50% schema coverage, this is partial compensation.

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

Purpose3/5

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

The description 'Plan or start one routine immediately' names a resource (one routine) and an action, but offers two verbs, leaving unsaid what distinguishes planning from starting and how that maps to the dry_run parameter. It also doesn't differentiate this tool from the sibling openmausbot_plan, which may already cover the planning behavior.

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?

No when-to-use guidance is present: it doesn't say 'use this to execute immediately vs. plan via openmausbot_plan' or mention alternatives such as openmausbot_cancel_run for cleanup. An agent must infer context from the name.

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