Causal Decision Agent

Overview Schema Source Related Servers Discussions Admin

pate

Read-only

Estimate the population average treatment effect by weighting experimental data to match target population covariates, with confidence intervals and validated evidence.

Instructions

Estimate the Population Average Treatment Effect (PATE). Validation: validated evidence tier (known-truth, reference, external-parity, or Monte Carlo artifact).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`y`	Yes	Outcome variable (only used from data_experiment).
`seed`	No	Random seed for reproducibility.
`trim`	No	Trimming threshold for participation propensities (values below trim or above 1 - trim are clipped).
`alpha`	No	Significance level for the confidence interval.
`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
`method`	No	Estimation strategy: * ``'ipw'`` -- Inverse probability of sampling weights. * ``'aipw'`` -- Augmented IPW (doubly robust). * ``'calibration'`` -- Entropy balancing on covariate moments.	ipw
`n_boot`	No	Number of bootstrap replications for standard-error estimation.
`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`	No	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.
`treatment`	Yes	Binary treatment indicator (only in data_experiment).
`covariates`	Yes	Shared covariates present in both datasets.
`data_target`	Yes	Target population sample. Must contain all covariates. Need not contain y or treatment.
`data_columns`	No	Optional column projection. Parquet/Feather/Stata loaders honour this for fast partial reads.
`data_sample_n`	No	Optional uniform random subsample size (seed=0, deterministic) — useful on huge panels.
`data_experiment`	Yes	Experimental/study sample. Must contain y, treatment, and all covariates.

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

B3.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds a vague note about 'validated evidence tier' without explaining what it means for the agent (e.g., trustworthiness, output semantics), providing little behavioral insight beyond the annotation.

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 very short (two sentences) and front-loaded with the core purpose. The second sentence about validation is cryptic but not verbose; overall it is concise but the second sentence could be clarified.

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

Completeness2/5

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

For a 16-parameter tool with both an experimental and target dataset, the description is incomplete. It fails to mention the key inputs (covariates, treatment, outcome, datasets) or the role of the 'data_target' sample, leaving the agent to rely entirely on schema descriptions. The output schema exists but the tool's specific logic is not summarized.

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%, so all 16 parameters already have descriptions in the schema. The description adds no parameter-level meaning, which is acceptable given the baseline of 3.

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?

The description states a clear verb ('Estimate') and a specific resource ('Population Average Treatment Effect (PATE)'), which distinguishes it from generic ATE tools. However, it does not differentiate from similarly named siblings like 'average_treatment_effect' or 'doubly_robust', so an agent may struggle to pick between them.

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?

No guidance is provided on when to use PATE versus alternative estimators (e.g., average_treatment_effect, aipw, ipw). The description lacks any mention of the two-dataset requirement (data_experiment/data_target) or when this estimand is appropriate. The 'Validation' sentence is unrelated to usage.

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

Deploy Server