Skip to main content
Glama

Manage an Automation

manage_automation
Destructive

Check or stop a recurring lane automation. Actions: 'status' (read-only), 'pause', 'cancel' (permanent), 'skip_next' (skip one week's pickup — nothing books or charges that week). STOP-ONLY by design: there is no agent-side resume, reactivate, or ceiling change — those exist only behind the account owner's emailed approval link. Auth required.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tokenYesautomation token from automate_lane (so_…)
actionYesstatus is read-only; pause/cancel/skip_next stop or shrink the automation

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

The description materially extends the annotations' destructiveHint=true by specifying that 'cancel' is permanent and that 'skip_next' stops charges/bookings for one week. It also discloses the auth requirement and that resume/reactivate are gated behind the account owner's emailed approval link, with no contradiction to the annotations.

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?

Every sentence earns its place: scope, action semantics, stop-only boundary, and auth requirement. The core verb+resource is front-loaded and there is no filler or 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 simple two-parameter tool with no output schema, the description covers the critical side effects, auth, and unsupported actions well. The only notable gap is that it does not describe what a 'status' call returns, although the action name and read-only hint partially cover that.

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

Parameters4/5

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

The input schema already documents both required parameters at 100% coverage, which sets a baseline of 3. The description adds useful action-level semantics beyond the schema, including permanence of cancel and the one-week billing effect of skip_next.

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 opening clause 'Check or stop a recurring lane automation' names specific verbs and a concrete resource, and the action list makes the scope explicit. It is immediately distinguishable from sibling creation tool automate_lane and related receipt/lane-history tools.

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

Usage Guidelines4/5

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

The description explicitly frames the tool as STOP-ONLY and warns there is no agent-side resume, reactivate, or ceiling change, so an agent knows when not to use it. It does not directly name sibling alternatives such as automate_lane in the description, though token provenance in the schema points there, which keeps it just shy of a 5.

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.