Skip to main content
Glama
Sign In
ESET-MCP

ESET-MCP

by maciekaz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

patch_unpatched_devices__list_device_patches

Read-onlyIdempotent

Retrieve unpatched devices and their missing patches, optionally filtered by device, device group, or patch type, to identify exposed systems and target remediation.

Instructions

List device patches - (GET /v1/device-patches) - If the same application, package or operating system is unpatched on multiple devices, the collection would contain entities for each device and patch individually.

The list may be empty if no patches for any device are found.

Input Schema

NameRequiredDescriptionDefault
fieldsNoOptional server-side projection: return only these keys for each list-item in the response. Reduces token usage on large list endpoints. Example: ['uuid','displayName']. Top-level fields (e.g. nextPageToken) are always preserved. Not forwarded to ESET - applied locally after fetch.
pageSizeNoLimit for pagination purposes. If unspecified or 0, the default value is 50. The maximum value is 1000; values above 1000 will be coerced to 1000. > **Info:** > For more information, refer to [Paginating Requests in APIs](https://medium.com/@ignaciochiazzo/paginating-requests-in-apis-d4883d4c1c4c) > > or [Design Patterns: Pagination](https://google.aip.dev/158)
pageTokenNoPage token of the current page. If not given or "", the first page is returned. > **Info:** > For more information, refer to [Paginating Requests in APIs](https://medium.com/@ignaciochiazzo/paginating-requests-in-apis-d4883d4c1c4c) > > or [Design Patterns: Pagination](https://google.aip.dev/158)
patchTypeNoPossible categories of vulnerabilities. - PATCH_TYPE_UNSPECIFIED: fallback - PATCH_TYPE_APPLICATION: Application patch. - PATCH_TYPE_OPERATING_SYSTEM: Operating system patch. - PATCH_TYPE_PACKAGE: Package patch.PATCH_TYPE_UNSPECIFIED
deviceUuidNoReference to the device whose vulnerabilities should be listed. If empty or null, vulnerabilities of any device accessible to the caller will be included in the response. type: vulnerability_management.v1.VulnerableDevice
deviceGroupUuidNoReference to the [device group] for which the vulnerable devices should be listed. Devices of the nested groups are listed recursively as well. If empty or null, any device accessible to the caller will be included in the response. type: device_management.v1.DeviceGroup

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

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, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds useful behavioral context: the per-device/per-patch entity granularity and the possibility of an empty list. It says nothing about pagination limits or what a returned entity contains.

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?

Two short sentences, front-loaded with the action, plus the endpoint in parentheses. Every sentence carries information, though the raw URL is of limited value to an agent and there is minor redundancy between the title-style name and the first clause.

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?

It is a read-only paginated list with no output schema, so the description should convey what an entity represents — it does so at a high level (one record per device and patch). It leaves the response shape, pagination behavior (default 50, max 1000) and how this differs from sibling patch/vulnerability listings unaddressed.

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?

With schema description coverage at 100%, each of the six parameters (including the patchType enum and the deviceUuid/deviceGroupUuid scoping) is already fully documented in the schema. The description's mention of application, package and operating system vaguely aligns with patchType but adds no filtering syntax or interaction details beyond the schema.

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 device patches") and pins the endpoint (GET /v1/device-patches). It also explains the entity granularity — one entry per device/patch pair — which clarifies what the result set actually represents. It does not distinguish itself from close siblings like patch_patch_management__list_device_patching_details or vuln_vulnerable_devices__list_device_vulnerabilities.

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 explicit when-to-use guidance, no prerequisites, and no named alternative despite several sibling list tools covering overlapping patching/vulnerability data. Usage is only implied by the mention that results may be empty and that filtering exists via patchType/deviceUuid in the schema.

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

Deploy Server

Other Tools