Rather than one tool per network object, the design passes the table as an argument — so anything SuzieQ indexes is reachable without the server growing. The pairing matters: show for the rows, summarize for the shape of them, same filters on both. The one setup trap is documented and easy to hit: the credentials live in a `.env` file next to the entry point, so a client launching from elsewhere needs the working directory set.
An MCP server that fronts the SuzieQ REST API, exposing SuzieQ's two core commands as tools. Any table SuzieQ tracks — devices, interfaces, BGP, routes — is reachable, with the same filter semantics you would use in the CLI.
- Detailed network state from any SuzieQ table, with optional key-value filters such as hostname, VRF or state, returned as a JSON string — `run_suzieq_show`
- Aggregated statistics and summaries over the same tables and filters, for when the per-row detail is not the question — `run_suzieq_summarize`
A running SuzieQ instance with its REST API enabled, plus the endpoint and an access token — `SUZIEQ_API_ENDPOINT` and `SUZIEQ_API_KEY`, both read from a `.env` file in the project directory. Python 3.8 or higher and `uv`; dependencies are `mcp`, `httpx` and `python-dotenv`. It runs over stdio via `uv run python main.py`. If you register it with a client, set the working directory to the project folder so the `.env` file is found.
One command plus a key — npx -y @smithery/cli install @PovedaAqui/suzieq-mcp --client claude, then supply credentials