action1-mcp-server

Server-side aggregation over all endpoints

action1_endpoints_summary

Read-onlyIdempotent

Walks every endpoint and returns summarized counts (total, status, platform, OS, online, reboot_required) in ~1 KB, avoiding large output for fleet overview.

Instructions

Walks every endpoint and returns counts (total, by status/platform/OS/online, reboot_required). ~1 KB output regardless of fleet size.

Input Schema

Name	Required	Description	Default
`org_id`	No	Org UUID.
`response_format`	No	Output format. Default markdown.

Output Schema

Name	Required	Description
`by_os`	No	object
`linux`	No	number
`macos`	No	number
`total`	No	number
`windows`	No	number
`by_status`	No	object
`by_platform`	No	object
`fresh_last_seen`	No	number
`reboot_required`	No	number
`stale_last_seen`	No	number
`by_online_status`	No	object

Schema Changelog

Changes observed during successful MCP inspections.

Changed14 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 / by_online_status
```
Added value: +{
+  "description": "object"
+}
```

addedOutput schema / properties / by_os

Added value: +{
+  "description": "object"
+}

addedOutput schema / properties / by_platform

Added value: +{
+  "description": "object"
+}

addedOutput schema / properties / by_status

Added value: +{
+  "description": "object"
+}

addedOutput schema / properties / fresh_last_seen
```
Added value: +{
+  "description": "number"
+}
```

addedOutput schema / properties / linux

Added value: +{
+  "description": "number"
+}

addedOutput schema / properties / macos

Added value: +{
+  "description": "number"
+}

addedOutput schema / properties / reboot_required
```
Added value: +{
+  "description": "number"
+}
```
addedOutput schema / properties / stale_last_seen
```
Added value: +{
+  "description": "number"
+}
```

addedOutput schema / properties / total

Added value: +{
+  "description": "number"
+}

addedOutput schema / properties / windows

Added value: +{
+  "description": "number"
+}

First observedv0.5.0Jun 27, 2026

TDQS

A4.5/5.0

Behavior5/5

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

The description adds crucial behavioral context beyond the metadata provided by annotations. Specifically, stating '~1 KB output regardless of fleet size' addresses performance and scaling, which is a significant operational guarantee for the AI agent.

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?

The tool is extremely concise. Both sentences are highly informative, front-loading the action and specifying the key value proposition (performance/scale) in the second part.

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

Completeness5/5

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

Given that it is a read-only aggregation tool, the description is maximally complete. It defines what is counted, how many endpoints are covered, and the size constraint of the output.

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%, setting the baseline at 3. The description does not elaborate on the meaning or requirements of the input parameters (org_id, response_format), but accurately reflects the tool's function.

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 description uses specific action verbs ('Walks', 'returns') and defines the resource and scope clearly ('every endpoint'). It specifies that the output is a statistical aggregation (counts), clearly distinguishing it from listing endpoints.

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?

While it doesn't explicitly name competing tools, it strongly implies its use case: viewing a high-level, complete summary of the fleet's status (total, status, OS, reboot needs) rather than retrieving granular details from a specific tool.

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

Deploy Server