Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
This server has severe definition quality issues across all 32 tools. While tool names follow a reasonable verb_noun pattern (e.g., 'basic_parametric_estimation_ols', 'causal_difference_in_differences'), the vast majority lack visible input schemas and comprehensive parameter documentation. Most tool definitions are inferred from registration entries rather than directly visible in source code. Only 2 tools (time_series_var_svar_model, time_series_cointegration_analysis) show explicit input schemas in the provided source. Descriptions are universally generic and under-informative (typically 20-60 chars), providing almost no guidance on WHEN to use each tool, what preconditions apply, or what the output structure looks like. No tools show output schema documentation. No error handling patterns are evident. The server registers 32 tools but provides minimal evidence of schema definition, parameter validation guidance, or output structuring.
30 of 32 tools (94%) have NO visible input schema in source code. This makes the tools inaccessible to agents, they cannot determine valid parameter names, types, or constraints.
For ALL 32 tools: Make the _registrations.py file visible in source or provide an excerpt showing the full FastMCP tool registration with input schema. Currently, only tool names and names descriptions are shown; the actual parameter schemas are hidden.
For ALL 32 tools: Expand descriptions to 60-150 characters. Answer: (1) What does this statistical method do? (2) When would an econometrician use it? (3) What data format does it expect? Example: 'OLS Regression Analysis, Estimate linear relationships between a dependent variable and one or more predictors. Use for hypothesis testing when errors are assumed normal and homoscedastic. Accepts 2D arrays or CSV files with numeric columns.'
For ALL 32 tools: Document input schemas explicitly. Include parameter names, types (string, number, array, object), required/optional flags, enums (if applicable), and min/max constraints. Example for a lag parameter: 'lags (integer, required, 1 - 12), Number of past time periods to include in the model.'
For ALL 32 tools: Document output schemas. Describe the result structure, field names, and types. Example: '{coefficients: {[string]: number}, r_squared: number, p_values: {[string]: number}, residuals: number[]}'
For tools accepting file paths (implicit in many): Document accepted file formats (CSV, JSON, XLSX, XLS, TXT), expected column names or structure, and encoding.
Implement error handling with actionable messages. Example: Instead of 'Failed to estimate OLS', return: 'OLS estimation failed: Singular matrix (X'X not invertible). Check for multicollinearity or missing values in columns: col_1, col_5. Try dropping one correlated predictor.'
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
All 32 tool descriptions are critically short (15-45 chars) and generic. They state WHAT but not WHEN to use them or any preconditions. E.g., 'OLS Regression Analysis' tells an agent nothing about prerequisites (data shape, assumptions) or how this differs from GMM/MLE. Descriptions should be 50-200 chars and answer 'What? When? Why choose this over alternatives?'
No output schemas are documented anywhere in the provided source. Agents cannot know what fields to expect, what data types are returned, or how to extract results for downstream tool calls. This violates the pattern:tool-chain and makes composition impossible.
30 tools have no visible parameter descriptions. The two tools that do (time_series_var_svar_model, time_series_cointegration_analysis) show only basic type info without guidance on constraints, ranges, or why each parameter exists.
No error handling or recovery guidance is visible. Tools provide no error categorization (retryable vs. user-fixable vs. fatal), no recovery suggestions, and no validation error messages. Per pattern:recovery-guide, errors must tell the LLM what to do next.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present. While most tools are READ_ONLY (safe), agents have no explicit guidance. Per pattern:command-tool and current spec alignment, destructive or high-risk operations should be annotated.
Add tool annotations via FastMCP. Mark read-only tools with `@mcp.tool(..., metadata={'readOnlyHint': true})`. If any tools write to disk or modify state, mark with `destructiveHint: true` and support dry-run.
Create a per-tool parameter guidance resource. Rather than embedding all parameter details in descriptions, publish a `guide://tools/<tool-name>` resource with full schema, examples, and common errors. This avoids bloating descriptions while providing agents full detail.
For the two tools with visible schemas (time_series_var_svar_model, time_series_cointegration_analysis): Expand descriptions and add output schema documentation. These serve as templates for the remaining 30.
Add examples to descriptions. Instead of 'Type of model: var or svar', say 'Type of model: var for Vector Autoregression (forecast multiple series jointly) or svar for Structural VAR (identify causal shocks). Default: var.'
Document default values explicitly. Agents need to know what happens if they omit a parameter. Example: 'output_format (string, optional, default: json), json returns structured nested object; markdown returns human-readable tables with significance stars; text returns Pydantic repr.'
For statistical methods, add prerequisite checks in descriptions. Example: 'Requires: data must be stationary (run time_series_unit_root_tests first), no missing values, and minimum 20 observations per variable.'
Consider adding a discovery tool: `list_econometric_methods(category: string)` that returns available tools with brief descriptions and link to detailed guides. Agents can call this first to understand the tool landscape.