Fleetwatch

io.github.CloudCorpRecordsPublished by GitHub account CloudCorpRecordsv0.1.0Updated Nov 7, 2026

Read-only fleet visibility: endpoint agents, health samples, alerts and org summaries.

Overview

AI-generated overview

Read-only bridge to ET Ducky's hosted MCP server, letting an assistant list endpoint agents, inspect health, review alerts and summarize an organization's…

What you can do
  • List and filter endpoint agents by hostname, OS, online state and tag
  • Inspect one agent's latest health sample and active alert count
  • Review alerts by status, severity, agent and time window
  • Get organization-wide counts of agents, OS split, isolation and alerts by severity
When to use it
Useful when you want an assistant to answer questions about a Windows/Linux endpoint fleet — which machines are online, how healthy they are, and which alerts are open — without giving it any write access.
Requirements
Runs locally over stdio via npx (Node.js) or the Docker image. Optionally set ETDUCKY_MCP_URL to override the upstream endpoint (defaults to the ET Ducky hosted server) and ETDUCKY_API_KEY to send a bearer token upstream; without the key no auth header is sent. Network access to the upstream is required.
Before you install
All traffic goes to the third-party ET Ducky hosted endpoint, including hostnames, last signed-in users and health data. ETDUCKY_API_KEY is forwarded as a bearer token to whatever ETDUCKY_MCP_URL points at, so only override that URL with a trusted endpoint. The surface is read-only, but upstream error text is passed back verbatim.

Installation

In SourceWeft

  1. Open Fleetwatch in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.

Other MCP clients

Follow the launch instructions in the repository.

README

fleetwatch

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, linux or other), online (true for agents with a heartbeat in the last 5 minutes), tag (one exact tag name), and limit (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 from list_agents.
  • list_alerts — alerts raised for the organisation's agents, newest first. Optional: status (active, acknowledged, resolved, auto_resolved, suppressed or any; defaults to active), severity (for example critical or warning), agent_id to scope to one machine, since_hours (1-720, default 168 — seven days) and limit (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 to https://etducky.com/api/mcp. (The override hook is this rebuild's own labelled reconstruction.)
  • ETDUCKY_API_KEY (optional) — when set, every upstream request carries an Authorization: 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):

bash
npx @reneturcios/fleetwatch list_agents '{"os":"windows","online":true}'npx @reneturcios/fleetwatch get_agent '{"agent_id":"agent-42"}'npx @reneturcios/fleetwatch get_fleet_summarynpx @reneturcios/fleetwatch --version

Exit codes: 0 on success, 1 on an isError result, 2 on a usage error.

MCP server

bash
npx -y @reneturcios/fleetwatch mcp

MCP client config:

json
{  "mcpServers": {    "fleetwatch": {      "command": "npx",      "args": ["-y", "@reneturcios/fleetwatch", "mcp"]    }  }}

Docker

bash
docker run -i ghcr.io/cloudcorprecords/fleetwatchdocker 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

bash
npm installnpm run buildnpm testnpm run dev

The test suite runs entirely against a stubbed JSON-RPC upstream — no live network calls.

License

MIT — see LICENSE.

Source: README.md at commit ad8438b

Tools

4

list_agents

List agents

List this organization's ET Ducky agents (Windows and Linux endpoints) with OS, agent version, online state, last heartbeat, last signed-in user, isolation state and tags. Sorted by hostname.

Parametersostaglimitonlinesearch

get_agent

Get agent

One agent with its latest health sample (CPU, memory, free space on C:, uptime, pending reboot, make and model) and its number of active alerts.

Parametersagent_idrequired

list_alerts

List alerts

Alerts raised for this organization's agents, newest first.

Parameterslimitstatusagent_idseveritysince_hours

get_fleet_summary

Get fleet summary

Counts for this organization: agents, online, offline, Windows, Linux, other OS, isolated, and active alerts by severity.

Takes no parameters.

Version history

1
  1. v0.1.0LatestNov 4, 2026

Score

90% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 days25 pts
  • Auth declared10 pts

    Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.

  • Tools listedRequired15 pts
  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts