ESET-MCP

A Model Context Protocol server for the

entire ESET management surface: ESET Connect

(cloud, all regions), ESET PROTECT On-Prem, ESET Inspect, and ESET Cloud

Office. Drive any of them from any MCP host (Claude Desktop, Claude Code,

or a custom agent) through tools, resources, and prompts.

Built as a single hub for any number of ESET deployments. One process

fronts cloud and on-prem consoles at the same time; clients pick the target

per request via headers. As long as MCP receives valid credentials (Basic

auth, plus an optional URL override and optional Cloudflare Access service

token) it routes the call to the right backend, mints its own tokens, and

keeps tenants isolated in the pool.

> ⚠️ Just to be clear, fellas

> This is an independent, community-driven open-source project and is not affiliated with, officially supported by, or endorsed by ESET, spol. s r.o. ESET and its product names are registered trademarks of their respective owners.

>

> While every effort has been made to ensure this software is safe and robust (including the strict Read-Only mode gate), this code is provided "AS IS", without any warranty of any kind. You are solely responsible for how you use this tool and any changes made to your ESET environment.

>

Table of contents

• Features
• Architecture at a glance
• Security
• Quick start
• Configuration
• Multi-tenant deployment (basic-auth mode)
• On-prem ESET PROTECT support
• Production deployment (HTTPS via Caddy)
• Tools, resources & prompts
• Architecture
• Tests
• Refreshing the OpenAPI specs
• License

Features

Complete API coverage

• 102 tools auto-generated from 16 official ESET Connect OpenAPI 3.0.1

specs, covering application-management, asset-management, automation,

device-management, identity, incident-management, installer-management,

mobile-device-management, network-access-protection, patch-management,

policy-management, quarantine-management, user-management,

vulnerability-management, and web-access-protection.

• 4 high-level composites that fold 3-6 raw calls into one:

`eset_search`, `device_full_profile`, `incident_full_context`,

`latest_detections`.

Read-only / read-write modes

• `ESET_MODE=RO` → catalog exposes only read-only tools (51 total).

Write tools are hidden from `list_tools` entirely.

• `ESET_MODE=RW` → all 106 tools advertised; mutating tools carry

`destructiveHint: true` in their MCP annotations.

• Independent of the ESET account's underlying permissions.
• A defence-in-depth in-memory gate rejects RW tool names in RO mode

before any HTTP request is sent.

Authentication

• `ESET_AUTH_MODE=env` - single tenant, credentials from `.env`.
• `ESET_AUTH_MODE=basic` - multi tenant, clients pass

`Authorization: Basic ` per request (plus optional

`X-ESET-Region` for a different cloud region, or `X-ESET-Server-URL` to

route the request to an on-prem PROTECT console). One server fronts many

ESET accounts and can mix cloud + on-prem in the same process.

• Per-tenant OAuth tokens, pooled and isolated by

`(user, password_hash, deployment, region-or-server-url, cf_secret_hash)`.

Rotating a password or Cloudflare Access service token mints a fresh

client; cloud and on-prem clients for the same user never share a pool entry.

Transports

• stdio - JSON-RPC over stdin/stdout for local hosts.
• Streamable HTTP - the current MCP transport (Nov 2025 spec).

Multi-region

`eu` / `de` / `us` / `ca` / `jpn`. Fixed via `ESET_REGION` in `env` mode;

per-request via `X-ESET-Region` in `basic` mode.

Cloud + on-prem in one process

In addition to the cloud regions, a single MCP server can front

customer-hosted ESET PROTECT On-Prem consoles. The on-prem auth wire

format (`POST /GetTokens` with a camelCase response) and per-host URL

structure are handled transparently; clients pick the target per request

via the `X-ESET-Server-URL` header. See

On-prem ESET PROTECT support.

Cloudflare Access (optional)

When the on-prem console sits behind a Cloudflare Access tunnel, MCP

authenticates as a service token

(env-default or per-request `X-ESET-CF-Access-Client-Id` /

`X-ESET-CF-Access-Client-Secret`) and rides through to the origin. The

CF token is an extra ingress layer in front of - not a replacement for -

the ESET account credentials. Cloud requests never carry these headers.

Resilience

• OAuth2 with proactive refresh ~5 min before token expiry and a forced

refresh + retry on 401.

• 429 retries with exponential backoff (up to 3 attempts, honours

`Retry-After`).

• Pagination (`nextPageToken`) walked transparently.
• 202 long-polling with the `response-id` header, up to 10 minutes.

Response shaping (context-window protection)

