Skip to main content
Glama
leemarcum

operational-data-mcp

by leemarcum
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

operational-data-mcp

A Model Context Protocol server that exposes operational and industrial telemetry to Claude and other MCP clients.

It ships with a sample ice cream packaging plant dataset (three machines, three days of hourly production, scheduled downtime events, and a couple of injected anomalies) so it works out of the box. Point it at your own JSON data via an environment variable to use it on real workloads.

npx operational-data-mcp

That's a working MCP server on stdio, no install step. Run on its own it sits silent waiting for a client, which is correct behavior for stdio transport.

To see what it actually does without wiring up a client first:

git clone https://github.com/leemarcum/operational-data-mcp
cd operational-data-mcp && npm install && npm run demo

npm run demo starts the server, calls every tool over stdio, and prints exactly what an MCP client receives — throughput attainment per machine, statistical outliers in the hourly counts, and the downtime events behind them.

The rest of this README explains why it exists, how to wire it into Claude Desktop, what each tool does, and how to extend it for your own plant or operational system.

Why this exists

Most "AI agent for operations" demos either skip the data-integration problem entirely or hand-wave it with a generic SQL connector. The hard part of doing this work for real is somewhere else: operational systems were built before MCP existed, the data is fragmented across vendors and protocols, and the security boundaries are there for good reasons.

I built this because I wanted a clean reference implementation of the pattern I keep using on real plants — a single MCP server that normalizes operational data into a few well-shaped tools an LLM can reason about. List your assets. Query production. Roll up throughput against target. Find the hours that look wrong. Same five questions on every plant floor, regardless of vendor.

The dataset is small on purpose. Replace it with yours and the same questions still apply.

Related MCP server: TrakSYS MCP Server

What you get

Five tools, three resources, one bundled dataset:

Tool

What it does

list_assets

Returns every machine in the dataset with metadata (line, vendor, controller, target throughput).

query_production

Filters hourly production counts by asset id and time window.

query_downtime

Filters downtime events by asset, cause code, or time window.

summarize_throughput

Rolls up attainment percentage and downtime minutes per asset over a window.

find_anomalies

Runs a simple z-score anomaly detector over hourly production counts.

Three resources (raw JSON, addressable by URI):

  • opdata://datasets/assets

  • opdata://datasets/production

  • opdata://datasets/downtime

Install and wire into Claude Desktop

Add this block to your claude_desktop_config.json (Settings → Developer → Edit Config):

{
  "mcpServers": {
    "operational-data": {
      "command": "npx",
      "args": ["-y", "operational-data-mcp"]
    }
  }
}

Restart Claude Desktop. The five tools above will appear in the tool drawer. Ask Claude things like:

Roll up Line A's attainment for June 2 and tell me what drove the gap from target.

Are there any hours on the Line B cartoner that look like anomalies? What was happening around them?

What's the most common downtime cause across all three assets?

Use your own data

The server reads three JSON files from a directory. Set OPDATA_DATA_DIR to point at yours:

{
  "mcpServers": {
    "operational-data": {
      "command": "npx",
      "args": ["-y", "operational-data-mcp"],
      "env": {
        "OPDATA_DATA_DIR": "/absolute/path/to/your/data"
      }
    }
  }
}

The directory must contain assets.json, production.json, and downtime.json. Schemas (intentionally minimal):

assets.json — array of:

{
  "id": "LINE-A-FILLER",
  "name": "Line A Pint Filler",
  "line": "A",
  "type": "filler",
  "target_per_hour": 4800,
  "vendor": "Tetra Pak",
  "controller": "Allen-Bradley CompactLogix"
}

production.json — array of:

{ "timestamp": "2026-06-01T06:00:00Z", "asset_id": "LINE-A-FILLER", "count": 4720 }

downtime.json — array of:

{
  "asset_id": "LINE-A-FILLER",
  "start": "2026-06-02T02:00:00Z",
  "minutes": 90,
  "cause_code": "CIP_WASHDOWN",
  "note": "Scheduled clean-in-place"
}

Anything extra in those objects is preserved and returned to the client. That's intentional — keeps the schema honest while letting you carry your own metadata through.

Run from source

git clone https://github.com/leemarcum/operational-data-mcp
cd operational-data-mcp
npm install
npm start

Inspect interactively with the official MCP Inspector:

npm run inspect

To regenerate the bundled sample data:

node scripts/generate-fixtures.js

Where this goes next

Honest list of what I'd add when a real use case shows up:

  • Streaming sources — swap the file-backed store for a Kafka/MQTT subscriber so production data flows in live. The tool surface stays the same; only the store layer changes.

  • More analyzers — OEE rollups, shift comparisons, changeover-time tracking. All composable on top of the same primitives.

  • Auth and RBAC — once an MCP server starts touching real operational data, you need ABAC at the tool level. The MCP protocol supports this; this reference doesn't implement it yet.

  • Bridging legacy controllers — most plants I've worked in have at least one machine speaking Modbus or OPC UA. A thin adapter that polls those and writes into this server's format gets you most of the way.

