action1-mcp-server

List updates for a package

action1_get_update_package

Read-onlyIdempotent

List updates available for a specific package ID to review patch availability and approval status, with filtering and pagination for endpoint update management.

Instructions

List updates for a package. Gets a list of updates available for a package specified by its ID. Perm: approve_updates, view_dashboards, manage_automations.

Input Schema

Name	Required	Description
`from`	No	Provide the number of the first record to be returned.
`limit`	No	Set the maximum number of items to be returned (the page size).
`cursor`	No	next_cursor of the previous call; takes precedence over from.
`custom`	No	Specify if the package is custom (yes) or builtin (no).
`fields`	No	Add FIELDS parameter to query extended data.
`filter`	No	Provide a case-insensitive substring to filter and narrow down returned results (i.e., if...
`org_id`	No	Org UUID.
`sortby`	No	Define the sorting order by a certain field.
`builtin`	No	Specify if the package is builtin (yes) or custom (no).
`verbose`	No	Skip per-item compactor.
`package_id`	Yes	Provide a specific package ID.
`only_latest`	No	Specify if you want to exclude superseded updates. By default, 'yes'.
`auto_paginate`	No	Walk pages until limit or the size budget; then continue with next_cursor.
`approval_status`	No	Specify the update status.
`response_format`	No	Output format. Default markdown.
`security_severity`	No	Specify the severity level, e.g., security_severity=-Critical (for all non-critical).

Output Schema

Name	Required	Description	Default
`note`	No
`count`	Yes
`items`	Yes
`total`	No
`has_more`	No
`next_cursor`	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"

changedInput schema / properties / auto_paginate / description

Previous value: -"Walk all pages."New value: +"Walk pages until limit or the size budget; then continue with next_cursor."

changedInput schema / properties / cursor / description

Previous value: -"Pagination cursor."New value: +"next_cursor of the previous call; takes precedence over from."

addedInput schema / properties / from / maximum
```
Added value: +9007199254740991
```
addedInput schema / properties / from / minimum
```
Added value: +0
```
addedInput schema / properties / limit / maximum
```
Added value: +50000
```
addedInput schema / properties / limit / minimum
```
Added value: +1
```

changedInput schema / properties / limit / type

Previous value: -"number"New value: +"integer"

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": {},
+  "id": {},
+  "internal_notes": {},
+  "kb_number": {},
+  "name": {},
+  "optional": {},
+  "organization_ids": {},
+  "reboot_needed": {},
+  "recommended": {},
+  "scope": {},
+  "self": {},
+  "size": {},
+  "status": {},
+  "type": {},
+  "update_type": {},
+  "vendor": {},
+  "versions": {}
+}

First observedv0.5.0Jun 27, 2026

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so safety is fully covered. The description adds genuine value by disclosing required permissions (approve_updates, view_dashboards, manage_automations), but it does not explain pagination defaults or output behavior, which are relevant for a 16-param list tool.

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?

The purpose is front-loaded and the description is short. Minor redundancy: 'List updates for a package' is restated by 'Gets a list of updates available for a package,' but overall it is efficient.

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?

With a rich schema, output schema, and annotations, the description covers purpose and permissions. For a list tool with many siblings, though, it leaves the agent without routing guidance to distinguish it from action1_list_updates and related enumeration tools, leaving a meaningful 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 all 16 parameters (including enums for custom, approval_status, only_latest, etc.) are already documented in the schema. The description only reiterates package_id via 'specified by its ID' and adds no syntax or default details beyond the schema, so the baseline 3 applies.

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 (list) and resource (updates for a package identified by ID), which distinguishes it from the generic update listing. However, it does not name any sibling such as action1_list_updates to explicitly delineate scope.

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

Usage Guidelines3/5

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

Usage is only implied by the purpose statement (call it to see updates for a given package). There is no explicit guidance on when to prefer this over action1_list_updates or the version/endpoint listing tools, and no exclusions or prerequisites beyond permissions.

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

Deploy Server