A single uncapped `list_*` call can return hundreds of KB - enough to

overflow a model's context. Two transformations are applied to every

tool response:

• `fields` projection - every GET tool exposes an optional

`fields: [string]` parameter that filters each list-item down to the

requested keys (e.g. `["uuid", "displayName"]`). Applied server-side

after fetch.

• Byte cap (`ESET_MCP_RESPONSE_BYTES_MAX`, default 100 KB) - if a

payload still exceeds the budget, the longest list is trimmed while

every top-level field (`nextPageToken`, `totalSize`, …) is preserved,

and a `_capped` metadata block is attached with an actionable hint

on how to continue. Agents retain full access to the data through

pagination.

Agent-friendly errors

HTTP errors are mapped to readable hints: 403 → check Permission Sets in

ESET PROTECT Hub; 401 → server refreshes the token automatically; 429 →

back off; 5xx → retry shortly.

Observability (logs + Prometheus)

• Structured logs to stderr. Text (default) for dev, JSON Lines for

prod log shippers via `ESET_MCP_LOG_FORMAT=json`. Every tool call,

token refresh, HTTP retry and pool eviction emits a typed `event`

record with low-cardinality fields (tool, deployment, status,

duration_ms, response_bytes, ...).

• Prometheus metrics at an opt-in `/metrics` endpoint

(`ESET_MCP_METRICS_ENABLED=true`, requires

`pip install eset-mcp[metrics]`). Counters for tool calls, token

refreshes, HTTP retries, cap hits; histograms for tool duration and

response sizes; gauge for client pool size.

• What never enters logs or metrics: passwords, `Authorization`

headers, CF Access secrets, request/response bodies, query strings,

substituted path parameters (which can leak UUIDs). A defensive

deny-list in the logger strips known-sensitive keys before any

formatter sees them.

• Failure isolation: telemetry emission is wrapped in a try/except so

a broken metrics registry or formatter can never turn a successful

tool call into an error to the agent. `/metrics` returns 500 (not 503)

if exposition ever raises - the worker stays up.

• Quieting in production: set `ESET_LOG_LEVEL=WARNING` to mute the

per-call INFO events but keep retries / errors visible; set

`ESET_LOG_LEVEL=ERROR` to silence everything but hard failures.

Disable metrics entirely with `ESET_MCP_METRICS_ENABLED=false`

(default). The three knobs are independent.

Architecture at a glance

The simplest setup: credentials in `.env`, one MCP host, one ESET cloud

region. Good for personal use, a single team, or a desktop AI client like

Claude Desktop or Claude Code.

For real multi-tenant or enterprise deployments, put a credentials manager

in front of ESET-MCP. The diagram below shows one such pattern using

IBM mcp-context-forge as the

"creds management" layer - any equivalent MCP gateway (or your own auth

proxy) works the same way:

The forge holds per-tenant secrets and injects `Authorization: Basic`,

`X-ESET-Region`, `X-ESET-Server-URL`, and `X-ESET-CF-Access-*` headers per

request. ESET-MCP routes each request to the right backend (cloud region,

on-prem PROTECT console, or on-prem behind Cloudflare Access) and the

per-tenant LRU client pool keeps OAuth tokens fully isolated between

tenants. This is a working pattern, not aspirational - the headers, pool

keys, and routing rules described here are all in the test suite under

`tests/test_concurrency.py` and `tests/test_onprem.py`.

Security

Credentials

• In `env` mode the password is read once at startup and kept in memory.
• In `basic` mode the password is on the wire only for the duration of

the request, and in memory only while the per-tenant client is hot

in the LRU pool. It is never logged.

• The pool key uses a SHA-256 hash of the password rather than the

password itself.

• OAuth access/refresh tokens are held per-tenant; tokens never cross

tenant boundaries within a single session.

Authentication modes & transport

`basic` mode over plain HTTP would leak passwords. The server enforces

HTTP transport for `basic` mode at startup but does not enforce TLS -

that is the deployment's job. The `prod` docker-compose profile fronts

the server with Caddy + Let's Encrypt.

Missing / malformed `Authorization` in `basic` mode → HTTP 401 with a

`WWW-Authenticate: Basic` challenge. Unknown region in `X-ESET-Region`

→ HTTP 401.

RO / RW isolation

Two independent layers:

1. Catalog hiding - `list_tools` filters out every non-GET tool in

RO mode. The agent never sees write tools.

2. Defence-in-depth gate - `call_tool` validates the tool's declared

mode against `ESET_MODE` before any HTTP request goes out. Hard-coded

