About fleetwatch
fleetwatch is a local, read-only bridge to ET Ducky’s hosted MCP server for organizations monitoring Windows and Linux endpoint agents. It forwards upstream tool calls without storing fleet data or running checks itself.
Key features
- 01List and filter agents by hostname
- 02Inspect an agent’s latest health sample
- 03List alerts by status and severity
- 04Summarize online devices and alerts
- 05Call tools through the CLI
Use cases
- 01Check which endpoint agents are online
- 02Review machine health and active alerts
- 03Filter devices by OS or tag
MCP support
As an MCP server, it exposes upstream tools to clients and forwards their calls to ET Ducky’s hosted MCP server. Its tool surface is read-only.
Configuration
Local server config is the same for every client. Copy it into your client’s MCP config file.
Tools
4Saved tool list · updated 1w ago
| Parameter | Type | Required | Description |
|---|---|---|---|
| os | enum | No | Only agents of this OS family.windows | linux | other |
| tag | string | No | Only agents carrying this exact tag name. |
| limit | integer | No | Most rows to return. Defaults to 100. |
| online | boolean | No | true for agents with a heartbeat in the last 5 minutes, false for the rest. |
| search | string | No | Case-insensitive part of the hostname. |
Details
From the project READMEfleetwatch
fleetwatch is a small local bridge to ET Ducky's hosted MCP server, which watches over an organisation's fleet of endpoint agents — the Windows and Linux machines running the ET Ducky agent — and reports who is online, how each machine's health looks, and which alerts are open.
The bridge keeps no fleet data and runs no checks of its own. It serves the upstream server's tool list locally, exactly as captured from the live endpoint, and forwards each tool call upstream, returning the result untouched. The whole captured surface is read-only: this rebuild adds no write capability.
Tools
list_agents— enumerate the organisation's agents with OS, agent version, online state, last heartbeat, last signed-in user, isolation state and tags, sorted by hostname. All arguments are filters:search(a case-insensitive part of the hostname),os(windows,linuxorother),online(true for agents with a heartbeat in the last 5 minutes),tag(one exact tag name), andlimit(1-500, default 100).get_agent— one agent in full: its latest health sample (CPU, memory, free space on C:, uptime, pending reboot, make and model) and its count of active alerts. Required:agent_id, the id fromlist_agents.list_alerts— alerts raised for the organisation's agents, newest first. Optional:status(active,acknowledged,resolved,auto_resolved,suppressedorany; defaults to active),severity(for examplecriticalorwarning),agent_idto scope to one machine,since_hours(1-720, default 168 — seven days) andlimit(1-500, default 100).get_fleet_summary— the organisation at a glance: agent counts, online and offline, the Windows / Linux / other OS split, isolated agents, and active alerts by severity. No arguments.
Configuration
ETDUCKY_MCP_URL(optional) — override the upstream endpoint. Defaults tohttps://etducky.com/api/mcp. (The override hook is this rebuild's own labelled reconstruction.)ETDUCKY_API_KEY(optional) — when set, every upstream request carries anAuthorization: Bearer <key>header. When it is not set, no auth header is sent. (This forwarding is also a labelled reconstruction; the original surface was captured keyless.)
Forwarding mechanics
On the first tool call the client opens a streamable
HTTP session with the upstream: a JSON-RPC initialize
request (protocolVersion 2025-03-26, clientInfo name
fleetwatch), then a notifications/initialized
notification, then the tools/call request carrying
the caller's arguments unchanged. When the upstream
answers initialize with an Mcp-Session-Id header,
that value rides on every later request of the session,
which is reused for the life of the process. Replies
may arrive as plain JSON or as server-sent events;
both are read.
Successful upstream results pass through verbatim,
including any isError flag the upstream sets.
Failures — a JSON-RPC error, a non-2xx status, an
unreadable response, or a request that cannot be
completed — come back as an isError result whose
text starts with fleetwatch error: (this rendering
is this rebuild's own labelled reconstruction).
CLI
Each tool is also a subcommand taking one JSON argument string (omit it for tools that take none):
npx @reneturcios/fleetwatch list_agents '{"os":"windows","online":true}'
npx @reneturcios/fleetwatch get_agent '{"agent_id":"agent-42"}'
npx @reneturcios/fleetwatch get_fleet_summary
npx @reneturcios/fleetwatch --version
Exit codes: 0 on success, 1 on an isError
result, 2 on a usage error.
MCP server
npx -y @reneturcios/fleetwatch mcp
MCP client config:
{
"mcpServers": {
"fleetwatch": {
"command": "npx",
"args": ["-y", "@reneturcios/fleetwatch", "mcp"]
}
}
}
Docker
docker run -i ghcr.io/cloudcorprecords/fleetwatch
docker run --rm ghcr.io/cloudcorprecords/fleetwatch --version
The container's default command is mcp, so the first
form is a stdio MCP server; any other arguments reach
the CLI normally.
Development
npm install
npm run build
npm test
npm run dev
The test suite runs entirely against a stubbed JSON-RPC upstream — no live network calls.
License
MIT — see LICENSE.
Comments
New to MCP?
From what the protocol is to installing your first server, these answers cover most first questions.
An open protocol that defines how AI applications connect to external tools and data in a uniform way. Clients talk to the model; MCP servers provide tools, resources and prompt templates. They exchange standard messages, so one server can be reused by many clients.