action1-mcp-server

List scripts

action1_list_scripts

Read-onlyIdempotent

Retrieve scripts from the Script Library to view existing built-in or custom scripts by platform, with output available in markdown or JSON.

Instructions

List scripts. Gets a list of existing scripts from the Script Library. Perm: use_scripts.

Input Schema

Name	Required	Description
`builtin`	No	Specify if the package is builtin (yes) or custom (no).
`verbose`	No	Skip per-item compactor.
`platform`	No	platform
`response_format`	No	Output format. Default markdown.

Output Schema

Name	Required	Description	Default
`note`	No
`count`	Yes
`items`	Yes
`total`	No
`truncated`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 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 / platform / enum

Added value: +[
+  "Windows",
+  "Mac",
+  "Linux"
+]

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 / items / items / properties

Added value: +{
+  "builtin": {},
+  "description": {},
+  "enterprise_id": {},
+  "id": {},
+  "language": {},
+  "name": {},
+  "params": {},
+  "reboot_exit_codes": {},
+  "script_text": {},
+  "self": {},
+  "status": {},
+  "success_codes": {},
+  "type": {}
+}

First observedv0.5.0Jun 27, 2026

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds one genuinely new behavioral fact — the use_scripts permission requirement — but says nothing about result volume, pagination, or filtering behavior on a list endpoint.

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?

Three short sentences, front-loaded with the action and resource, with the permission constraint last. Minor redundancy between 'List scripts' and 'Gets a list of existing scripts', but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

A read-only list tool with an output schema, fully documented parameters, and rich annotations needs little more. Still, the description omits anything about result shape, default ordering, or how verbose/response_format change the output, leaving it only adequate.

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% with enums on three of four parameters, so the schema already carries full parameter meaning. The description adds no parameter guidance, which meets the baseline-3 expectation but no more.

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 and resource ('List scripts') and clarifies the source ('existing scripts from the Script Library'), which separates it from action1_get_script, action1_create_script, and action1_run_script. It does not explicitly name those siblings, so it stops short of a 5.

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?

There is no guidance on when to use this versus action1_get_script or action1_search, and no mention of when a caller should filter by builtin/platform versus paging through everything. The only context is the permission requirement, which is not usage routing.

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

Deploy Server