mcpField
O
openITCOCKPIT

openITCOCKPIT

Local
openitcockpit.ioCloud & Infra0Updated 6w ago

About openITCOCKPIT

openITCOCKPIT is an MCP server for monitoring operators who need to inspect and manage an openITCOCKPIT instance through an LLM client. It offers read-only monitoring tools and optional write tools, which are disabled by default, with toolsets for different operational roles.

Key features

  1. 01Inspect host and service health and problems
  2. 02Review downtime, acknowledgements, and shift summaries
  3. 03Explain notifications and investigate incidents
  4. 04Enable write tools only when configured
  5. 05Limit available tools with operational toolsets

Use cases

  1. 01Identify causes of current monitoring problems
  2. 02Check whether an incident is already being handled
  3. 03Schedule maintenance downtime
  4. 04Restrict an agent to a defined monitoring task

MCP support

The MCP server exposes openITCOCKPIT monitoring and configuration tools to MCP clients. Write tools are not registered unless enabled, and toolsets can limit the available surface.

Configuration

Local server config is the same for every client. Copy it into your client’s MCP config file.

mcp.json · Universal config
{
"mcpServers": {
"openitcockpit": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-e",
"OITC_APIKEY",
"-e",
"OITC_BASEURL",
"-e",
"OITC_TRANSPORT",
"-e",
"OITC_ENABLE_WRITE_TOOLS",
"-e",
"OITC_VERIFY_TLS",
"docker.io/openitcockpit/mcp-server:0.5.0"
],
"env": {
"OITC_APIKEY": "<OITC_APIKEY>",
"OITC_BASEURL": "<OITC_BASEURL>",
"OITC_TRANSPORT": "<OITC_TRANSPORT>",
"OITC_ENABLE_WRITE_TOOLS": "<OITC_ENABLE_WRITE_TOOLS>",
"OITC_VERIFY_TLS": "<OITC_VERIFY_TLS>"
}
}
}
}
Run commanddocker run -i --rm -e OITC_APIKEY -e OITC_BASEURL -e OITC_TRANSPORT -e OITC_ENABLE_WRITE_TOOLS -e OITC_VERIFY_TLS docker.io/openitcockpit/mcp-server:0.5.0
Environment variables to set
OITC_APIKEYSecretAPI key of a dedicated, least-privilege openITCOCKPIT user. This server presents it to openITCOCKPIT; it is never handed to a client.
OITC_BASEURLBase URL of the openITCOCKPIT instance, e.g. https://openitcockpit.example.org - without a path.
OITC_TRANSPORTTransport mode. The image defaults to 'http', which additionally requires MCP_AUTH_TOKEN and a published port; a client that runs this container itself wants 'stdio'.
OITC_ENABLE_WRITE_TOOLSRegister the 15 tools that change the monitoring configuration. Off by default: they are not even registered unless this is 'true'.
OITC_VERIFY_TLSVerify the openITCOCKPIT TLS certificate. On by default; for a self-signed instance set OITC_CA_BUNDLE rather than turning this off.

Local servers need a runtime on your machine (e.g. Node.js 18+). Config file locations differ by client; see your client’s docs.

Packages
ocidocker.io/openitcockpit/mcp-server:0.5.0

Tools

No tool list yet

Local servers expose tools only once running on your machine, and the maintainer has not provided a tool list.

Details

From the project README

openITCOCKPIT MCP Server

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

cp .env.example .env          # fill in the two secrets, see Configuration
docker compose up --build

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

AskWhat 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.

OITC_TOOLSETS=health          # find things and see how they are doing
OITC_TOOLSETS=operations      # acknowledge, maintenance windows, check now
OITC_TOOLSETS=lifecycle       # take things out of the monitoring, or delete them

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 SQLite, so models and changes stay comparable.

oitc-mcp-eval --model your-model --samples 3     # against the configured instance
oitc-mcp-eval --compare                          # newest run of every model
./scripts/eval-throwaway.sh --model your-model   # instance created and removed for you

docs/evals.md.

Documentation

Configurationevery setting, and which secret goes where
Connecting a clientHTTP and stdio, with working examples
InstallationDocker, from source, MCP Registry
Toolsevery tool, generated from the code
Working with the toolsresult shapes, container scope, read-modify-write
Toolsetslimiting an instance, writing your own set
Skills and promptsthe material served alongside the tools
Measuring a modelthe eval, its cases, and reading the results
Securitywhat this server can reach, and what it refuses
Architecturehow the pieces fit together
Tool designthe rules a new tool follows
openITCOCKPIT API notesthe behaviour this server works around
Versioningversion numbers and compatibility
Developmentchecks, tests, running from a checkout

Security in one paragraph

The server holds one openITCOCKPIT credential and never sends it to a client. Clients authenticate with their own token; in delegated mode each request carries a short-lived user token instead, and the server acts as that user with their permissions. Write tools stay unregistered until you enable them. The details, including what to give the openITCOCKPIT user: docs/security.md.

License

MIT.

Comments

Markdown supported

New to MCP?

From what the protocol is to installing your first server, these answers cover most first questions.

An open protocol that defines how AI applications connect to external tools and data in a uniform way. Clients talk to the model; MCP servers provide tools, resources and prompt templates. They exchange standard messages, so one server can be reused by many clients.