Skip to main content
Glama
vikranthviki

Causal Decision Agent

by vikranthviki

pretrends_power

Read-only

Compute the power of pre-trend tests against a hypothesized violation, showing how likely the test detects a given trend. Use to assess the credibility of parallel-trends evidence.

Instructions

Power of the pre-trend test against a hypothesised violation. Validation: certified parity evidence.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
testNoWhich pre-test the power refers to. ``"individual"`` is the practice Roth (2022) analyses and the one his ``pretrends`` R package implements: the analyst eyeballs the event-study plot and calls the pre-trends into question if *any* pre-period coefficient is individually significant. Power is then one minus the probability that every pre-period coefficient falls inside its own ``+/- z_{1-alpha/2} * SE`` band, integrated over the joint normal with mean ``delta`` -- a multivariate-normal rectangle probability. ``"joint"`` is the power of the joint Wald test that all pre-period coefficients are zero, ``chi2(K)`` with non-centrality ``delta' Sigma^-1 delta``. Reported by :func:`pretrends_test`, and a strictly different quantity -- not a tighter or looser version of the same one. The two are not even comparable at face value: the joint test has size exactly ``alpha``, while the coefficient-by-coefficient test rejects with probability above ``alpha`` under the null because each of the K coefficients gets its own ``alpha``-level look. Which comes out more powerful against a given trend depends on the design. ``power_joint`` is always reported alongside, so both are available from one call. .. versionchanged:: 1.21.0 The default moved from ``"joint"`` to ``"individual"`` so the number matches Roth's ``pretrends`` package. This changes the returned ``power`` for existing calls -- see MIGRATION.md. Pass ``test="joint"`` to recover the previous behaviour.individual
alphaNoSignificance level of the pre-trend test.
deltaNoHypothesised trend violation in the pre-period (length = number of pre-periods). Default: linear trend ``delta[k] = (k+1) * min(|SE|)`` -- a violation equal to one SE at the furthest lag, declining linearly to near-zero.
detailNoPayload 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
resultYesEvent-study result with pre-treatment estimates and SEs.
as_handleNoIf 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_pathNoAbsolute 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_idNoOptional 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.
data_columnsNoOptional column projection. Parquet/Feather/Stata loaders honour this for fast partial reads.
data_sample_nNoOptional uniform random subsample size (seed=0, deterministic) — useful on huge panels.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

The description discloses significant behavioral context beyond the readOnlyHint: it explains the statistical properties of the two tests, including that the individual test's rejection probability exceeds alpha under the null and that the joint test has exact size alpha. It also mentions the version change that alters the default behavior and the returned 'power' value, which is a non-obvious behavioral change. The description does not explicitly state that it is read-only, but the annotation readOnlyHint=true is sufficient, and the description adds the nuance about the change in default.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is detailed but very long, and the key pieces (what it does, how to choose 'test') are embedded in a dense paragraph. The first sentence is clear, but the rest is extensive and could be front-loaded better. It spends many words on statistical definition and version history that, while useful, could be trimmed or relegated to a note. It is not concise for an agent to quickly parse.

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

Completeness4/5

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

Given the complexity of the tool (10 params, many with defaults, statistical background), the description covers the necessary context: the two test types, the default behavior change, the optional detail levels, and the availability of both power values. The presence of an output schema and sibling tools (pretrends_test) helps, but the description does not explicitly list the required inputs for a basic call (e.g., it assumes 'result' is self-evident). It is reasonably complete for an expert but could be more explicit about what is needed for a first call.

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?

Although the schema provides descriptions for each parameter (100% coverage), the tool description enriches the qualitative semantics by explaining the statistical meaning of 'test' (the difference between individual and joint tests, including non-centrality) and the default for 'delta' (a linear trend based on one SE at the furthest lag). This goes beyond the schema's summary, giving the agent a statistical grounding to choose appropriate values.

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 defines the tool as computing the power of a pre-trend test against a hypothesized violation, with specific references to Roth (2022) and its distinction between 'individual' and 'joint' tests. It clearly differentiates from the large sibling set, particularly from pretrends_equivalence, pretrends_slope_for_power, pretrends_summary, and pretrends_test, by focusing on the power calculation and referencing the exact package that implements it.

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?

The description explicitly explains when to use this tool (for power analysis against a hypothesized violation) and contrasts it with pretrends_test (the joint Wald test), stating they are 'a strictly different quantity -- not a tighter or looser version of the same one'. It also provides context on the two pre-test strategies, which is essential for the agent to choose the correct 'test' parameter. It does not name an alternative for power computation, but it clearly states the use case and the relationship to related tools.

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

Deploy Server

Other Tools