Skip to main content
Glama
README.md
# 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_summary
npx @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/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

```bash
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`.