Causal Decision Agent

Overview Schema Source Related Servers Discussions Admin

ltmle_survival

Read-only

Estimate causal effects of dynamic treatment regimes on discrete-time survival outcomes using LTMLE, adjusting for time-varying covariates and censoring.

Instructions

LTMLE for a discrete-time survival outcome under dynamic regimes. Validation: validated evidence tier (known-truth, reference, external-parity, or Monte Carlo artifact). Assumptions: Unconfoundedness (sequential exchangeability for longitudinal/LTMLE); Positivity / overlap of treatment given history; At least one nuisance (outcome or treatment) is estimated consistently; the targeting step gives double robustness. Pre-conditions: Covariates, treatment, and outcome (for survival/longitudinal variants: time-to-event and time-varying covariates); Enough data to fit a Super Learner / HAL nuisance library. Failure modes: Near-positivity violations create extreme clever-covariate weights -> Truncate weights, restrict the estimand, or report a positivity diagnostic. Alternatives: sp.dml, sp.ipw, sp.g_computation. Typical minimum N: 400.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`alpha`	No	Significance level for confidence intervals and tests.
`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
`baseline`	No	Time-invariant baseline covariates.
`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.
`censoring`	No	``1`` if the subject is observed through interval k, ``0`` if right-censored at or before k. If omitted, no censoring.
`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.
`treatments`	Yes	Treatment column per interval.
`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.
`regime_control`	No	Treatment regimes, same semantics as :func:`ltmle`.
`regime_treated`	No	Treatment regimes, same semantics as :func:`ltmle`.
`covariates_time`	Yes	Time-varying covariates at each interval.
`event_indicators`	Yes	Column names for the per-interval event indicator ``T_k`` (``1`` if the event occurs in interval k, ``0`` otherwise).
`propensity_bounds`	No	propensity_bounds parameter (Tuple[float, float]).

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

A4.5/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so no contradiction. The description adds valuable behavioral context: failure modes around positivity violations leading to clever-covariate weights, the double-robustness property from the targeting step, and validation tier semantics.

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?

The description is compact and structured with labeled sections (Validation, Assumptions, Pre-conditions, Failure modes, Alternatives, Typical minimum N), front-loading the core definition. No filler or redundant phrasing.

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

Completeness5/5

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

The description covers validation tier, assumptions, pre-conditions, failure modes, alternatives, and minimum sample size. Since an output schema exists, return-value details are not required; the description is complete for an estimator of this complexity.

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?

The input schema provides 100% coverage with descriptions for all 15 parameters, including treatments, event_indicators, censoring, and regime parameters. The description mentions covariates, treatment, outcome, and time-to-event/time-varying covariates, but the schema already carries the heavy lifting for parameter meaning.

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 opening sentence clearly states the method (LTMLE), the target outcome (discrete-time survival), and the setting (dynamic regimes). This distinguishes it from sibling tools such as ltmle, tmle, and hal_tmle by specifying the survival-outcome variant.

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

Usage Guidelines4/5

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

The description explicitly lists alternatives (sp.dml, sp.ipw, sp.g_computation) and provides preconditions, assumptions, failure modes, and a typical minimum N. It does not offer an explicit 'use this when X, alternative when Y' contrast, but the context is clear enough for an expert agent.

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

Deploy Server