Skip to main content
Glama

guardian_review

Sanity-check a causal claim ("cause drove effect") before acting on it.

Provide exactly one of csv (CSV text), data (list of row objects) or dataset_id (a dataset uploaded via guardian_request_upload; use this for more than ~200 rows; single-use, deleted when reviewed) containing columns named by cause and effect. Returns a verdict -- pass (act), caution (act carefully), or hold (do not act; the effect looks confounded or unsupported) -- with the naive correlational effect versus the confounder-adjusted causal effect and its confidence interval, the confounders adjusted for, a confidence score, a plain-English interpretation, and a recommended action, plus the estimator used and the inferred causal DAG. All numbers are deterministic statistics (never LLM-generated); the LLM may only choose an estimator id from a fixed whitelist and write the interpretation prose.

Args: cause: Treatment column the claim says drives the outcome (e.g. "ad_spend"). effect: Outcome column (e.g. "new_customers"). csv: Dataset as CSV text (header row required). data: Dataset as a list of row records (alternative to csv). dataset_id: ID returned by guardian_request_upload after uploading the CSV (alternative to csv/data; for datasets above ~200 rows). Single-use: the dataset is deleted when reviewed, so re-upload to retry. known_confounders: Columns to adjust for; otherwise discovered automatically. context: Free-text business context, e.g. "Q3 promo evaluation". units: Display-only unit hints by column, e.g. {"ad_spend": "USD"}. step: A concrete treatment step (e.g. 1000 for a $1,000 spend increase) to restate the effect in business terms (cost per incremental outcome, ...). time_col: Column to order rows by for time series (autocorrelation-robust standard errors and adstock). adstock: Opt-in geometric-adstock transform for a lagged/carryover treatment. se: Standard-error flavor; "auto" diagnoses autocorrelation when time_col is given. test_design: true (or an options object) also returns how many periods a spend-cut test needs to confirm the effect. estimator: Primary-effect estimator. Omit (or "auto") to follow config.estimator (default "rule": the deterministic choice); "llm" lets the server's LLM pick from a fixed whitelist (falls back to the rule if no LLM is configured); or force "ols_adjusted", "aipw", "ipw", "psm" or "dml_forest" (always wins over config). The response reports the estimator used (estimator.id, .source, .rationale, .fallback_reason) and the inferred dag. config: Per-step engine config, an object with optional keys cleaning, discovery, estimator, summary, each "rule" (deterministic, no LLM) or "llm". Defaults when omitted or partial: cleaning="llm", discovery="llm", estimator="rule", summary="rule". The LLM never computes a number: cleaning proposes derived columns / null-imputation strategies (pandas computes the values), discovery prunes/orients the discovered DAG (cause/effect are always yours), estimator picks a whitelisted id, summary writes the prose ("rule", the default, is a fixed template that explains the why with no AI). An "llm" step falls back to "rule" when the server has no Gemini key or the call fails; the response's engine_steps reports requested vs used per step with a fallback reason. Unknown keys or values are rejected. Use all "rule" for a fully deterministic, reproducible run. seed: Optional base random seed (default 42) for every seeded step; the seeds used are returned in stamp.seeds. cate: Opt-in list of dataset columns to stratify by for subgroup effects (returned in cate); columns are validated against the dataset. sensitivity: Opt-in; true also returns sensitivity checks (sensitivity).

Every response carries `stamp` (core/guardian versions, estimator, resolved
config, seeds, data_fingerprint) and `llm_decisions` (audit/replay records):
a changed answer with an unchanged `stamp.data_fingerprint` came from a Syl
release or config change, not from your data. Only cleaning/discovery/estimator
set to "llm" can change a number; summary never does.

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": {
      "cause": "<cause>",
      "effect": "<effect>"
    },
    "name": "guardian_review"
  }
}

Input Schema

