openITCOCKPIT MCP Server

Official

by openITCOCKPIT

Overview Schema Source Related Servers Discussions Admin

Python

Remote

Forecast Metric

forecast_metric

Read-onlyIdempotent

Predict when a monitoring metric will hit its warning or critical threshold by analyzing historical trends, reporting the projected date and rate of change.

Instructions

When a measured value reaches its warning or critical threshold, from a straight line through its history. Reports the rate of change, the date and how well the line fits, per metric of the check. Use it for "when will the disk on db01 be full" or "what is filling up".

Input Schema

TableJSON Schema

Name	Required	Description
`hours`	No	How much history the forecast is computed from.
`metric`	No	Only this metric of the check, by its name. Empty: every metric it records.
`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.
`servicename`	Yes	Exact service name on that host. Required. A name that matches no service is answered with the tools that can find the right one.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.5.0Sep 18, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds method transparency (straight-line fit), output specifics (rate of change, date, fit quality), and the no-match behavior for hostname/service (from schema). This goes beyond annotations in a useful way.

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

Conciseness3/5

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

The description is short and includes a helpful example, but the first sentence is grammatically broken, reducing clarity. It's still concise, but the structure suffers from the malformed opening.

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

Completeness4/5

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

Given the fully described schema, rich annotations, and presence of an output schema, the description is almost complete. It explains method, use cases, and outcomes, and doesn't need to restate return values. The only gap is the awkward phrasing, not missing crucial context.

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

Parameters3/5

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

Schema description coverage is 100%, so parameters are fully documented in the schema. The description contributes little additional parameter meaning beyond the schema, except implying per-metric results. Baseline 3 is appropriate given high coverage.

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

Purpose4/5

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

The description conveys a specific predictive purpose: forecasting when a metric crosses a threshold using a straight-line fit, and it mentions that it reports rate of change, date, and fit quality. It is clear enough, though the first sentence is grammatically incomplete and it doesn't explicitly contrast with sibling tools.

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

Usage Guidelines4/5

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

The description gives concrete use cases ("when will the disk on db01 be full" / "what is filling up"), providing clear context for when to use it. It doesn't mention alternatives or exclusions, but the examples sufficiently guide an agent.

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