Skip to main content
Glama

ml-lifecycle-mcp

An MCP server that exposes a time series forecasting model as a tool, with a built-in audit trail for every call.

Why this project

Two things prompted this:

  1. A conversation with an RBC contact about the Model Context Protocol as a way to expose internal ML/data tools to LLM clients in a standardized way.

  2. RBC Borealis's own research focus areas include time series analysis and NLP — this project picks time series as the first concrete capability, built the way I'd want a production tool to be built, not a notebook demo.

The goal isn't "wrap a model in MCP." It's: what does it take for an ML capability to be trustworthy enough to hand to an autonomous client? That means typed interfaces, input validation, tests that cover the failure modes (not just the happy path), and — carried over from a separate project of mine, ai-governance-gateway — an audit log of every call, since "what happened and with what inputs" is the first question anyone asks when a model-backed system misbehaves.

Related MCP server: Enterprise MCP Gateway and Tool Registry

Architecture

src/ml_lifecycle_mcp/
  forecasting.py   # the model: Holt-Winters exponential smoothing (statsmodels),
                    # wrapped behind a typed function so the tool layer never
                    # touches statsmodels directly
  audit.py          # AuditLogger — context manager that records every call
                     # (timing, input shape, success/failure) as JSON lines
  server.py         # FastMCP server: registers `forecast_timeseries` as an
                     # MCP tool, wraps it with the audit logger
  web.py             # Starlette app: a browser UI over the same model +
                      # the same audit log, for demoing without an MCP client
  static/            # index.html / style.css / app.js — the browser UI
tests/
  test_forecasting.py  # model correctness + input validation
  test_audit.py        # logging behavior, including the failure path
  test_server.py        # the tool function as a client would call it
  test_web.py            # the HTTP API as a browser would call it

Design choices worth knowing about, and their limitations:

  • Confidence intervals are approximated from in-sample residual standard deviation under a normal-residual assumption, not from statsmodels' simulation-based intervals. That's a reasonable trade for a lightweight service, but it understates uncertainty for short or non-stationary series. A production version would switch to get_prediction() with simulated paths.

  • Audit logging defaults to shape-only (list length, types), not raw values, since forecasting inputs may be business-sensitive. log_values=True exists for local debugging but shouldn't be turned on against real data without a retention/PII policy — same lesson as the governance gateway project.

  • One tool, on purpose. This was scoped to be small and correct rather than broad. An NLP tool (sentiment/summarization) following the same pattern — typed wrapper, audited, tested — is the natural next addition.

  • The web UI adds zero new dependencies. mcp already pulls in starlette and uvicorn transitively, so web.py uses those directly instead of adding FastAPI on top. It shares the same AuditLogger instance (same default log file) as the MCP server, so a call made from Claude Desktop and a call made from the browser both show up in one audit trail — the log shouldn't care which door a request came through.

Setup

python -m venv .venv
source .venv/bin/activate        # Windows: .venv\Scripts\activate
pip install -e ".[dev]"

Running the tests

python -m pytest -v

Running the server

python -m ml_lifecycle_mcp.server

This starts an MCP server over stdio. To use it from Claude Desktop, add it to claude_desktop_config.json:

{
  "mcpServers": {
    "ml-lifecycle-mcp": {
      "command": "/absolute/path/to/.venv/bin/python",
      "args": ["-m", "ml_lifecycle_mcp.server"]
    }
  }
}

Then ask Claude something like: "Forecast the next 5 points of [10, 12, 13, 15, 14, 17, 19, 20]" — it will call forecast_timeseries and every call gets written to audit_log.jsonl in the working directory.

Running the web UI

python -m ml_lifecycle_mcp.web

Open http://127.0.0.1:8000. Paste a series, set a horizon, hit run forecast — you'll see the series plotted with the forecast segment and its 80% confidence band, and the audit log panel underneath updates with every call. This is the same model and the same audit trail the MCP tool uses, just reachable without an MCP client — useful for a live demo when you don't want to depend on Claude Desktop being configured correctly in the room.

Example

from ml_lifecycle_mcp.server import forecast_timeseries

forecast_timeseries(values=[10, 12, 13, 15, 14, 17, 19, 20], horizon=3)
# {'forecast': [21.21, 22.60, 23.98],
#  'lower_80': [20.32, 21.70, 23.08],
#  'upper_80': [22.11, 23.49, 24.87],
#  'method': 'holt_winters_trend'}

Available Tools

1 tool
forecast_timeseriesA

Forecast future values of a univariate time series.

Args: values: Historical observations in chronological order (minimum 4 points). horizon: Number of future steps to forecast. seasonal_periods: Length of one seasonal cycle (e.g. 12 for monthly data with yearly seasonality), if the series is seasonal. Omit if unknown or the series is too short to estimate seasonality reliably.

Returns: Point forecast plus an approximate 80% confidence interval, and the method actually used (seasonal models silently fall back to a trend-only model if there isn't enough data for the requested period).

ParametersJSON Schema
NameRequiredDescriptionDefault
valuesYes
horizonYes
seasonal_periodsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
methodYes
forecastYes
lower_80Yes
upper_80Yes

TDQS

A4.5/5.0
Behavior4/5

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

No annotations provided, so description carries full burden. It discloses return format (point forecast + approximate 80% CI) and behavioral traits (seasonal models fall back to trend-only if data insufficient). No destructive or auth concerns for forecast 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?

Description is well-structured with Args and Returns sections. Front-loaded with purpose. Some redundancy in repeating parameter descriptions, but overall efficient. Every sentence adds value.

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?

Given 3 parameters (2 required) and existing output schema, description covers all necessary aspects: input constraints, seasonal fallback, return format. Agent has enough information to use tool correctly.

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

Parameters5/5

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

Schema coverage is 0%, so description fully explains parameters. 'values' specifies chronological order and minimum 4 points; 'horizon' is number of steps; 'seasonal_periods' explains its meaning and usage. Adds meaning beyond types and titles in schema.

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?

Description clearly states the tool forecasts future values of a univariate time series. The action (forecast) and resource (time series) are specific and unambiguous. No sibling tools exist, so differentiation is not required.

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?

Description provides usage context: minimum 4 data points, seasonal behavior and fallback logic. It advises when to omit seasonal_periods (if unknown or too short). While no explicit when-not-to-use is given, the guidance is sufficient for proper invocation.

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. 1 tool updatev0.1.0
    • First observedforecast_timeseries

TDQS

A4.1/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of confusion or overlap between tools. The single tool's purpose is clearly described.

Naming Consistency5/5

There is only one tool, so naming consistency is trivially maintained. The name 'forecast_timeseries' follows a clear verb_noun pattern.

Tool Count2/5

The server name implies a broad ML lifecycle scope, but it exposes only one forecasting tool. This is far too few tools to cover the intended domain, making the count inappropriate.

Completeness1/5

The server claims to handle an ML lifecycle but provides only a time series forecasting tool. Essential operations like data preprocessing, model training, evaluation, and deployment are missing, resulting in a severely incomplete surface.

Maintenance

ActivityStale
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    C
    maintenance
    A Model Context Protocol (MCP) server that integrates the FAIM time series forecasting SDK with any MCP-compatible AI assistant, enabling AI-powered forecasting capabilities.
    2
    5 npm
    8
    MIT
  • A
    license
    Not graded
    quality
    B
    maintenance
    Exposes enterprise KPIs, health scores, forecasting, and anomaly detection as MCP tools, resources, and prompts for use by any MCP-compatible agent.
    AGPL 3.0