action1-mcp-server

Stop a automation

action1_stop_instance

Destructive

Stops a running automation instance and aborts its actions on a remote endpoint, requiring an instance ID and confirmation to execute.

Instructions

Stop a automation. Stops applying a automation instance and aborts actions running on a remote endpoint. Perm: manage_automations.

Input Schema

Name	Required	Description
`org_id`	No	Org UUID.
`confirm`	No	Required to execute. Exact string "YES".
`dry_run`	No	Default true (preview). Set false to execute.
`instance_id`	Yes	Provide a specific instance ID.

Output Schema

Name	Required	Description	Default
`id`	No
`tool`	No
`type`	No
`status`	No
`dry_run`	No
`would_send`	No
`user_message`	No
`developer_message`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed11 schema fields changedv0.6.0Oct 26, 2026
- changedInput schema / $schema
```
Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
```
- changedOutput schema / $schema
```
Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
```
- changedOutput schema / additionalProperties
```
Previous value: -trueNew value: +{}
```
- addedOutput schema / properties / developer_message
```
Added value: +{}
```
- addedOutput schema / properties / dry_run
```
Added value: +{}
```
- addedOutput schema / properties / id
```
Added value: +{}
```
- addedOutput schema / properties / status
```
Added value: +{}
```
- addedOutput schema / properties / tool
```
Added value: +{}
```
- addedOutput schema / properties / type
```
Added value: +{}
```
- addedOutput schema / properties / user_message
```
Added value: +{}
```
- addedOutput schema / properties / would_send
```
Added value: +{}
```
First observedv0.5.0Jun 27, 2026

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already flag destructiveHint=true and openWorldHint=true, but the description adds meaningful consequence detail beyond them: the stop aborts actions actively running on a remote endpoint, which tells the agent the blast radius extends to in-flight work. The permission requirement is also stated, though the dry_run-default-true / confirm="YES" safety gates are left to the schema.

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 short sentences, front-loaded with the action and then the mechanism and permission. Slightly redundant ("Stop a automation" immediately restated as "Stops applying a automation instance"), and grammar is off ("a automation"), but there is no wasted explanatory padding.

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 destructive mutation with full annotation coverage, a documented output schema, and 100% param coverage, the description supplies the essential missing pieces: the remote-abort side effect and the required permission. It could still note that the call previews by default unless dry_run is false, since that changes agent behavior.

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 100%, so baseline is 3. The description mentions no parameter semantics at all; the instance_id, org_id, confirm, and dry_run meanings are entirely carried by the schema.

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 concrete verb+resource ("Stop a automation") and clarifies the mechanism: stopping the instance's application and aborting actions on the remote endpoint. This differentiates it from delete_automation or get_automation_status in the sibling set, though it never explicitly names those alternatives.

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 guidance on when to use this versus delete_automation, delete_automation_action, or the status/results tools. The only conditional information given is the required permission (manage_automations), not a usage decision rule.

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

Deploy Server