clients, prompt-injection attempts, and stale agent snapshots all hit

the gate and receive a structured `ModeForbiddenError` text response

(no exception, no network call).

In RW mode, mutating tools carry `destructiveHint: true` so MCP hosts

that respect annotations can require a per-call confirmation.

Per-tenant isolation (basic-auth mode)

• Auth headers are parsed in dedicated ASGI middleware and stashed in a

`ContextVar`; they never enter request bodies or logs.

• Each request resolves to a `Credentials` instance keyed by

`(user, password_hash, region)`.

• An LRU bound on the client pool prevents unbounded memory growth from

random-credential spraying.

Network surface

• In dev (`docker compose up`) the MCP server publishes `:8765`.
• In the `prod` profile the MCP container has no published port -

Caddy joins the same docker bridge network and proxies HTTPS in. The

only host ports are 80 (HTTP-01 ACME) and 443 (HTTPS).

• No outbound traffic except to `*.eset.systems` (auth + APIs).

Dependency & code audit

• Snyk Code: 0 issues in `eset_mcp/`.
• Ruff: clean (`select = E F W I B UP RUF`).
• Runtime dependencies: `mcp`, `httpx`, `pydantic`, `python-dotenv`.

Plus `starlette` + `uvicorn` when running HTTP.

Out of scope (by design)

• No webhook receivers.
• No persistent storage; logs go to stdout.
• No on-disk caching of OAuth tokens.
• No write-back of `basic`-mode credentials to disk.

Responsible disclosure

Please open a private security advisory rather than a public issue:

.

Quick start

The fastest path is the published Docker image. No Python install, no

venv, no source checkout - just `.env` + `docker run`. The image is

multi-arch (amd64 + arm64), signed with cosign, ships with SBOM +

build provenance, and is published to GHCR on every release.

cp .env.example .env          # fill in ESET_USER / ESET_PASSWORD / ESET_REGION
docker run --rm -i --env-file .env ghcr.io/maciekaz/eset-mcp:1

Pin policy:

• `:1` - latest 1.x.x (auto-updates within the major)
• `:1.0` - latest 1.0.x (auto-updates within the minor)
• `:1.0.1` - exact version (production)
• `:latest` - most recent stable release
• `:main` / `:sha-` - edge builds from main (not for production)

Wire up to Claude Desktop / Claude Code (stdio)

// claude_desktop_config.json
{
  "mcpServers": {
    "eset": {
      "command": "docker",
      "args": ["run", "--rm", "-i", "--env-file", "/absolute/path/to/.env",
               "ghcr.io/maciekaz/eset-mcp:1"]
    }
  }
}

HTTP transport (single-tenant or behind your own proxy)

docker run -d --name eset-mcp \
  --env-file .env -p 8765:8765 \
  -e ESET_MCP_TRANSPORT=http \
  ghcr.io/maciekaz/eset-mcp:1
# MCP endpoint: http://localhost:8765/mcp

Verify the image (cosign keyless)

cosign verify \
  --certificate-identity-regexp '^https://github.com/maciekaz/ESET-MCP/' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  ghcr.io/maciekaz/eset-mcp:1

From source (contributors / local hacking)

git clone https://github.com/maciekaz/ESET-MCP.git
cd ESET-MCP
cp .env.example .env
python -m venv .venv && source .venv/bin/activate
pip install -e ".[dev]"
eset-mcp

Docker Compose (uses the published image)

docker compose up -d eset-mcp-http
# MCP endpoint: http://localhost:8765/mcp

By default the compose file pulls `ghcr.io/maciekaz/eset-mcp:1` - no

local build, fast first start. Pin a specific version by editing the

`image:` line in `docker-compose.yml`.

One-off stdio via compose:

docker compose --profile stdio run --rm eset-mcp-stdio

Hacking on the source? Use the dev profile to build from your local

checkout instead of pulling:

docker compose --profile dev up --build eset-mcp-http-dev

Configuration

All settings live in `.env`. Required fields are marked in

`.env.example`.

> Use a dedicated API user - not your console login. Create one in

> ESET PROTECT Hub / ESET Business Account → API users.

Multi-tenant deployment (basic-auth mode)

# .env
ESET_AUTH_MODE=basic
ESET_MCP_TRANSPORT=http
ESET_REGION=eu   # default region; clients can override per request

Every HTTP request must carry:

Example Python client:

import base64
from mcp import ClientSession
from mcp.client.streamable_http import streamablehttp_client

