MCP Catalog

Last updated

2026-10-17

Every MCP server published from this stack, what each one wraps, and where it fits. Most exist because a service the agent needed to talk to did not have a maintained MCP yet, so I wrote one.

As of 2026-10-17. Repository and package names below were checked against GitHub and the npm registry on that date.

What this is

An index of the MCP servers shipped from this cookbook’s parent stack. Every repo linked here is public. Most follow the same shape: a thin TypeScript wrapper that converts MCP tool calls into authenticated REST or RPC calls against an existing service, with confirmation gates on destructive operations. Several of the newer ones are “ctrl” tools: a CLI first, with an MCP adapter over the same code, and writes off or gated by default.

Two naming quirks to know up front. Some repos were renamed after their npm package shipped, so the npm name and the repository name differ (the npm column below says which). And a few useful servers here are not on npm at all, so the install column matters.

If you are looking for the agent-side patterns for how these get consumed (Claude Desktop, Claude Code, OpenClaw, Hermes Agent, Codex CLI), see mcp-readme-five-clients.md. This guide is about the inventory.

Why this way

Three reasons there are this many of them:

1. Most third-party tools do not ship MCPs yet, or ship thin ones. The 2026-era MCP ecosystem is still mostly experiments. If you want an agent to manage a service that already has a clean HTTP API, the gap between “no MCP” and “good MCP” is a weekend.
2. A purpose-built MCP beats a generic HTTP MCP. A generic http_request MCP forces the agent to remember endpoints, auth schemes, and response shapes. A typed MCP turns the same workflow into named tools with input validation, confirmation gates, and uniform error surfacing.
3. The catalog grows along the workload, not ahead of it. Each MCP in the list below was written because the orchestrator already needed to do that work weekly and was doing it through shell scripts or browser automation.

The cost is maintenance: every MCP is a small TypeScript repo with its own release cadence, README, and schema-drift exposure. That cost is bounded by repo-redeploy.md and the MCP release publish checklist.

Catalog

Grouped by what the underlying service does. Versions move, so see each repo or npm view <package> version for current. The README pattern and the client setup blocks are in mcp-readme-five-clients.md.

Media & home services

Network & infrastructure

Social & publishing

Security operations

The SOC-side stack lands more than ten MCPs against a typical purple-team toolchain (Wazuh, TheHive, Cortex, MISP, Suricata, Zeek, and the two commercial platforms below). Each one has a confirmation gate on destructive operations, and the Wazuh one is read-only.

Network security telemetry

Threat-intel framework

OSINT graph

Code, memory, and skills for agents

miseledger (a local SQLite full-text ledger for agent work history, source in Brigade’s engines/evidence-ledger) is the same family but a CLI, not an MCP.

Agent infrastructure (not MCPs, but agent-facing)

These are not MCPs - they ship as standalone tools the orchestrator or other agents shell out to:

Upstream contributions (not owned, but maintained alongside)

These are not published from this stack but they get tracked in the same release cadence because the agent depends on them:

Conventions across every MCP

The repos share enough that you can read one and predict the rest:

• TypeScript, MCP SDK transport. Almost all speak the official MCP server-stdio transport. Where a server is shared between clients, I run it once behind a loopback-only HTTP endpoint instead, but none of the published packages tunnel MCP over the network.
• Confirmation gates on destructive operations. Anything that deletes, modifies, or restarts production state requires a confirm: true argument. Without it, the tool returns a structured “confirm required” response. The pattern lives in mcp-tool-handler-test-pattern.
• --help on the binary. Every MCP can be launched directly from the command line for smoke checks: npx <mcp-name> --help prints tool list, required env vars, and version.
• Five-client README. Every README includes setup blocks for Claude Desktop, Claude Code, OpenClaw, Hermes Agent, and Codex CLI. See mcp-readme-five-clients.md.
• No hard-coded service URLs. Service base URL, token, and any per-instance flags come from environment variables. The README documents each one.
• Secrets via env, never CLI args. No MCP accepts a token as a command-line argument. It is too easy for it to land in ps, logs, or shell history.
• Secrets injected per server at launch, not stored in client config. Clients like Claude Code forward only a safe environment whitelist plus the explicit env block, so credentials would otherwise end up in plaintext in the client’s JSON. I register each server with a small wrapper as its command: the wrapper reads a mode-0600 env file (the path comes from an environment variable, so each server can point at its own file), exports it, then execs the real server command. The env file itself is rendered from the secret store, and the client config only holds the wrapper path and the server’s script path.

