Skip to main content
Glama
Sign In
ESET-MCP

ESET-MCP

by maciekaz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

vuln_vulnerable_devices__list_device_os_vulnerabilities

Read-onlyIdempotent

Lists operating system vulnerabilities for a specified device or device group, including kernel and core package issues, to identify exposed systems and prioritize remediation.

Instructions

List device operating system vulnerabilities - (GET /v1/device-os-vulnerabilities) - List vulnerabilities of the operating system of the given device.

Note: Besides vulnerabilities of the Linux kernel, there are also some "core packages" whose vulnerabilities are treated as operating system vulnerabilities. For example: glibc, systemd, etc.

Such vulnerabilities are reported twice, once as an operating system vulnerability and once as a package vulnerability.

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)
deviceUuidNoReference to the vulnerable device. If the device is identified as "me", all the [OS vulnerabilities] of the actual device are returned. If called with "me" in the cloud (that is, not on the device where the device context is ambiguous), the call will fail. If empty or null, vulnerabilities of the operating system regardless of any device accessible to the caller will be returned in the response. Clean devices with no vulnerabilities have no entry in the collection of vulnerable devices. type: VulnerableDevice
deviceGroupUuidNoReference to the [device group]. If filled, only devices within the group will be included in the response. If empty, 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

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnly=true, idempotent=true, destructive=false, openWorld=true, so the safety profile is covered. The description contributes genuinely new behavioral context: the double-reporting of core-package vulnerabilities (once as OS, once as package), which materially affects how an agent interprets and deduplicates results. It stops short of describing the response shape or pagination behavior.

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 opening line front-loads verb, resource, and endpoint path, and the single blockquote is tightly scoped to the one non-obvious fact an agent needs (duplicate OS/package reporting). No filler or redundant restatement of the title.

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?

All five parameters are optional and fully described in the schema, annotations cover the safety profile, and no output schema exists. The description covers purpose and the key interpretation caveat, but for a list endpoint with no output schema it could say more about what each returned vulnerability entry looks like.

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%, and the schema already documents 'me' handling for deviceUuid, group scoping for deviceGroupUuid, and the pageSize/pageToken semantics including defaults and caps. The description adds no parameter-level meaning beyond what the schema provides, 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 and resource ('List device operating system vulnerabilities') plus the backing endpoint GET /v1/device-os-vulnerabilities. The blockquote clarifies what counts as an OS vulnerability (kernel plus core packages like glibc/systemd), which conceptually separates it from the sibling vuln_vulnerable_devices__list_device_vulnerabilities. It never names that sibling, so the differentiation is implied rather than explicit.

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?

The note implies when this view matters (you need OS-scoped findings rather than package findings), but there is no explicit when-to-use/when-not guidance and no mention of the sibling list_device_vulnerabilities or list_vulnerable_devices as alternatives. Selection guidance is inferred rather than stated.

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