Causal Decision Agent

by vikranthviki

Overview Schema Source Related Servers Discussions Admin

Python

Local

feglm

Read-only

Estimate GLMs (logit, probit, Gaussian) with high-dimensional fixed effects for causal analysis and decision support.

Instructions

Estimate GLM (logit, probit, Gaussian) with high-dimensional fixed effects. Validation: certified parity evidence.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`fml`	Yes	pyfixest formula.
`seed`	No	RNG seed for sampled (non-enumerated) ``vce="wild"`` draws.
`vcov`	No	Variance-covariance estimator (``vce=`` is the canonical alias). Also accepts ``vce="CR2"``/``"CR3"``/``"jackknife"`` (with ``cluster=``) for the clubSandwich bias-reduced cluster-robust SEs, and ``vce="wild"`` (with ``cluster=``) for the restricted score wild cluster bootstrap (Kline-Santos 2012; bit-exact vs Stata ``boottest`` in the enumerated regime).
`detail`	No	Payload depth: 'minimal' (~150 tokens) for sub-step calls where only the point estimate is needed; 'standard' (~1K tokens) for diagnostics + coefficient table; 'agent' (~2K tokens, default) adds violations / next_steps / suggested_functions so the LLM can plan its next call without another round-trip.	agent
`family`	No	GLM family: ``"gaussian"``, ``"logit"``, ``"probit"``.	gaussian
`cluster`	No	Cluster id column for the extended ``vce=`` menu (also a shorthand for one-way ``{"CRV1": cluster}``).
`as_handle`	No	If true, cache the fitted result on the server and return result_id + result_uri alongside the JSON payload so a subsequent tools/call can chain without re-running.
`data_path`	Yes	Absolute path or URL to a data file. Supported: .csv / .tsv / .txt (delimited), .parquet / .pq, .feather / .arrow, .xlsx / .xls, .dta (Stata), .json / .jsonl. Schemes: file://, s3://, gs://, https://.
`result_id`	No	Optional handle to a previously-fitted result (returned by an earlier call when as_handle=true). Tools that operate on a fitted object accept this in place of re-supplying data_path + columns.
`wild_reps`	No	Replications for ``vce="wild"``. When ``2**G <= wild_reps`` the full Rademacher grid is enumerated (deterministic).
`conley_lat`	No	conley_lat parameter (Optional[str]).
`conley_lon`	No	conley_lon parameter (Optional[str]).
`data_columns`	No	Optional column projection. Parquet/Feather/Stata loaders honour this for fast partial reads.
`conley_cutoff`	No	conley_cutoff parameter (Optional[float]).
`data_sample_n`	No	Optional uniform random subsample size (seed=0, deterministic) — useful on huge panels.
`wild_weight_type`	No	Wild weight distribution (``"rademacher"`` or ``"webb"``).	rademacher

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 15, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already provide readOnlyHint=true, establishing the safety profile. The description adds a modest quality claim ('certified parity evidence') but does not disclose operational traits such as computational intensity or the optional server-side caching enabled by as_handle. No contradiction with annotations.

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?

The description is just two sentences, with the core purpose front-loaded in the first sentence. The second sentence ('Validation: certified parity evidence.') is cryptic and low in actionable value, but it is brief and does not create bloat.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The rich input schema and presence of an output schema compensate for the brief description, making it adequate for basic invocation. However, the description does not orient the agent to advanced features like the extended vcov menu, wild cluster bootstrap, result chaining, or the meaning of the parity-validation note, which leaves some gaps for a high-complexity tool.

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

Parameters3/5

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

Schema coverage is 100% and all 16 parameters have thorough descriptions in the input schema, so the baseline applies. The description does not add parameter-specific meaning, but it is not required to given the complete schema documentation.

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 names a specific verb ('Estimate'), a precise resource (GLM with high-dimensional fixed effects), and enumerates the supported families (logit, probit, Gaussian). This clearly differentiates it from siblings like feols, fepois, and plain glm/logit/probit without needing to name them.

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

Usage Guidelines3/5

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

The intended use is implied by the name and description (GLM with HDFE), but there is no explicit when-to-use guidance, no prerequisites, and no mention of when to prefer this over closely related siblings like feols, fepois, or meglm. An agent must infer the selection criteria.

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

Deploy Server