Lifecycle

A new MCP enters the catalog when:

1. The agent has already been doing the same thing through shell/curl/browser automation for at least two weeks.
2. There is no maintained MCP for the service already (or the existing one is too partial to use).
3. The service has a stable, documented API. Reverse-engineering web UI calls is not a basis for an MCP. That work belongs in a browser-automation layer.

A MCP leaves the catalog when:

• The underlying service is decommissioned in the stack.
• An upstream-maintained MCP for the same service ships at parity. In that case, the local MCP is archived with a pointer to the replacement.

Verification

Spot-check that the catalog is honest about what is published:

# Every catalogued npm package resolves.
for pkg in jellyfin-mcp immich-mcp reelgrep-mcp postiz-mcp n8n-ops-mcp maltego-mcp \
           wazuh-mcp thehive-mcp thehive-cortex-mcp misp-mcp rapid7-mcp sophos-mcp \
           suricata-mcp zeek-mcp mitre-mcp \
           @solomonneas/proxmox-mcp @solomonneas/adguard-mcp @solomonneas/librenms-mcp; do
    npm view "$pkg" version >/dev/null 2>&1 \
      && echo "$pkg: OK" \
      || echo "$pkg: MISSING ON NPM"
done

# Every catalogued GitHub repo exists and is public. Expect PUBLIC on every line.
for repo in lidless-labs/jellyctrl lidless-labs/immichctrl lidless-labs/proxmox-mcp \
            lidless-labs/adguardctrl lidless-labs/librenmsctrl lidless-labs/hotwash \
            lidless-labs/maltego-mcp escoffier-labs/graphtrail; do
    echo "$repo: $(gh repo view "$repo" --json visibility -q .visibility)"
done

# Every MCP's repo has a five-client README (for repos you have checked out).
for mcp in jellyfin-mcp postiz-mcp n8n-ops-mcp; do
    grep -E "Claude Desktop|Claude Code|OpenClaw|Hermes|Codex CLI" \
         "$HOME/repos/$mcp/README.md" | wc -l
done    # Expect: 5 per README

A healthy stack: every catalog entry resolves on npm or on GitHub, every README contains all five client blocks, and repo-redeploy.sh is current for the MCPs that need a built dist/ locally.

Gotchas

MCP names on npm and on GitHub are not always identical. cortex-mcp is thehive-cortex-mcp on npm because cortex-mcp was taken. The “ctrl” repos kept their original package names (jellyctrl publishes jellyfin-mcp, n8nctrl publishes n8n-ops-mcp, immichctrl publishes immich-mcp). And the bare proxmox-mcp name on npm is a different author’s package, so mine is scoped. Track both names in the redeploy manifest and in the catalog above, and always check npm view <pkg> repository.url before installing from a name you only half remember.

One shared secrets file means every wrapped server can read every secret. The launch wrapper sources a single env file by default, so a server that only needs its own token still gets the others in its environment. Point MCP_SECRETS_FILE at a per-server file for the high-value ones. The wrapper also logs a warning and carries on if the file is unreadable, so a missing file shows up as a server that fails on missing env vars, not as a wrapper error.

A confirmation gate in one direction is not symmetry. Destructive tools require confirm: true, but the agent has no way to require confirm: false for safety. Defense in depth: also gate the dangerous tools at the agent’s tools.allow policy.

Test fixtures that hit a real API will rot. Each MCP has a fake-server capture pattern for unit tests. The integration-style tests are deliberately not in the repo (see mcp-tool-handler-test-pattern). If you add a new MCP, copy that pattern - do not write tests that hit a live service.

npm publish on a working tree with private files in dist/ will leak. Always npm pack --dry-run before npm publish and review the tarball contents. The MCP release publish checklist lives in the parent repo’s notes and has bitten every catalog entry at least once.

The catalog is the README. Drift between this file and the actual published set is a bug. Pair every new MCP publish with a catalog edit and a git grep <mcp-name> to find stale references.

Templates

• ../templates/ai-stack/ - model alias and adapter snippets that pair with these MCPs
• ../templates/skills/SKILL.md - the skill shape that often wraps a single MCP tool call

Related

• mcp-readme-five-clients.md - the README shape every MCP repo ships with
• repo-redeploy.md - how these stay current on the agent host
• opsdeck.md - the dashboard that surfaces MCP health alongside service health
• ../ai-stack/skills-development.md - skill patterns that wrap MCP tools