Causal Decision Agent

Overview Schema Source Related Servers Discussions Admin

synth_power_plot

Read-only

Plot a statistical power curve from a synth_power result to visualize the minimum detectable effect, helping you assess whether an experiment is adequately powered before rollout.

Instructions

Plot the power curve from :func:synth_power.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`ax`	No	Axes to plot on. If ``None``, a new figure is created.
`title`	No	Custom plot title. Defaults to ``"SCM Power Curve -- Minimum Detectable Effect"``.
`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
`figsize`	No	Figure size (width, height) in inches.
`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.
`data_columns`	No	Optional column projection. Parquet/Feather/Stata loaders honour this for fast partial reads.
`power_result`	Yes	Output of :func:`synth_power`. Must contain columns ``effect_size``, ``power``, and ``mde_flag``.
`data_sample_n`	No	Optional uniform random subsample size (seed=0, deterministic) — useful on huge panels.

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.5/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 by structured data. The description adds no further behavioral detail such as figure creation behavior or chaining via result_id, but it does not contradict the annotations.

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

Conciseness5/5

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

A single declarative sentence with no filler. The core action and input source are front-loaded, and every word 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?

For a read-only plotting tool with a fully documented schema and an output schema, the description is minimally adequate. It does not explain lifecycle context such as calling after synth_power or how result caching interacts, nor does it contrast with nearby plot/synth siblings.

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 10 parameters. The description adds no parameter-level meaning beyond the implied relationship to power_result, which is already stated in the input schema.

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 names a specific verb ('Plot'), a specific artifact ('power curve'), and the upstream producer (:func:`synth_power`). This distinguishes it from generic plot tools and most synth_* siblings, though it does not explicitly name non-plot alternatives.

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 dependency on synth_power is implied, so an agent can infer this is a post-processing/visualization step after running synth_power. However, there is no explicit when/when-not guidance or reference to adjacent tools such as synth_mde or synth_power for non-plot needs.

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

Deploy Server