Hot MCP Server

Node.js client for StatsD, DogStatsD, and Telegraf. The hot mcp server wraps that behind the Model Context Protocol, so an assistant can use it through 14 defined tools rather than through you.

What it actually does

This project was originally a fork off of node-statsd. This project includes many additional changes, including: * uds (Unix domain socket) and tcp protocol support * TypeScript types * Telegraf support * Datadog mode * events * child clients * debug logging * client-side aggregation * much more, including many bug fixes

Its toolset

Everything the assistant can do here goes through one of these:

• host — The host to send stats to, if not set, the constructor tries to
• port — The port to send stats to, if not set, the constructor tries to retrieve it from the DD_DOGSTATSD_PORT environment variable, default: 8125
• prefix — What to prefix each stat name with default: ''. A period separator is automatically added if not present (e.g. my_prefix becomes my_prefix.)
• suffix — What to suffix each stat name with default: ''. A period separator is automatically added if not present (e.g. my_suffix becomes .my_suffix)
• tagPrefix — Prefix tag list with character default: '#'. Note does not work with telegraf option
• tagSeparator — Separate tags with character default: ','. Note does not work with telegraf option
• globalize — Expose this StatsD instance globally. default: false
• cacheDns — Caches dns lookup to host for cacheDnsTtl, only used
• cacheDnsTtl — time-to-live of dns lookups in milliseconds, when cacheDns is enabled. default: 60000
• mock — Create a mock StatsD instance, using a mock transport that doesn't create real sockets
• globalTags — Tags that will be added to every metric. Can be either an object or list of tags. default: {}
• includeDataDogTags — Whether to include DataDog tags to the global tags. default: true. The following Datadog tags are appended to globalTags from the corresponding

Adding it to your client

Setup follows the usual MCP pattern — install or clone the server, register it in your client's configuration file, restart the client.

Configuration

You will need 3 environment variables: DD_AGENT_HOST, DD_ENTITY_ID, DD_DOGSTATSD_URL. The server will not start without them, which is usually why the tools fail to appear on a first run. Keep credentials in your client's env block or a secrets manager rather than in a file you might commit.

When to reach for it

Plenty of monitoring and observability servers cover similar ground. The differences that matter in practice are scope of access and how much setup stands between you and a working tool call. Hot's toolset — host, port, prefix and 11 more — is a fair guide to whether it matches your workflow. It is maintained by bdeitte; worth a glance at recent repository activity before you build anything load-bearing on it.

SyncDev reviews every entry in this directory against the project's own documentation before publishing, and revisits them as servers change.

Caveats

• It runs with your machine's permissions. That is convenient and also the reason to think about what you point it at before you approve a tool call.
• With 14 tools registered it takes up a noticeable share of the context window; turn it off in projects that never touch Hot.
• Missing credentials fail quietly in some clients — if no tools show up, check the environment block first.
• MCP clients confirm each tool call by default. Leave that on until you have watched what the hot mcp server does with a few real requests.