openITCOCKPIT MCP Server

Official

by openITCOCKPIT

Overview Schema Source Related Servers Discussions Admin

Python

Remote

Installed Software

list_installed_software

Read-onlyIdempotent

List installed software on a host from the openITCOCKPIT agent inventory. Filter by package name or show only outdated packages to identify pending updates.

Instructions

Software installed on a host, from the openITCOCKPIT agent's inventory. OS is auto-detected (Linux, Windows, macOS).

A host carries hundreds to thousands of packages. Pass name_filter to search by package name, or only_updatable=True for just the outdated ones. For updates across the whole estate use find_pending_updates.

A host with no agent inventory at all raises, rather than returning zero rows.

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	Maximum rows to return. Defaults to 50, maximum 500.
`hostname`	Yes	Exact host name. Required - there is no estate-wide form of this tool. A name that matches no host is answered with the tools that can find the right one.
`name_filter`	No	Substring to search for in the name. Empty returns everything, capped by limit.
`only_updatable`	No

Output Schema

TableJSON Schema

Name	Required	Description
`hint`	No	How to narrow the query when truncated.
`count`	Yes	Number of rows in `items`.
`items`	Yes	The rows, at most `limit` of them.
`truncated`	Yes	True if openITCOCKPIT held more rows than were returned.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.5.0Sep 18, 2026

changedInput schema / properties / hostname / description

Previous value: -"Exact host name. Required - there is no estate-wide form of this tool. Get a name from list_services_by_state, list_log_entries or get_container_tree first."New value: +"Exact host name. Required - there is no estate-wide form of this tool. A name that matches no host is answered with the tools that can find the right one."

First observedv0.1.0Sep 7, 2026

TDQS

A4.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, lowering the bar. The description adds valuable non-obvious behavior: a host with no agent inventory raises instead of returning zero rows, and the OS is auto-detected. This goes beyond what annotations alone convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short paragraphs each serve a distinct purpose: definition, filtering guidance with alternative tool, and edge-case behavior. There is no filler and no redundant restatement of schema details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present and annotations covering safety and idempotence, the description covers the key non-obvious edge case, the alternative tool, and filtering guidance. An agent has enough context to select and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers 3 of 4 parameters, and the description adds meaning for name_filter and only_updatable, clarifying that name_filter searches by package name and only_updatable=True returns outdated packages. This compensates for the schema not documenting only_updatable.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource and scope: software installed on a host from the openITCOCKPIT agent's inventory, with OS auto-detection. It also explicitly differentiates itself from find_pending_updates, which is for estate-wide updates.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear guidance on when to use this tool: per-host package inventory with optional name_filter or only_updatable filters. It explicitly names the alternative tool for estate-wide update scenarios, and the schema reinforces that this tool has no estate-wide form.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.