Skip to main content
Glama

sequence

Destructive

Run ordered action steps while enforcing policy, confirmation, confinement, lease, and audit checks on each step; nested chains are rejected.

Instructions

Run an ordered action sequence. Every step re-enters the ordinary single-tool policy, confirmation, confinement, lease, and audit gateway; nested sequences are rejected.

Input Schema

NameRequiredDescriptionDefault
stepsYes
dry_runNo
max_stepsNo
stop_on_errorNo
confirmation_tokenNoExternally approved, one-time challenge ID from request_confirmation for a high-risk action.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

B3.1/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds real behavioral context beyond that: each step re-enters the policy, confirmation, confinement, lease, and audit gateway, and nesting is rejected. But the jargon (confinement, lease) is undefined and it says nothing about error handling or what happens on partial failure.

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 sentences, front-loaded with the core action and followed by the governance constraint; no filler. Dense internal terminology slightly reduces immediate comprehension but the structure is efficient.

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?

This is a complex orchestration tool accepting up to 128 steps with dry-run and stop-on-error semantics, no output schema, and near-empty parameter documentation. The description leaves critical gaps: return shape, per-step failure behavior, and the meaning of most parameters.

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 only 20%, with just confirmation_token documented. The description never mentions steps, dry_run, max_steps, or stop_on_error, so four of five parameters have no semantics anywhere, and the low coverage is not compensated for.

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 ('Run an ordered action sequence'), which clearly identifies this as a meta-orchestration tool distinct from the single-action siblings like click or type_text. It stops short of naming a sibling or contrasting with calling those tools one by one, so it misses the top band.

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?

The description implies usage (batch several actions with per-step governance) and gives one exclusion ('nested sequences are rejected'), which is useful. However it never says when an agent should choose sequence over issuing the individual tools directly, nor any prerequisite beyond confirmation.

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