action1-mcp-server

List of all vulnerable software within the organization

action1_list_org_vulnerabilities

Read-onlyIdempotent

List and filter organization-wide CVE exposures by severity, remediation status, date, CVE ID, and endpoint to prioritize vulnerable software; use per-endpoint listing for individual devices.

Instructions

Org-wide CVE rollup with 13 server-side filters. For per-endpoint vulnerabilities use action1_list_vulnerabilities (curated). List of all vulnerable software within the organization. Perm: view_vulnerabilities.

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).
`score`	No	The severity of the Common Vulnerabilities and Exposures (CVE) entries.
`cursor`	No	next_cursor of the previous call; takes precedence over from.
`cveids`	No	Add CVEIDs parameter to query specific vulnerabilities by their CVE IDs.
`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.
`verbose`	No	Skip per-item compactor.
`endpoint_id`	No	The ID of the endpoint to query.
`reset_cache`	No	Reset current cache.
`auto_paginate`	No	Walk pages until limit or the size budget; then continue with next_cursor.
`response_format`	No	Output format. Default markdown.
`published_date_end`	No	The maximum publishing date of the Common Vulnerabilities and Exposures (CVE) entries.
`remediation_status`	No	The remediation status.
`published_date_start`	No	The minimum publishing date of the Common Vulnerabilities and Exposures (CVE) entries.
`remediation_required_end_day`	No	The maximum value of the remediation deadline, in days. Example: 30
`remediation_required_start_day`	No	The minimum value of the remediation deadline, in days. Example: 7

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.

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

addedInput schema / properties / reset_cache / enum
```
Added value: +[
+  "Yes",
+  "No"
+]
```

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: +{
+  "cisa_kev": {},
+  "cve_id": {},
+  "cvss_score": {},
+  "endpoints_count": {},
+  "organization_id": {},
+  "organization_ids": {},
+  "published_date": {},
+  "remediation_deadline": {},
+  "remediation_status": {},
+  "software": {},
+  "vector_string": {}
+}

First observedv0.5.0Jun 27, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive), so the description's added value is the authorization requirement ('Perm: view_vulnerabilities') and the note that filtering happens server-side across 13 filters, which sets expectations about result volume. It does not mention rate limits or caching behavior beyond the schema's reset_cache param.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Short overall and the sibling routing is front-loaded, but the middle sentence 'List of all vulnerable software within the organization' merely restates the title and occupies critical space without adding 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?

With an output schema, rich annotations, and full parameter documentation, the description needs only to establish scope, sibling routing, and auth — all of which it does. Minor gap: no hint about the shape of the rollup (per-CVE aggregation vs per-software) despite the title referencing vulnerable software.

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 coverage is 100% with all 18 parameters documented, so the baseline is 3. The description's '13 server-side filters' hints at the filter set but adds no syntax, combinations, or precedence guidance beyond what the schema already provides.

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?

States a specific verb+resource+scope ('Org-wide CVE rollup') and names the sibling it is not ('For per-endpoint vulnerabilities use action1_list_vulnerabilities'). An agent can distinguish it from the per-endpoint variant without opening either schema.

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?

Explicitly routes the per-endpoint case to action1_list_vulnerabilities and states the permission needed (view_vulnerabilities). It does not, however, clarify relationships to adjacent CVE tools like action1_list_cve_endpoints or action1_get_cve.

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

Deploy Server