If you're using this for something real and want one of those, open an issue.

Why I built it

I spent fifteen years working in industrial automation — robotics, controls, plant networking — while writing production software in parallel. The pattern this server demonstrates is the one I keep using on real plants: take fragmented operational data that nobody can easily query, put it behind a small set of well-shaped tools, and let an LLM (or anyone else) answer the same five questions about it that an experienced operator would ask.

The cleanest production version of that pattern was at an ice cream plant where I networked previously-isolated lines together for real-time downtime and throughput visibility. The bundled dataset is a sanitized echo of what that data looked like.

— Lee Hunter Marcum github.com/leemarcum

License

MIT. See LICENSE.

Available Tools

5 tools
find_anomaliesFind AnomaliesA

Run simple z-score anomaly detection on production counts. Returns timestamps where an asset's hourly count is more than threshold standard deviations away from its mean.

ParametersJSON Schema
NameRequiredDescriptionDefault
asset_idNoLimit to one asset; otherwise checks all assets
thresholdNoZ-score threshold (default 2.0)

TDQS

A3.9/5.0
Behavior3/5

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

Since no annotations are provided, the description carries the burden. It adds context about the algorithm (z-score, standard deviations from mean) and the meaning of the threshold, but does not explicitly state whether the operation is read-only, how it handles missing asset_id (all assets), or any side effects. It also does not clarify the full return structure beyond timestamps.

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?

The description is two sentences long and immediately states the tool's purpose and output. There is no redundancy or irrelevant information; every word contributes to understanding.

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

Completeness3/5

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

The tool is relatively simple with 2 optional parameters and no output schema. The description explains the algorithm and that timestamps are returned, but it does not specify the full return format (e.g., whether it includes the anomaly score or value) or the scope when asset_id is omitted. This is a gap given the absence of an output schema, but the description is otherwise adequate.

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 coverage is 100%, so baseline is 3. The description adds meaningful context by explaining the threshold's role ('more than threshold standard deviations away from its mean') and introduces the concept of 'hourly count,' which is not in the schema. This adds value beyond the schema's parameter descriptions.

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 clearly states a specific action ('Run simple z-score anomaly detection') on a specific resource ('production counts'), and explains the output ('Returns timestamps'). This distinguishes it from sibling tools like list_assets or query_production, which serve different purposes.

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

Usage Guidelines3/5

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

The description implies when to use the tool (when you need to detect anomalies in production counts), but does not explicitly state when not to use it or mention alternative tools like query_production. There are no exclusions or comparisons, so guidance is only implicit.

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

list_assetsList AssetsB

List all machines / production lines in the operational dataset, with their metadata (type, line, target throughput).

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.3/5.0
Behavior3/5

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

No annotations are provided, so the description carries full responsibility for behavioral transparency. The description indicates it's a read operation listing items with metadata, which implies non-destructive behavior. However, it doesn't disclose whether the list is paginated, ordered, or if authentication is required. A score of 3 is appropriate as it conveys basic read behavior but lacks depth.

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?

The description is a single sentence that efficiently conveys the tool's purpose and the data it returns. Every word contributes meaning, with no wasted content. It is optimally concise.

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

Completeness3/5

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

Given the tool has zero parameters, no output schema, and no annotations, the description provides adequate but minimal information. It explains what is listed and what metadata is included, but lacks details on pagination, sorting, or authentication. For such a simple tool, the description is sufficient to understand its core function, but not thoroughly complete.

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?

The schema has no parameters and 100% description coverage, so the baseline is 3. The description does not add parameter-level details since there are none, but it explains what metadata is returned (type, line, target throughput), providing some value beyond the empty schema.

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 the tool lists all machines/production lines with their metadata. It specifies the verb 'list' and resource 'machines / production lines', and distinguishes itself from siblings that focus on production queries, downtime, throughput, and anomalies.

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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites or situations where one of the sibling tools would be more appropriate. The agent is left to infer usage from the name alone.

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

query_downtimeQuery Downtime EventsC

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

ParametersJSON Schema
NameRequiredDescriptionDefault
endNo
limitNo
startNo
asset_idNo
cause_codeNoFilter by downtime cause code, e.g. 'JAM', 'CHANGEOVER'

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.

query_productionQuery Production CountsB

Return hourly production counts, optionally filtered by asset id and/or time range. Time range is ISO 8601 timestamps.

ParametersJSON Schema
NameRequiredDescriptionDefault
endNoISO timestamp upper bound
limitNoMax number of rows to return
startNoISO timestamp lower bound
asset_idNoAsset id to filter on, e.g. 'LINE-A-FILLER'

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It doesn't specify whether this is a read-only operation, if it requires specific permissions, if results are paginated beyond the limit parameter, or the structure of the returned data. The hint about ISO 8601 timestamps is helpful but insufficient for a data-returning tool.

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