token = base64.b64encode(b"api-user@tenant.tld:secret").decode()
headers = {"Authorization": f"Basic {token}", "X-ESET-Region": "us"}

async with streamablehttp_client(
    "https://eset-mcp.example.com/mcp/", headers=headers
) as (r, w, _):
    async with ClientSession(r, w) as session:
        await session.initialize()
        tools = await session.list_tools()

> ⚠️ Basic auth without TLS leaks credentials. Always run `basic`

> mode behind HTTPS.

On-prem ESET PROTECT support

ESET ships PROTECT as both a cloud service (the ESET Connect API at

`*.eset.systems`) and an on-prem console customers self-host. The on-prem

REST API lives on a single host (default port `9443`) and uses a different

authentication endpoint - `POST /GetTokens` with a JSON body and a

camelCase response - but otherwise shares the URL structure of the cloud

API. ESET-MCP supports both, in the same process.

How the server decides cloud vs on-prem

So a single MCP server can front the cloud for most clients and route

specific requests to one or more on-prem consoles - keyed entirely by which

URL each client sends in `X-ESET-Server-URL`.

Single-tenant on-prem (env mode)

# .env
ESET_AUTH_MODE=env
ESET_DEPLOYMENT=onprem
ESET_ONPREM_SERVER_URL=https://protect.company.local:9443
ESET_ONPREM_VERIFY_SSL=true     # set to false only for self-signed certs you trust
ESET_USER=api-user@company.local
ESET_PASSWORD=...

Multi-tenant on-prem (basic auth, per-request URL)

# .env
ESET_AUTH_MODE=basic
ESET_MCP_TRANSPORT=http
ESET_DEPLOYMENT=cloud            # default; clients opt into on-prem per-request
# ESET_ONPREM_SERVER_URL is optional - if set it becomes the on-prem default

Client targeting on-prem:

headers = {
    "Authorization": f"Basic {token}",
    "X-ESET-Server-URL": "https://protect.client-a.local:9443",
}

Same MCP server, different request - same headers minus `X-ESET-Server-URL`

• stays on cloud.

What works on on-prem vs cloud

The tool catalog is identical for both deployments (all 102 OpenAPI-derived

tools plus the 4 composites). At call time the server uses cloud paths for

cloud credentials and on-prem paths for on-prem credentials.

• Shared & verified: `device_*`, `asset_groups_*`, `policy_*` and most

of `task_*` (Automation) work the same on cloud and on-prem.

• Cloud-only modules: `incident_*`, `mobile_*`, `wap_*`, `nap_*`,

`quarantine_*` and most of `vuln_*` correspond to separate ESET products

(ESET Inspect, Cloud Office Security, MDM) that are not part of the

on-prem PROTECT installation. Calling them against an on-prem console

returns a plain 404 from ESET - surfaced to the agent as an

`ESET API error: 404` text response with no special handling.

• Path overrides: a few endpoints have a different URL on-prem - e.g.

`POST /v1/devices/{uuid}:rename` is `:renameDevice` on-prem. These are

declared in `eset_mcp/openapi/onprem-path-overrides.json`

and applied automatically when the request targets on-prem.

Cloudflare Access in front of the on-prem console

When the on-prem PROTECT console is exposed via a Cloudflare tunnel and

gated by Cloudflare Access, MCP can authenticate as a

service token.

The chain becomes MCP → Cloudflare Access → ESET on-prem.

Two values per token pair, supplied either via `.env`:

ESET_ONPREM_CF_ACCESS_CLIENT_ID=abc1234567890.access
ESET_ONPREM_CF_ACCESS_CLIENT_SECRET=

…or per-request in basic-auth mode (overrides the env defaults - handy

when each tenant has its own tunnel and its own service token):

headers = {
    "Authorization": f"Basic {token}",
    "X-ESET-Server-URL": "https://protect.client-a.local:9443",
    "X-ESET-CF-Access-Client-Id": "abc1234567890.access",
    "X-ESET-CF-Access-Client-Secret": "",
}

MCP translates the `X-ESET-CF-*` input headers into the actual

`CF-Access-Client-Id` / `CF-Access-Client-Secret` headers that Cloudflare

Access expects, and attaches them to every outbound call - both the

`POST /GetTokens` auth handshake and every subsequent ESET API request.

The CF secret is treated like the password: never logged, only its SHA-256

hash enters the client pool key. Rotating the secret mints a fresh client

+ fresh ESET token. Cloud requests never carry CF Access headers

regardless of env defaults - ESET Connect is a public SaaS.

Security notes for on-prem

