Skip to main content
Glama
davidesg

ART MCP Server

by davidesg

confirm_and_estimate

Confirm the model specification, generate the .inp, estimate parameters, and receive an immediate diagnosis including significance tests, residual plots, and histogram.

Instructions

Build the .inp for the confirmed spec, estimate and show diagnosis immediately.

Two modes:

  • Fresh model (base_pre_path=""): constructs from scratch using series in inp_path and the analyst-confirmed (lam, d, D, p, q, P, Q) spec.

  • Incremental (base_pre_path=<.pre>): loads all existing interventions and harmonics from the .pre, then replaces/adds only the ARMA part (p, q, P, Q) and mu. Use this to add ARMA to a model after the outlier cycle.

Always returns:

  • Parameter table with SE and t-stats

  • Diagnosis verdict (Q-test, JB, outliers)

  • Residual ACF/PACF + histogram

Parameters

inp_path : source .inp/.pre (series data and name; spec ignored unless base_pre_path is given) output_path : path to write the new .inp lam : Box-Cox lambda (0.0=log, 1.0=identity) d : regular differencing order D : seasonal differencing order (0=B1 harmonics, 1=B2 multiplicative) p : regular AR order q : regular MA order n_harmonics : harmonic pairs cos/sin (D=0 fresh only; ignored when base_pre_path is given — harmonics come from the .pre) seasonal : on/off switch for the whole deterministic seasonal package (cos/sin pairs + Nyquist alter). None (default) => derive from n_harmonics>0, correct for freq>=4. Pass False for a NON-seasonal series (no seasonal terms at all — avoids the spurious Nyquist of BUG-0005). Pass True for a SEMI-ANNUAL seasonal series (freq=2), whose only seasonal term is the Nyquist alter while n_harmonics (pairs) is 0. P : seasonal AR order (D=1 only) Q : seasonal MA order (D=1 only) base_pre_path : if given, load interventions+harmonics from this .pre and add only the ARMA spec. Typical use: final ARMA step after outlier cycle in B1 flow. estimate_mu : include mean parameter μ in estimation (default False). Set True when μ̄/SE > 2 in the residuals of the clean model. include_histogram : return histogram PNG as third item (default False). Keep False during the outlier cycle to save tokens; set True for the final model only. guion_path : (optional) path to guion.json — records this version guion_name : version name (e.g. "PC3"); auto-assigned if empty guion_decision : brief description of what this model tests or concludes guion_rationale : justification for the choices made guion_problems : problems found in the diagnosis of this model guion_next : description of the next version to try

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
DNo
PNo
QNo
dNo
pNo
qNo
lamNo
inp_pathYes
seasonalNo
guion_nameNo
guion_nextNo
guion_pathNo
estimate_muNo
n_harmonicsNo
output_pathYes
base_pre_pathNo
guion_decisionNo
guion_problemsNo
guion_rationaleNo
include_histogramNo
Behavior5/5

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

The description discloses return values in detail ('Always returns' list), side effects of incremental mode (loads interventions/harmonics from .pre, replaces only ARMA part), and even warns about a known bug (BUG-0005 spurious Nyquist) with workaround for seasonal parameters. No annotations were present, so the description carries the full burden and does so thoroughly.

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 front-loaded with the core action, followed by a structured breakdown of modes, returns, and parameter details. Though long, it is necessary given 20 parameters, and each sentence adds operational value. The use of headings and bolded parameter names improves scannability.

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 the tool has 20 parameters, no output schema, and no annotations, the description provides comprehensive context: what it builds, how the two modes differ, what is returned, and detailed parameter semantics including bug workarounds. It is more than sufficient for an agent to correctly select and invoke this tool.

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?

With schema_description_coverage at 0%, the description compensates fully. Every parameter is explained with its meaning, default, and special cases (e.g., 'lam: Box-Cox lambda (0.0=log, 1.0=identity)', 'seasonal: None (default) => derive from n_harmonics>0', 'base_pre_path: if given, load interventions+harmonics...'). This provides value far beyond the 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?

The description opens with a specific action: 'Build the .inp for the confirmed spec, estimate and show diagnosis immediately.' It clearly distinguishes from siblings by explaining two modes (fresh vs incremental) and referencing the typical use case 'final ARMA step after outlier cycle'. The scope is well-defined.

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

Usage Guidelines5/5

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

Explicit usage guidance is provided: it describes when to use each mode (base_pre_path empty vs provided), states 'Use this to add ARMA to a model after the outlier cycle', and advises on include_histogram ('Keep False during the outlier cycle... set True for the final model only'). It also explains when to set estimate_mu based on statistical evidence.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/davidesg/art-python'

If you have feedback or need assistance with the MCP directory API, please join our Discord server