Docs

How the tools are built

The catalog has three kinds of tool. The kind decides how you install and run it.

Install

Published tools are on npm. Pick whichever of these fits how you work.

npx -y <tool>

npm i -g <tool>

git clone https://github.com/lidless-labs/<tool>.git
cd <tool> && npm install && npm run build

The Node tools need Node 20 or newer. Python tools name their version on the tool page.

Connect an AI client

Any MCP client works. Swap <tool> and the variables for the ones listed on the tool's page.

claude mcp add <name> \
  -e SYSTEM_URL=https://system.example.net \
  -e SYSTEM_API_KEY=... \
  -- npx -y <tool>

{
  "mcpServers": {
    "<name>": {
      "command": "npx",
      "args": ["-y", "<tool>"],
      "env": {
        "SYSTEM_URL": "https://system.example.net",
        "SYSTEM_API_KEY": "..."
      }
    }
  }
}

[mcp_servers.<name>]
command = "npx"
args = ["-y", "<tool>"]

[mcp_servers.<name>.env]
SYSTEM_URL = "https://system.example.net"
SYSTEM_API_KEY = "..."

{
  "mcpServers": {
    "<name>": {
      "command": "npx",
      "args": ["-y", "<tool>"],
      "env": {
        "SYSTEM_URL": "https://system.example.net",
        "SYSTEM_API_KEY": "..."
      }
    }
  }
}

command:  npx
args:     -y <tool>
env:      SYSTEM_URL, SYSTEM_API_KEY, ...

Restart the client after editing its config. Most clients only read the server list at startup.

Credentials

Tools read connection details from environment variables, named after the system they talk to.

<SYSTEM>_URL        where the system lives, e.g. https://siem.lan:55000
<SYSTEM>_API_KEY    or a token / username + password, depending on the system

Start with a read-only account

Create a dedicated user or API token for the tool with read-only permissions. Upgrade its role later, once you have seen how your agent uses it. Most tools are useful without any write access.

Keep secrets out of shared configs

Client config files often end up in dotfile repos. Where your client supports it, reference variables from your shell or a secret manager rather than pasting keys inline. Several tools also redact secrets from their own logs and error messages.

Write gates

An agent can read freely, but it has to be told explicitly before it changes anything. Tools that can write use up to three tiers.

A refused call returns an error and sends nothing to your system. If you see one, the gate is doing its job. The Safety section on each tool page lists its exact flags.

Self-signed certificates

Homelab and SOC systems often run with self-signed TLS.

Tools that talk HTTPS have their own verify flag, for example MISP_VERIFY_SSL=false or LIBRENMS_TLS_INSECURE=1. The relaxation applies only to that tool's requests to that system, never the whole process. A better fix is to add your internal CA to the trust store and leave verification on.

Scripts and cron

The companion CLIs cover the jobs you want on a schedule rather than in a chat.

They read the same environment variables as the MCP server, so one set of credentials serves both. They default to reads, which makes them safe to run from cron or CI. Each tool's README lists its commands.

Troubleshooting

Updates and security

Releases are listed in the changelog.

npm i -g <tool>@latest      # global install
npx -y <tool>@latest        # on-demand; npx otherwise reuses its cache

Found a vulnerability?

Report it privately through the repository's Security tab on GitHub rather than a public issue. Bugs and feature requests go in the repo's issues.