Conciseness4/5

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

The description is very short—two sentences with no fluff. It's front-loaded with the main purpose and then adds the optional filter details. It's concise but perhaps too sparse given the lack of annotations and output schema.

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?

There is no output schema, so the description must explain what the tool returns, but it doesn't. The tool has 4 optional parameters, which may require guidance on default behavior (e.g., if no time range given, does it return the last hour? all data?). The lack of behavioral transparency and return value documentation leaves significant gaps for an agent to use this tool correctly.

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 the baseline is 3. The description mentions 'asset id and/or time range' which maps to the asset_id, start, and end parameters, but adds no extra semantics beyond what the schema already states. The time range format hint ('ISO 8601 timestamps') is valuable but repeats the schema's property descriptions.

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 hourly production counts and notes optional filtering by asset id and/or time range. The verb 'query' plus the resource 'production counts' makes the purpose specific, but it doesn't explicitly differentiate from sibling tools like query_downtime or summarize_throughput.

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

Usage Guidelines3/5

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

The description provides context on when to use it—for hourly production counts with optional filters. However, there are no explicit guidelines on when not to use it versus alternatives like summarize_throughput or find_anomalies, leaving the agent to infer based on the tool name.

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

summarize_throughputSummarize ThroughputA

Roll up production counts vs. target throughput per asset. Returns total produced, target, attainment ratio, and downtime minutes per asset over the (optionally bounded) time window.

ParametersJSON Schema
NameRequiredDescriptionDefault
endNo
startNo

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries the burden of disclosing behavior. It describes the tool as a read-style roll-up returning aggregated metrics, which implies non-destructive behavior. However, it does not mention error handling, time zone assumptions, data freshness, or whether the operation is safe/read-only, leaving some gaps.

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?

The description is two sentences long, front-loaded with the core purpose. Every sentence adds value: the first defines the action, the second lists return fields. No redundant or vague language.

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

Completeness3/5

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

For a tool with no output schema, the description partially compensates by listing return fields. However, it does not describe the output structure (e.g., list of objects, keys), error responses, or handling of empty results. Given the low complexity, it is adequate but not fully complete.

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 coverage is 0%, so the description must compensate. It names the time window as 'optionally bounded' and implies start and end are the boundaries. But it does not specify the expected format (e.g., ISO 8601), inclusive/exclusive behavior, or defaults when omitted. The addition is modest but not fully sufficient.

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 clearly states the tool's function: it rolls up production counts versus target throughput per asset. It specifies the return values (total produced, target, attainment ratio, downtime minutes) and the time window. This differentiates it from sibling tools like query_production (raw data) and query_downtime (specific metric).

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 such as query_production or query_downtime. The description only states what the tool does, without context for choosing among siblings or noting prerequisites.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 5 tool updatesv0.1.0
    • First observedfind_anomalies
    • First observedlist_assets
    • First observedquery_downtime
    • First observedquery_production
    • First observedsummarize_throughput
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.5/5.0

Scored across 5 tools

Disambiguation5/5

Each tool targets a distinct purpose: listing assets, querying production, querying downtime, summarizing throughput, and detecting anomalies. There is no overlap in functionality, making it easy for an agent to select the correct tool for a given task.

Naming Consistency4/5

All tool names follow a clear verb_noun pattern (e.g., list_assets, query_production). The only minor deviation is 'find_anomalies' instead of 'list_anomalies' or 'query_anomalies', but it still maintains the verb_noun structure and is consistent with the overall style.

Tool Count5/5

With 5 tools, the server is well-scoped for an operational data analysis domain. Each tool provides essential functionality without being excessive, covering asset listing, data querying, summarization, and anomaly detection appropriately.

Completeness3/5

The tool set covers core querying and analysis needs (production, downtime, throughput, anomalies) but lacks write operations (e.g., adding or updating assets/events) and more advanced analysis (e.g., trend forecasting). This is acceptable for a read-only data exploration server, but leaves gaps for full lifecycle management.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • TrakSYS MCP Server

    EA2-Programmer
    A
    license
    Not graded
    quality
    D
    maintenance
    An MCP server that provides secure, read-only access to the TrakSYS manufacturing analytics platform through entity-based tools and guided investigation prompts. It enables users to interact with manufacturing databases and perform data analysis via natural language.
    MIT

  • MCP PLC Core

    Maxkrempl
    F
    license
    B
    quality
    B
    maintenance
    Universal MCP server for industrial PLC communication, enabling AI agents to read sensors, alarms, status, setpoints, and write setpoints via adapters for Modbus, S7, or custom PLCs.
    6
    -