NameRequiredDescriptionDefault
seNoauto
csvNo
cateNo
dataNo
seedNo
stepNo
causeYes
unitsNo
configNo
effectYes
adstockNo
contextNo
time_colNo
estimatorNo
dataset_idNo
sensitivityNo
test_designNo
known_confoundersNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • addedInput schema / $defs / EngineConfigIn
      Added value: +{
      +  "additionalProperties": false,
      +  "description": "Per-step engine mode: ``\"rule\"`` (deterministic, no LLM) or ``\"llm\"``.\n\nOmitted steps take their defaults: ``cleaning=\"llm\"``, ``discovery=\"llm\"``,\n``estimator=\"rule\"``, ``summary=\"rule\"``. An ``\"llm\"`` step falls back to the rule\npath (and says so in the response's ``engine_steps``) when no server-side Gemini\nkey is configured or the LLM call fails. The LLM never computes a number.",
      +  "properties": {
      +    "cleaning": {
      +      "anyOf": [
      +        {
      +          "enum": [
      +            "rule",
      +            "llm"
      +          ],
      +          "type": "string"
      +        },
      +        {
      +          "type": "null"
      +        }
      +      ],
      +      "default": null,
      +      "description": "Derived-column proposals and null imputation. Default 'llm'.",
      +      "title": "Cleaning"
      +    },
      +    "discovery": {
      +      "anyOf": [
      +        {
      +          "enum": [
      +            "rule",
      +            "llm"
      +          ],
      +          "type": "string"
      +        },
      +        {
      +          "type": "null"
      +        }
      +      ],
      +      "default": null,
      +      "description": "LLM pruning/orienting of the discovered DAG. Guardian always supplies cause/effect, so this only affects prune/orient. Default 'llm'.",
      +      "title": "Discovery"
      +    },
      +    "estimator": {
      +      "anyOf": [
      +        {
      +          "enum": [
      +            "rule",
      +            "llm"
      +          ],
      +          "type": "string"
      +        },
      +        {
      +          "type": "null"
      +        }
      +      ],
      +      "default": null,
      +      "description": "Primary-effect estimator choice. Default 'rule'.",
      +      "title": "Estimator"
      +    },
      +    "summary": {
      +      "anyOf": [
      +        {
      +          "enum": [
      +            "rule",
      +            "llm"
      +          ],
      +          "type": "string"
      +        },
      +        {
      +          "type": "null"
      +        }
      +      ],
      +      "default": null,
      +      "description": "Interpretation prose. Default 'rule': a fixed, audit-friendly template that explains the why (confounder importance, interval, adjustment set, estimator). 'llm' lets Gemini write prose (never numbers).",
      +      "title": "Summary"
      +    }
      +  },
      +  "title": "EngineConfigIn",
      +  "type": "object"
      +}
    • addedInput schema / properties / cate
      Added value: +{
      +  "anyOf": [
      +    {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Cate"
      +}
    • addedInput schema / properties / config
      Added value: +{
      +  "anyOf": [
      +    {
      +      "$ref": "#/$defs/EngineConfigIn"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null
      +}
    • addedInput schema / properties / estimator
      Added value: +{
      +  "anyOf": [
      +    {
      +      "enum": [
      +        "ols_adjusted",
      +        "aipw",
      +        "ipw",
      +        "psm",
      +        "dml_forest"
      +      ],
      +      "type": "string"
      +    },
      +    {
      +      "const": "auto",
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Estimator"
      +}
    • addedInput schema / properties / seed
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Seed"
      +}
    • addedInput schema / properties / sensitivity
      Added value: +{
      +  "default": false,
      +  "title": "Sensitivity",
      +  "type": "boolean"
      +}
  2. Changed1 schema field changed
    • addedInput schema / additionalProperties
      Added value: +false
  3. Changed1 schema field changed
    • addedInput schema / properties / dataset_id
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Dataset Id"
      +}
  4. First observed

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and discloses important behavior: returned verdicts and effect estimates, deterministic statistics, LLM limits, estimator fallbacks, audit stamp fields, and single-use dataset deletion. It also explains that only cleaning/discovery/estimator set to llm can change a number, while summary never does.

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 front-loaded with purpose and data-input rules, then organized as Args plus response details, which suits an 18-parameter tool. It is long and repeats the LLM-never-computes-numbers point more than once, so it is not maximally concise.

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?

Although there is no output schema, the description explains the return payload thoroughly: verdict, naive versus adjusted effect, confidence interval, confounders, interpretation, recommended action, estimator metadata, DAG, stamp, and llm_decisions. Given the tool's complexity, it provides enough context to call and interpret it correctly.

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?

Schema description coverage is 0%, but the description documents all 18 parameters in an Args section, including mutually exclusive data inputs, known_confounders, context, units, step, time_col, adstock, se, test_design, estimator, config, seed, cate, and sensitivity. It adds meaning beyond the bare schema, such as dataset_id single-use behavior and estimator whitelist/fallback semantics.

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 states a specific verb and resource: sanity-check a causal claim of the form "cause drove effect" before acting on it. It distinguishes the tool from the sibling guardian_request_upload by explaining dataset_id upload flow and when to use it.

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?

It gives clear context and alternatives for supplying data: exactly one of csv, data, or dataset_id, with dataset_id for more than ~200 rows and single-use semantics. It also explains estimator/config choices, but it does not explicitly state when not to use the tool or what non-causal questions should use instead.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.