timeseries-mcp

decompose

Separate a time series into trend, seasonal, and residual components, and compute the strength of each part.

Instructions

Split the series into trend/seasonal/residual and quantify each component's strength.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "series_id": "<series_id>",
      "period": "<period>"
    },
    "name": "decompose"
  }
}

Input Schema

Name	Required	Description	Default
`method`	No	STL is robust to outliers.	stl
`period`	Yes	Observations per season, e.g. 288 for daily @ 5min.
`series_id`	Yes

Output Schema

Name	Required	Description
`method`	Yes
`period`	Yes
`series_id`	Yes
`components`	Yes
`interpretation`	Yes
`trend_strength`	Yes	0-1; Hyndman F_T = max(0, 1 - Var(resid)/Var(trend+resid)).
`seasonal_strength`	Yes	0-1; Hyndman F_S = max(0, 1 - Var(resid)/Var(seasonal+resid)).

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Jul 30, 2026

TDQS

C2.8/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the core function (split and quantify) but omits important traits: that it is a read-only operation, any data requirements (e.g., sufficient length), or how it handles missing values. The word 'quantify' is vague.

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?

Single sentence that is front-loaded with the main action ('Split the series') and includes the key outputs. No redundant words or filler.

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 the complexity of decomposition (two methods, seasonal period logic, output schema present), the description is too sparse. It does not explain the two available methods (STL vs classical) or their trade-offs, nor does it clarify that 'quantify each component's strength' refers to metrics like relative strength. The output schema is not referenced but could have been used to supplement this dimension.

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 description coverage is 67% (method and period have descriptions; series_id does not). The tool description does not add any parameter-level meaning beyond what the schema provides. For series_id, no context is given on what constitutes a valid ID (e.g., must exist in the system).

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?

Description clearly states the tool splits a series into trend/seasonal/residual and quantifies component strength. It uses a specific verb 'split' and identifies the resource 'series' and components. While it doesn't explicitly differentiate from sibling tools like stationarity or trend_test, the purpose is unambiguous and distinct for decomposition tasks.

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 on when to use this tool versus alternatives like stationarity or trend_test. It does not mention prerequisites (e.g., series must be seasonal), exclusions (e.g., not for irregular data), or when decomposition is appropriate.

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

Deploy Server