operational-data-mcp

Query Downtime Events

query_downtime

Retrieve downtime events from industrial systems, filtered by asset ID, time range, or cause code, to identify production stoppages and analyze operational issues.

Instructions

Return downtime events, optionally filtered by asset id, time range, or cause code.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "query_downtime"
  }
}

Input Schema

Name	Required	Description
`end`	No
`limit`	No
`start`	No
`asset_id`	No
`cause_code`	No	Filter by downtime cause code, e.g. 'JAM', 'CHANGEOVER'

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Aug 17, 2026

TDQS

C2.8/5.0

Behavior3/5

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

With no annotations, the description carries full behavioral burden. It correctly implies a read-only query (not destructive) via 'Return downtime events', which is appropriate. However, it does not disclose potential performance impacts of unfiltered queries, date format expectations, or whether results are sorted or paginated (the limit parameter hints at pagination but is not explained).

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 a single sentence, which is concise, but it omits necessary detail for a tool with 5 parameters and no output schema. Every sentence should add value; here, the sentence is adequate but incomplete for the complexity.

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

Completeness2/5

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

Given 5 parameters, 0 required, no output schema, and complex sibling tools, the description is under-specified. It does not mention return format (e.g., list of events with fields), default behavior (e.g., recent events if no time range), or error handling. The description covers only the general purpose, leaving gaps for an agent to resolve.

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

Parameters2/5

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

Schema coverage is only 20% (only cause_code has a description). The description mentions filtering by asset id, time range, or cause code but does not explain the format of start/end (e.g., ISO 8601, Unix timestamp) or the meaning of asset_id. It adds value by grouping filters but lacks critical details that would help an agent use parameters correctly.

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 clearly states it returns downtime events with optional filters by asset id, time range, or cause code. This distinguishes it from siblings like list_assets (assets) or query_production (production events), though it could more explicitly contrast with these related tools.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like find_anomalies or summarize_throughput. The description does not mention exclusions, prerequisites, or context for interpretation (e.g., that downtime may overlap with production data).

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

Deploy Server