StatsPAI

feols

Read-only

Estimate OLS or IV models with high-dimensional fixed effects and cluster-robust standard errors using fixest/reghdfe-style formulas for econometric analysis.

Instructions

OLS with high-dimensional fixed effects (R fixest / Stata reghdfe syntax): 'y ~ x1 + x2 | unit + year'. IV as 'y ~ x | fe | d ~ z'. vcov: 'iid', 'hetero', or {'CRV1': 'cluster_col'} (two-way: 'a + b'). Validation: certified parity evidence.

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": {
      "fml": "<fml>"
    },
    "name": "feols"
  }
}

Input Schema

Name	Required	Description	Default
`fml`	Yes	fixest formula, e.g. 'y ~ x \| unit + year'
`vcov`	No	'iid', 'hetero' or {'CRV1': 'col'}
`detail`	No	Payload depth; agent is the fullest.	agent
`cluster`	No	Cluster column (same as {'CRV1': col}).
`data_id`	No	Data handle (d_...) from load_data; replaces data_path.
`weights`	No	Weight column.
`data_csv`	No	Small inline table as CSV text.
`as_handle`	No	Cache the fit and return its result_id.
`data_path`	No	Absolute path of a data file on the server.
`result_id`	No	Handle of an earlier fit made with as_handle=true.
`data_records`	No	Small inline table as row objects.
`max_output_bytes`	No	Result byte budget (default 262144; 0 = none).

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 12, 2026

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already establish the safety profile (readOnlyHint=true, openWorldHint=false), so the description only needs to add operational context, which it partly does by specifying the accepted vcov forms including two-way clustering. It says nothing about failure modes (missing cluster column, singular design, unloaded data handle) or what 'certified parity evidence' actually guarantees. That final clause is a claim without content, so the added context stays thin.

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?

Dense but front-loaded: the estimator and the formula grammar come first, options second, with almost no filler words. The single weak sentence is 'Validation: certified parity evidence', which spends words without conveying anything actionable. Everything else earns its place.

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?

With twelve parameters, an output schema, and full schema coverage, the description does not need to re-document return values or data-source plumbing, and it correctly concentrates on the formula grammar that drives everything. What is missing is tool-selection context against the several overlapping IV/regression siblings and any indication of computational limits or error conditions. Adequate for calling the tool, incomplete for choosing it.

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 description coverage is 100%, so the schema already documents all twelve parameters and the baseline is 3. The description does add one thing the schema lacks: the two-way clustering syntax ('a + b'), which is genuinely useful for the vcov parameter. Otherwise it largely restates the schema's own formula and vcov examples, and the ten data-source/as_handle/max_output_bytes parameters get no mention at all.

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?

Names the estimator and its resource precisely ('OLS with high-dimensional fixed effects') and anchors it to two well-known syntaxes (R fixest / Stata reghdfe), which immediately tells an agent what class of tool this is. The embedded IV form ('y ~ x | fe | d ~ z') muddies the boundary with the sibling 'iv'/'ivreg' tools, since it implies IV estimation is also in scope here without saying how the two differ.

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?

The text is entirely about how to write the formula, not when to reach for this tool. There is no statement of when to use feols versus the sibling 'iv', 'ivreg', or 'pipeline_iv', and no prerequisites (e.g. that the data must first be loaded via load_data and referenced by data_id). The trailing 'Validation: certified parity evidence' does not function as usage guidance because it never explains what condition it implies.

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