• `X-ESET-Server-URL` accepts only `https://` URLs with no path, query or

fragment. Trailing slashes are stripped. Anything else → HTTP 400.

• `ESET_ONPREM_VERIFY_SSL=false` disables TLS certificate verification and

exposes the connection to MITM. The server logs a single WARNING per

client construction when it's disabled. Use only on trusted intranets

with self-signed certs you cannot replace.

• On-prem tokens are held in memory per

`(user, password_hash, server_url, cf_secret_hash)` - same isolation

rules as cloud tokens. The pool keys them separately so cloud and

on-prem clients never collide, and two clients hitting the same on-prem

URL with different CF service tokens get separate pool entries.

• Sending only one of the two `X-ESET-CF-*` headers returns HTTP 400

rather than silently falling back to the env default (almost certain

operator typo).

Production deployment (HTTPS via Caddy)

The `prod` docker-compose profile launches Caddy in front of the MCP

server. Caddy fetches a Let's Encrypt cert on first start (HTTP-01

challenge - ports 80 / 443 must be reachable from the public internet)

and proxies HTTPS to the internal MCP container.

# .env
ESET_AUTH_MODE=basic
ESET_PUBLIC_DOMAIN=eset-mcp.example.com
ESET_ACME_EMAIL=ops@example.com

docker compose --profile prod up -d
# MCP endpoint: https://eset-mcp.example.com/mcp

You get:

• HTTPS on 443 with auto-renewing Let's Encrypt cert.
• HTTP-01 challenge on 80.
• MCP container bound only to the docker bridge network - no published port.
• gzip / zstd compression, JSON access logs on stdout.

Tools, resources & prompts

Composite high-level tools

Each composite degrades gracefully when a sub-call returns 403/404

(e.g. on tenants missing a module). The shape carries `skipped` /

`truncated` flags where applicable.

Resources

• `eset://config/mode` - `RO` or `RW`.
• `eset://config/region` - current region (per-request in basic-auth mode).
• `eset://config/deployment` - `cloud` or `onprem ()` for this request.
• `eset://config/tools-catalog` - JSON catalog of all 106 tools (name,

mode, method, path, service, description).

• `eset://docs/rate-limits` - quick reminder about the 10 req/s ceiling.

Prompts

• `audit_inactive_devices(days=30)` - offboarding candidates.
• `vulnerability_report` - per-device CVE report.
• `incident_triage` - open incidents + related detections.

Architecture

eset_mcp/
├── __main__.py         # entrypoint - stdio or HTTP, wires resolver + pool
├── server.py           # MCP server (tools / resources / prompts) + telemetry
├── credentials.py      # Credentials + EnvResolver / BasicAuthResolver + ContextVar
├── middleware.py       # ASGI Basic-auth middleware (basic mode only)
├── client_pool.py      # LRU pool of EsetHttpClient keyed by (user, region, ...)
├── http_client.py      # async httpx + 202 polling + 429 retry + 401 refresh
├── auth.py             # CloudTokenManager (OAuth2) + OnPremTokenManager (/GetTokens)
├── regions.py          # cloud region → per-service domains + on-prem URL resolver
├── modes.py            # RO/RW gate
├── errors.py           # HTTP error → agent-friendly text
├── config.py           # .env loading
├── response_shaping.py # fields projection + byte cap
├── composite_tools.py  # hand-written high-level tools
├── tools_loader.py     # generator: tools from OpenAPI specs + on-prem path overrides
├── observability/      # JSON/text structured logging + Prometheus metrics
└── openapi/            # 16 ESET Connect OpenAPI 3.0.1 specs + onprem path overrides

Tests

pytest                  # full suite (RO smoke + unit + integration)
pytest -m "not rw"      # RO only (default in CI)
pytest -m rw            # RW (requires an account with RW permissions)

Integration tests hit a real ESET tenant - credentials supplied via the

same `.env`. CI workflow:

`.github/workflows/integration.yml`

runs on PR, on push to `main`, and once a day at 03:17 UTC. The cron

catches drift between the server and ESET's published OpenAPI specs.

Refreshing the OpenAPI specs

cd eset_mcp/openapi
for name in business-account application-management asset-management automation \
            device-management iam incident-management installer-management \
            mobile-device-management network-access-protection patch-management \
            policy-management quarantine-management user-management \
            vulnerability-management web-access-protection; do
  curl -sO "https://eu.esetconnect.eset.systems/swagger/api/${name}.json"
done

`tests/test_catalog_vs_openapi.py` flags any new or changed operations

after a refresh.

License

MIT