claude mcp add openitcockpit-mcp-server -- npx -y openitcockpit-mcp-server
A pasteable skeleton generated from the repository name. Check the project README for the exact package and arguments.
Star count
0 ★ · openITCOCKPIT/openITCOCKPIT-MCP-Server · read from the GitHub search API · (checked 2026-10-16 20:00:20)
Source
collected from the punkpeye/awesome-mcp-servers list · type: MCP server
Harvest history
first seen 2026-10-09 · last seen 2026-10-16 · seen 32× · listed by 7 sources
Score
score 703 · 7 sources · mcp
FAQ (answers come from our records)
How do I install it?
We did not find an install command for this repository (our install coverage is only about 4%). Check its README or releases page.
Who is it for?
We filed it under these tags: MCP 服务. The tags come from the entry itself, not a taxonomy we imposed.
Who maintains it?
repository openITCOCKPIT/openITCOCKPIT-MCP-Server;first catalogued 2026-10-09;last seen 2026-10-16。There is no official certification or quality rating here — we record sources and dates only.
An MCP server that puts an openITCOCKPIT monitoring instance in front of an LLM client: what is broken and why, what someone already handles, what changed - and, off by default, the tools that act on it. > [!CAUTION] > **Use at your own risk.** This server lets a language model read and - with write > tools enabled - change your monitoring configuration. A model can misunderstand a > request or pick the wrong call. Review what it proposes before you approve it, and > start with read-only access. The software is provided "as is", without warranty > or liability of any kind; see the MIT License. - **Requires openITCOCKPIT 5.6 or newer** (compatibility). - **42 tools**, 20 read-only and 22 that change something. - **Write tools are off by default** and are not registered until you enable them. - **Names, never IDs.** Tools take hostnames, template names and container paths; the server resolves them. - **Scope-checked writes.** References are validated against the target container before anything is sent, which openITCOCKPIT's own API does not do. Quickstart Point your client at http://localhost:8000/mcp with the bearer token from your .env. Compose reads that same file for the published port, so setting OITC_PORT there moves both sides at once. Three settings matter to start: MCP_AUTH_TOKEN (what clients present to this server), OITC_BASEURL and OITC_APIKEY (what this server presents to openITCOCKPIT). Everything else has a default - all of it. What you can ask it | Ask | What answers it | |---|---| | "What is broken right now?" | get_problem_overview - causes separated from their consequences | | "Why is db-01 critical?" | get_service_health, investigate_problem | | "Is anyone on it already?" | the same tools: downtime and acknowledgement come with the state | | "What happened during the night shift?" | get_shift_summary | | "Why did I get no alert for web01?" | explain_notification | | "Take web01 out until Monday" | schedule_downtime (write) | | "Which templates could web-05 use?" | get_allowed_elements_for_container | Every tool by name, with its parameters and what it costs in context: **docs/tools.md**, generated from the code. What a result looks like and what happens when you write: **docs/using-the-tools.md**. Limiting an instance Running a monitoring instance is not one job, so a surface small enough to be easy would be too small to be useful. Instead the server keeps every tool the work needs and a toolset hands one agent its share: around ten tools, complete for that job and nothing beyond it. A tool that was never registered cannot be called at all. The shipped sets are health, operations, lifecycle, patch, reporting, catalog, onboarding, config and provisioning. Sets are defined in a file you can replace: docs/toolsets.md. Measuring a model oitc-mcp-eval asks operator questions against your instance and checks whether a model answers them from the tools instead of inventing. It keeps every run in