Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@timeseries-mcp Load my temperature data and find anomalies"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Deterministic time-series statistics for AI agents. An MCP server that gives any LLM agent unit-tested statistical tools — anomaly detection, changepoint detection, seasonal decomposition, stationarity/trend tests, data-quality audits, baseline forecasts — with schema-validated structured output and no arbitrary code execution.
Agent: "Is anything wrong with the server room this week?"
load_csv(server_room_temp.csv) → ts1: 1992 points @ 5min
data_quality(ts1) → 1 sampling gap (2h, ~24 points missed)
detect_anomalies(ts1, stl_residual, → 3 spikes flagged, seasonal-context aware
period=288)
detect_changepoints(ts1_daily) → level shift on day 7: 21.4°C → 23.4°C
forecast_baseline(ts1, seasonal_naive) → next hour ± honest backtest error
Agent: "There's a 2-hour telemetry gap on June 4, three temperature spikes,
and a sustained +2°C shift starting June 7 — likely HVAC degradation.
Baseline forecast error is MAE 2.2°C, so alert thresholds under 3°C
will false-positive."Both panels are generated by the library itself — the anomaly markers, gap band, and changepoint segments are real outputs of detect_anomalies, data_quality, and detect_changepoints on the seeded sample datasets (regenerate them).
LLMs are unreliable at arithmetic over long arrays, and the common workaround — handing the model a Python sandbox — is a non-starter in locked-down environments and unauditable everywhere else. The existing "data analysis" MCP servers are mostly run_script shims: the model writes pandas code, executes it server-side, and hopes.
This server takes the opposite position:
Deterministic — same input, same output, every time. Every number comes from a unit-tested routine (57 tests), not model-generated code.
No code execution — the tool surface is 17 typed functions. There is nothing to inject into. Safe for enterprise hosts that cannot allow exec().
Schema-validated — every tool returns a Pydantic model published as an MCP outputSchema, so hosts get structured content they can verify, log, and post-process.
Token-frugal by design — data loads once into a server-side registry and gets a handle (ts1). A million-point series never enters the model's context; every response is capped and previews are evenly thinned.
Related MCP server: openclaw-output-vetter-mcp
Tool | What it does |
| Register a series, get a handle + summary stats back |
| Catalog, distribution summary, capped raw windows |
| Regularize onto a grid; rolling mean/std/min/max/median |
| Gaps, duplicate timestamps, missing values, sampling regularity |
|
|
| Level shifts via CUSUM binary segmentation, MAD-robust noise scale |
| STL / classical split + Hyndman trend/seasonal strength (0–1) |
| ADF + KPSS read together, combined verdict + differencing hint |
| ACF/PACF, significance bounds, seasonal-period suggestion |
| OLS + robust Theil-Sen + Mann-Kendall (tie-corrected) |
| Pearson/Spearman on shared timestamps + best lead/lag scan |
| naive / seasonal-naive / drift / SES, 95% intervals, holdout backtest included |
Plus MCP resources (timeseries://catalog, timeseries://{id}/summary) and a guided analyze_series prompt.
Statistical choices worth noting: anomaly scores are method-honest (MAD falls back with an explanation when 50%+ of values tie); changepoint noise is estimated from first differences so the shifts being hunted don't inflate their own denominator; every forecast ships with a real holdout backtest because a baseline you can't beat is information.
Requires Python 3.11+ and uv.
Claude Code
claude mcp add timeseries -- uvx --from git+https://github.com/Lkhanaajav/timeseries-mcp timeseries-mcpClaude Desktop / Cursor (claude_desktop_config.json / mcp.json)
{
"mcpServers": {
"timeseries": {
"command": "uvx",
"args": ["--from", "git+https://github.com/Lkhanaajav/timeseries-mcp", "timeseries-mcp"],
"env": { "TIMESERIES_MCP_DATA_ROOT": "/path/to/your/csv/files" }
}
}
}Streamable HTTP (remote / multi-client)
uvx --from git+https://github.com/Lkhanaajav/timeseries-mcp timeseries-mcp --transport http --port 8000Try it without an MCP host — the example walkthrough runs the full agent workflow over the in-memory transport, no API key needed:
git clone https://github.com/Lkhanaajav/timeseries-mcp && cd timeseries-mcp
uv sync && uv run python examples/demo.pyMCP host (Claude Code / Desktop / Cursor / any client)
│ stdio or Streamable HTTP
▼
FastMCP server — 17 typed tools, 2 resources, 1 prompt
│ series handles (ts1, ts2, ...) — raw data never re-enters context
▼
SeriesStore ── path-sandboxed CSV loader (TIMESERIES_MCP_DATA_ROOT)
│
▼
analysis/ — pure, deterministic, unit-tested routines
anomalies · changepoints · decompose · stationarity
correlation · trend · quality · baselines
(numpy / scipy / statsmodels underneath)Tool logic is transport-agnostic and per-session state is a single registry object — aligned with where the MCP spec is heading (stateless Streamable HTTP core in the 2026-07-28 revision).
No code execution. No eval, no exec, no model-written scripts.
Filesystem sandbox. load_csv resolves paths against TIMESERIES_MCP_DATA_ROOT (default: the server's working directory) and refuses traversal outside it — tested, including absolute-path escapes.
No network access. The server reads local CSVs and inline arrays only; no URL fetching, no SSRF surface.
Bounded everything. Row caps on ingestion, point caps on every response, series-count caps on the registry.
Self-correcting errors. Invalid inputs return actionable tool errors (Unknown series_id 'ts9'. Known ids: ts1, ts2.) so agents recover instead of hallucinating.
uv run pytest # 57 tests, ~2sGolden statistical tests — injected spikes are found, known slopes are recovered within tolerance, random walks fail stationarity, seasonal-naive beats naive on seasonal data.
Behavioral contrasts — a value that is globally unremarkable but wrong for its phase of the daily cycle is caught by stl_residual and correctly not caught by global z-score.
Protocol tests — the full workflow runs over the real MCP transport in memory; every tool is asserted to publish an outputSchema; error paths surface as MCP tool errors, not crashes.
Changepoint detection assumes shifts-plus-noise; on strongly seasonal or trending series, decompose or resample first (the sample demo shows this workflow).
Forecasts are reference baselines, deliberately. If your ARIMA can't beat seasonal_naive's backtest here, it's not adding value.
The series registry is in-process memory: restart = clean slate, and horizontal HTTP scaling would need a shared store (roadmap).
No multivariate methods yet beyond pairwise comparison.
mcp-server-data-exploration and pandas-mcp-server take the code-execution route — maximum flexibility, minimum auditability. Vendor servers like InfluxDB MCP front their own databases. This server is the deterministic, self-contained middle: bring a CSV, get defensible statistics.
An agent-facing evaluation suite for this server — scoring whether agents pick the right tools with the right arguments — lives at mcp-trajectory-evals.
Built with AI assistance (Claude Code) for scaffolding and test generation; statistical method selection, API design, parameter defaults, and final review are mine. Notable choices I'd defend in review: MAD-of-differences noise estimation for CUSUM (a global σ is inflated by the shifts being detected), reading ADF and KPSS jointly rather than either alone, and refusing to ship forecasts without a holdout backtest.
MIT © Lkhanaajav Mijiddorj
ACF/PACF with significance bounds; suggests a seasonal period when one stands out.
| Name | Required | Description | Default |
|---|---|---|---|
| nlags | No | Defaults to min(40, n/2 - 1). | |
| series_id | Yes |
| Name | Required | Description |
|---|---|---|
| acf | Yes | |
| pacf | Yes | |
| nlags | Yes | |
| series_id | Yes | |
| confidence_bound | Yes | ±1.96/sqrt(n) significance band for the ACF. |
| significant_lags | Yes | Lags (>=1) where |ACF| exceeds the band. |
| suggested_period | Yes | First strong non-trivial ACF peak, if any. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should disclose behavioral traits. It only mentions suggesting seasonal periods but doesn't describe mutability, computational assumptions, or output nature beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two clauses, no redundancy. It front-loads key info but could be slightly more informative without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description doesn't need to detail returns. However, for a time series analysis tool among many siblings, more usage context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (nlags described, series_id not). The description adds no further parameter details, so it fails to compensate for missing info in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it computes ACF/PACF with significance bounds and suggests a seasonal period. It uses specific verbs and resources, distinguishing from sibling tools like stationarity or decompose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 siblings (e.g., decompose, detect_seasonality). The description lacks context for when autocorrelation analysis is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Correlate two series on shared timestamps and find the lag of strongest coupling.
| Name | Required | Description | Default |
|---|---|---|---|
| max_lag | No | Max lead/lag (in steps) to scan. | |
| series_a | Yes | ||
| series_b | Yes |
| Name | Required | Description |
|---|---|---|
| pearson | Yes | A single statistical test outcome. |
| best_lag | Yes | Lag (in steps, b relative to a) maximizing |cross-correlation|. |
| series_a | Yes | |
| series_b | Yes | |
| spearman | Yes | A single statistical test outcome. |
| n_overlap | Yes | |
| interpretation | Yes | |
| ccf_at_best_lag | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior fully. It states the action but omits key traits: whether the operation is read-only (likely), how missing timestamps are handled, computational complexity, or side effects. The existence of an output schema helps but is not referenced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with no fluff. However, it may be overly terse given the tool's complexity. Front-loading the purpose is good, but additional structure (e.g., bullet points) could improve readability without much length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks context on how timestamps are shared, what happens with missing data, or how max_lag influences results. It does not differentiate from siblings like 'autocorrelation' or 'trend_test'. Incomplete for a correlation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (33%: only max_lag described in schema). The description adds no parameter information for series_a, series_b, or max_lag. It fails to clarify that series_a and series_b are identifiers for time series data, leaving the agent guessing their format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool correlates two series on shared timestamps and finds the lag of strongest coupling. It uses specific verbs ('correlate', 'find') and resources ('two series', 'lag') and distinguishes itself from siblings like 'autocorrelation' (single series) and 'detect_anomalies' (different purpose).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. With many sibling tools (e.g., autocorrelation, load_csv), the description should indicate scenarios like comparing two related time series to find time shifts, but it does not. No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Audit sampling gaps, duplicate timestamps, missing values, and regularity.
| Name | Required | Description | Default |
|---|---|---|---|
| series_id | Yes |
| Name | Required | Description |
|---|---|---|
| gaps | Yes | Largest gaps first, capped at 20. |
| verdict | Yes | One-line plain-language assessment. |
| n_points | Yes | |
| series_id | Yes | |
| is_monotonic | Yes | Whether timestamps are strictly increasing. |
| n_gaps_total | Yes | |
| missing_values | Yes | |
| duplicate_timestamps | Yes | |
| median_interval_seconds | Yes | |
| sampling_regularity_pct | Yes | Percent of intervals within 10% of the median interval. Null for n < 3. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as whether the tool modifies data, requires specific data formats, or handles errors. Only lists checks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence listing the checks; concise but somewhat telegraphic. Could be rephrased for better readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description might suffice for basic use, but it lacks context on prerequisites, limitations, or interpretation of results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (series_id) with 0% schema description coverage. The description provides no details about the parameter's format, allowed values, or meaning beyond its name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description lists specific checks (sampling gaps, duplicate timestamps, missing values, regularity), making the purpose fairly clear. However, the verb 'audit' is vague, and it doesn't explicitly differentiate from sibling tools like detect_anomalies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 detect_anomalies or describe. No when-not-to-use or context clues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Split the series into trend/seasonal/residual and quantify each component's strength.
| 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 |
| 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)). |
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.
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.
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.
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.
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.
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.
Distributional summary: quartiles, spread, skewness, kurtosis, missing count.
| Name | Required | Description | Default |
|---|---|---|---|
| series_id | Yes |
| Name | Required | Description |
|---|---|---|
| stats | Yes | Five-number-style summary of the values in a series. |
| kurtosis | Yes | Excess kurtosis (normal distribution = 0). |
| skewness | Yes | |
| series_id | Yes | |
| inferred_freq | Yes | |
| last_timestamp | Yes | |
| first_timestamp | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It lists the statistics returned, providing basic transparency, but does not mention error handling, permissions, or side effects. The output schema exists but is not referenced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, efficient and to the point. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so return value details are covered, but the lack of parameter explanation, usage context, and error handling leaves the description incomplete for a tool with only one parameter and no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not mention the single parameter 'series_id'. It adds no meaning beyond the schema's type and required status.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides a distributional summary listing specific statistics (quartiles, spread, skewness, kurtosis, missing count). It distinguishes from sibling tools like data_quality or detect_anomalies, but could be more explicit about the verb (e.g., 'Calculates and returns').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. The description only states what it does without specifying prerequisites, context, or when it is preferred over other statistical tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Flag anomalous observations; returns scored anomalies, strongest first.
| Name | Required | Description | Default |
|---|---|---|---|
| method | No | zscore/mad/iqr are global; stl_residual is seasonal-aware (needs period). | zscore |
| period | No | Seasonal period, required for stl_residual. | |
| series_id | Yes | ||
| threshold | No | Score cutoff (zscore/mad/stl) or IQR fence multiplier (iqr). |
| Name | Required | Description |
|---|---|---|
| notes | Yes | |
| method | Yes | |
| anomalies | Yes | Highest scores first, capped at 50. |
| series_id | Yes | |
| threshold | Yes | |
| n_anomalies | Yes | |
| baseline_std | Yes | |
| baseline_mean | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states the output structure (scored, sorted) but does not mention data requirements (e.g., numeric series, missing value handling) or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys purpose and output format with no redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, output schema exists), the description plus schema cover the core functionality. Minor omission: no mention that input must be numeric, but this is implied by anomaly detection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75% and already provides detailed parameter descriptions (method enum, period condition, threshold meaning). The main description adds no new parameter information beyond what schema offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool flags anomalous observations and returns scored anomalies sorted by strength, which distinguishes it from siblings like detect_changepoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The main description lacks explicit guidance on when to use this tool vs alternatives. The schema mentions method-specific distinctions (global vs seasonal-aware), but no systematic when-to-use criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect level shifts (mean changes) via CUSUM binary segmentation.
| Name | Required | Description | Default |
|---|---|---|---|
| series_id | Yes | ||
| threshold | No | CUSUM significance bound; 1.36 ~ 95%. | |
| max_changepoints | No | ||
| min_segment_length | No | Minimum points between changepoints. |
| Name | Required | Description |
|---|---|---|
| notes | Yes | |
| method | Yes | |
| series_id | Yes | |
| threshold | Yes | |
| changepoints | Yes | |
| n_changepoints | Yes | |
| min_segment_length | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the purpose but does not disclose side effects, read-only nature, or dependencies. The minimal behavioral info is the CUSUM method, but deeper context (e.g., output format, data requirements) is absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence stating purpose and method. It is concise, but at the cost of omitting valuable context like usage guidance. Each word earns its place, but a second sentence could improve completeness without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 params, specific statistical method, output schema exists), the description is too sparse. It does not explain data requirements (numeric series, any length constraints) or output expectations. The output schema mitigates return-value docs, but more context is needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (threshold and min_segment_length have descriptions). The tool description adds no parameter information beyond the schema, leaving series_id and max_changepoints fully undocumented. The description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool detects level shifts (mean changes) using a specific method (CUSUM binary segmentation). It distinguishes from siblings like detect_anomalies (outliers) and stationarity (trend tests).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines provided. The description does not mention when to use this tool versus alternatives like trend_test or detect_anomalies, nor does it specify prerequisites (e.g., numerical series).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Baseline forecast with 95% intervals and an honest holdout backtest.
| Name | Required | Description | Default |
|---|---|---|---|
| method | No | Reference methods per Hyndman FPP3; every result includes a holdout backtest. | naive |
| period | No | Seasonal period, required for seasonal_naive. | |
| horizon | No | Steps ahead to forecast. | |
| series_id | Yes |
| Name | Required | Description |
|---|---|---|
| notes | Yes | |
| method | Yes | |
| horizon | Yes | |
| backtest | Yes | Holdout accuracy of the chosen baseline method. |
| forecasts | Yes | |
| series_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions intervals and backtest but does not disclose whether the tool is read-only, modifies data, requires permissions, or has side effects. A baseline forecast is likely non-destructive but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key information, no unnecessary words. Every part is essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, good schema coverage, and presence of output schema, the description is adequate but not complete. It lacks usage guidance and behavioral details that would help an agent decide when to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75% (3 of 4 params described). The description does not add meaning beyond the schema; it only repeats 'baseline' and 'intervals' which are not parameter-specific. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it's a baseline forecast tool with 95% intervals and holdout backtest. The verb 'forecast' and resource 'baseline' are specific, and it distinguishes from sibling tools like detect_anomalies or decompose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. Does not mention when not to use or compare to other forecasting methods. The description only states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch raw observations in a time window (evenly thinned if over the limit).
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | ISO-8601 window end (inclusive). | |
| limit | No | Max points to return. | |
| start | No | ISO-8601 window start (inclusive). | |
| series_id | Yes |
| Name | Required | Description |
|---|---|---|
| points | Yes | |
| returned | Yes | |
| series_id | Yes | |
| truncated | Yes | |
| n_in_window | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden. It reveals the even thinning mechanism, which is a key behavioral trait. However, it omits details like handling of null start/end or empty windows.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 15 words, no filler. Front-loaded with the primary action. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of output schema and decent parameter schema, the description is sufficient for a fetch-like tool. It covers the key behavior (thinning) and purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, so the schema already documents most parameters. The description adds no extra parameter information, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'fetch' and resource 'raw observations' within a 'time window', with a specific behavior 'evenly thinned if over the limit'. This distinguishes it from siblings like 'resample' or 'load_sample'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs. alternatives like 'load_values' or 'resample'. The thinning behavior is noted but not contrasted with other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every series currently loaded, with basic stats.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| series | Yes | |
| n_series | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It correctly indicates a read-only listing operation, but does not elaborate on what 'basic stats' entails or any constraints like permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that front-loads the purpose with no extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists (though not shown), the description is mostly complete. However, it omits details on what 'basic stats' refers to, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description naturally cannot add parameter info. The baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists every loaded series with basic stats, using a specific verb-resource combination. It distinguishes from sibling tools like load_csv or load_values, which are for loading not listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need to see loaded series), but provides no explicit guidance on when to use vs alternatives, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load one column of a CSV as a time series and register it under a series_id.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | CSV path inside the data root (see TIMESERIES_MCP_DATA_ROOT). | |
| value_column | No | Numeric value column; first numeric column if omitted. | |
| timestamp_column | No | Timestamp column; auto-detected if omitted. |
| Name | Required | Description |
|---|---|---|
| end | Yes | ISO-8601 timestamp of the last observation. |
| name | Yes | |
| start | Yes | ISO-8601 timestamp of the first observation. |
| stats | Yes | Five-number-style summary of the values in a series. |
| source | Yes | Where the series came from: csv path, inline, sample, or a derivation. |
| n_points | Yes | |
| series_id | Yes | |
| inferred_freq | Yes | Pandas frequency string inferred from the index, e.g. '5min'; null if irregular. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It mentions registration under a series_id but omits details like overwrite behavior, required CSV format, or side effects of registration. The output schema may compensate somewhat, but the description leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is concise, front-loaded, and contains no filler. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core action and key parameters, and the output schema exists to explain return values. However, with many sibling tools, a brief note on when to use this tool versus others would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds little beyond what the schema already provides. The overall purpose is reinforced, but no additional parameter-level guidance or constraints are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and outcome: 'Load one column of a CSV as a time series and register it under a series_id.' It clearly distinguishes from siblings like 'load_values' and 'load_sample' by specifying the data source and registration step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for loading CSV data into a time series, but does not explicitly state when to prefer this tool over alternatives or provide exclusions. With many sibling tools, some comparative guidance would improve this score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load a bundled synthetic sample (seeded, reproducible) — useful for demos and evals.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Which bundled deterministic sample dataset to load. |
| Name | Required | Description |
|---|---|---|
| end | Yes | ISO-8601 timestamp of the last observation. |
| name | Yes | |
| start | Yes | ISO-8601 timestamp of the first observation. |
| stats | Yes | Five-number-style summary of the values in a series. |
| source | Yes | Where the series came from: csv path, inline, sample, or a derivation. |
| n_points | Yes | |
| series_id | Yes | |
| inferred_freq | Yes | Pandas frequency string inferred from the index, e.g. '5min'; null if irregular. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the data is seeded and reproducible, which is key behavioral info. No mention of side effects, but for a read-like load operation, that is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately conveys the action and purpose. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema exists), the description is fully adequate: it states purpose, usage context, and key behavioral property.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with enum options clearly documented. The description adds no further meaning beyond the schema, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Load' and the resource 'bundled synthetic sample', and specifies it is seeded and reproducible for demos and evals. This distinctly differentiates it from sibling tools like load_csv (external data) and load_values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states it is useful for demos and evals, implying it is for synthetic, reproducible scenarios. It does not explicitly exclude other uses or mention alternatives, but the context is clear enough for appropriate selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register a series from inline values (small data; prefer load_csv for files).
| Name | Required | Description | Default |
|---|---|---|---|
| freq | No | If no timestamps: pandas frequency (default '1min'). | |
| name | No | Human-readable label for the series. | inline |
| start | No | If no timestamps: start time for a regular grid. | |
| values | Yes | The observations, in time order. | |
| timestamps | No | ISO-8601 timestamps matching `values`. |
| Name | Required | Description |
|---|---|---|
| end | Yes | ISO-8601 timestamp of the last observation. |
| name | Yes | |
| start | Yes | ISO-8601 timestamp of the first observation. |
| stats | Yes | Five-number-style summary of the values in a series. |
| source | Yes | Where the series came from: csv path, inline, sample, or a derivation. |
| n_points | Yes | |
| series_id | Yes | |
| inferred_freq | Yes | Pandas frequency string inferred from the index, e.g. '5min'; null if irregular. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'Register' which implies a write operation, but gives no details on side effects, permissions, or limits beyond the schema's maxItems. More behavioral context is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with a parenthetical hint. Every word adds value, and the core purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters with complex interplay (timestamps vs. freq/start), but the description does not explain these relationships. While the output schema exists, the description lacks guidance on how parameters interact for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains each parameter. The description adds no additional parameter meaning beyond the static text. Per guidelines, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the clear verb 'Register' with the resource 'a series from inline values'. It explicitly differentiates from the sibling load_csv by noting preference for files, making the tool's role distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides direct guidance: 'prefer load_csv for files' implies this tool is for inline small data. It does not address other siblings like load_sample, but the main alternative is covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resample onto a regular grid; registers and returns a NEW derived series.
| Name | Required | Description | Default |
|---|---|---|---|
| agg | No | Aggregation. | mean |
| rule | Yes | Pandas offset alias, e.g. '5min', '1h', '1D'. | |
| series_id | Yes |
| Name | Required | Description |
|---|---|---|
| end | Yes | ISO-8601 timestamp of the last observation. |
| name | Yes | |
| start | Yes | ISO-8601 timestamp of the first observation. |
| stats | Yes | Five-number-style summary of the values in a series. |
| source | Yes | Where the series came from: csv path, inline, sample, or a derivation. |
| n_points | Yes | |
| series_id | Yes | |
| inferred_freq | Yes | Pandas frequency string inferred from the index, e.g. '5min'; null if irregular. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states the tool registers and returns a new derived series (non-destructive), but does not elaborate on permission needs, missing data handling, or side effects. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence. It front-loads the primary action. However, the term 'registers' is slightly vague and could be clarified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool resamples time series, more context is needed: what the output contains (e.g., timestamps, values), how missing data is handled, and the effect of the 'agg' parameter. The presence of an output schema helps but is not visible here. The description is incomplete for a 3-param tool with 2 required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (agg and rule have descriptions in schema). The tool description adds no additional meaning beyond the schema. The series_id param lacks contextual explanation. The description does not compensate for the 33% uncovered param.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'resample' and the resource 'series onto a regular grid', with the added distinction that it 'returns a NEW derived series', which differentiates it from modifying tools. Sibling tools like load_csv, describe, etc. are distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use resample vs alternatives (e.g., rolling_stats, get_window). It does not mention prerequisites, when not to use, or preferred scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rolling-window statistics with an evenly spaced preview per stat.
| Name | Required | Description | Default |
|---|---|---|---|
| stats | No | Which rolling statistics to compute. | |
| window | Yes | Window size in observations. | |
| series_id | Yes |
| Name | Required | Description |
|---|---|---|
| stats | Yes | |
| window | Yes | |
| series_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must carry behavioral transparency. It mentions 'evenly spaced preview' but doesn't explain what that entails (number of points, how spacing works). No disclosure of performance implications or idempotency. Adds some value but insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the core action. No redundant words or filler. Efficient and direct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values need not be detailed. However, the description lacks context on usage within the suite of sibling tools (many time-series operations). The 'evenly spaced preview' concept is undefined, and required parameter 'series_id' is unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (series_id lacks description). The description adds no parameter-level details beyond what the schema already provides. For the undocumented series_id, the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it computes rolling-window statistics with a preview, distinguishing it from siblings like 'get_window' (single window) or 'describe' (summary stats). The verb 'rolling-window statistics' and resource 'per stat' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., 'get_window', 'describe', 'data_quality'). No explicit when/when-not or mention of prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run ADF and KPSS together and give a combined stationarity verdict.
| Name | Required | Description | Default |
|---|---|---|---|
| series_id | Yes |
| Name | Required | Description |
|---|---|---|
| adf | Yes | A single statistical test outcome. |
| kpss | Yes | A single statistical test outcome. |
| verdict | Yes | Combined reading of both tests. |
| series_id | Yes | |
| differencing_hint | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions the tests but does not explain what the verdict looks like, side effects, or interpretation. The existence of an output schema is noted but not detailed in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, front-loading the core purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of combining two statistical tests and the presence of many sibling tools, the description lacks context about stationarity, test names, and verdict interpretation. An agent needs more information to decide appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning to the single parameter 'series_id' beyond the schema. Schema coverage is 0% and the parameter is just a string without clarification of valid values or source.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs ADF and KPSS tests together and provides a combined stationarity verdict, using a specific verb ('run') and resource ('stationarity test'). It distinguishes from sibling tools like trend_test or autocorrelation by specifying the tests used.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 trend_test or decompose. There is no mention of prerequisites or context for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate trend three ways: OLS, robust Theil-Sen, and the Mann-Kendall test.
| Name | Required | Description | Default |
|---|---|---|---|
| series_id | Yes |
| Name | Required | Description |
|---|---|---|
| direction | Yes | 'increasing', 'decreasing', or 'no significant trend'. |
| series_id | Yes | |
| mann_kendall | Yes | A single statistical test outcome. |
| ols_r_squared | Yes | |
| change_over_span | Yes | Theil-Sen slope × (n-1): total modeled change. |
| theil_sen_ci_low | Yes | |
| theil_sen_ci_high | Yes | |
| ols_slope_per_step | Yes | |
| theil_sen_slope_per_step | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description alone must convey behavioral traits. It only states the action (estimate three ways) without disclosing whether the operation is read-only, what the output format is, or any side effects. The existence of an output schema is not mentioned, and the description lacks depth beyond the core action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff. However, it is so brief that it sacrifices valuable information for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (three estimation methods) and the lack of annotations or parameter descriptions, the description is severely incomplete. It omits how to select a method, what the output contains, and any prerequisites. The agent cannot fully understand how to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the single parameter 'series_id' beyond its name. The description adds no meaning to the parameter, leaving the agent to guess its purpose or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'estimate' and the resource 'trend', specifying exactly three methods (OLS, Theil-Sen, Mann-Kendall). This distinguishes it from sibling tools like detect_anomalies or decompose, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, no prerequisites, and no conditions for choosing among the three methods. This leaves the agent without context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0autocorrelationcompare_seriesdata_qualitydecomposedescribedetect_anomaliesdetect_changepointsforecast_baselineget_windowlist_seriesload_csvload_sampleload_valuesresamplerolling_statsstationaritytrend_testScored across 17 tools
Each tool has a clearly distinct purpose: loading (three variants), listing, statistics, transformations, anomaly detection, decomposition, quality, comparison, and forecasting. There is no ambiguity; an agent can easily select the correct tool.
Most tools follow a verb_noun or descriptive verb pattern (e.g., load_csv, detect_anomalies, forecast_baseline). A few are single verbs (decompose, resample) or noun phrases (data_quality, stationarity), but the pattern is largely consistent and readable.
With 17 tools, the server covers a full range of time series operations—loading, inspection, transformation, analysis, anomaly detection, and forecasting—without being overwhelming. Each tool earns its place.
The toolset covers core lifecycle operations: loading, listing, description, resampling, rolling stats, quality checks, anomaly and changepoint detection, decomposition, stationarity, autocorrelation, trend tests, comparison, and baseline forecasting. Minor gaps (e.g., no differencing, no series deletion/export) are acceptable for analysis-focused servers.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for building and testing AI agents with multi-model experimentation and insights.
Analytics for MCP servers. Find out which of your tools agents get wrong. MCPulse shows you which tools AI agents retry, which come back empty, and which they never call at all. Two lines inside your own server. It never sees your arguments or your results. getmcpulse.com
Hosted MCP server for live public-data APIs and Skills for AI agents.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
