action1-mcp-server

Run a script (auto-route by endpoint OS)

action1_run_script

Destructive

Run PowerShell or Bash scripts on Action1 endpoints or endpoint groups, with OS-based routing and a preview before execution.

Instructions

Cross-platform script runner. Routes to PowerShell (Windows) or Bash (macOS); errors on Linux/unknown. For target_type='EndpointGroup' pass os ('windows' or 'macos').

Input Schema

Name	Required	Description
`os`	No	Script OS. Required for target_type='EndpointGroup'; for a single endpoint it must match the detected OS.
`name`	No	Friendly action name.
`org_id`	No	Org UUID.
`confirm`	No	Required to execute. Exact string "YES".
`dry_run`	No	Default true (preview). Set false to execute.
`endpoint_id`	Yes	Endpoint UUID, or Group ID when target_type='EndpointGroup'.
`script_text`	Yes	Script source.
`target_type`	No	Endpoint (default) or EndpointGroup for fan-out.
`retry_minutes`	No	Retry window in minutes when endpoint is offline.
`response_format`	No	Output format. Default markdown.
`timeout_minutes`	No	Per-action timeout in minutes (number or digit-string).
`success_exit_codes`	No	PowerShell only; ignored on macOS.
`skip_connectivity_check`	No	Skip offline-abort check.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 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"

addedInput schema / properties / os

Added value: +{
+  "description": "Script OS. Required for target_type='EndpointGroup'; for a single endpoint it must match the detected OS.",
+  "enum": [
+    "windows",
+    "macos"
+  ],
+  "type": "string"
+}

removedInput schema / properties / retry_minutes / $ref
```
Removed value: -"#/properties/timeout_minutes"
```

addedInput schema / properties / retry_minutes / anyOf

Added value: +[
+  {
+    "maximum": 10080,
+    "minimum": 0,
+    "type": "integer"
+  },
+  {
+    "pattern": "^\\d+$",
+    "type": "string"
+  }
+]

addedInput schema / properties / success_exit_codes / pattern
```
Added value: +"^\\d+(,\\d+)*$"
```

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: +{}
```

First observedv0.5.0Jun 27, 2026

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=true; the description usefully adds the routing/error behavior on top. However it never mentions the confirm="YES" gate, the dry_run default of true, or the blast radius when fanning out to an endpoint group, which are the behaviors an agent most needs to reason about for a destructive tool.

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?

Three short sentences, zero waste, with the routing rule front-loaded and the group-specific caveat second. Every sentence carries distinct information.

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 13-parameter destructive tool with full schema coverage, rich annotations, and an output schema, the description covers the one non-obvious routing rule and the Linux exclusion. The confirm/dry_run execution gate and group fan-out semantics are left to the schema, which is acceptable but leaves a small gap.

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 only restates what the schema already says about os (required for EndpointGroup, windows/macos values) and adds nothing about timeout_minutes, retry_minutes, confirm, or success_exit_codes.

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 (script runner) and its defining trait: it auto-routes to PowerShell on Windows or Bash on macOS. This functionally distinguishes it from the sibling action1_run_powershell and action1_run_bash_macos, though it never names 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 Guidelines4/5

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

Gives a real usage condition ('For target_type=EndpointGroup pass os') and a when-not rule ('errors on Linux/unknown'), which steers the agent away from unsupported targets. It stops short of saying 'use action1_run_powershell when you want explicit PowerShell', so alternative selection is only implied.

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

Deploy Server