Syl Guardian

io.sylaiPublished by sylai.ioOfficial publisherv0.3.1Updated Oct 29, 2026

Causal check on AI agent claims, from ad-spend/ROAS lift to any decision: pass, caution or hold.

VerifiedStreamable HTTPWeb executableData & AnalyticsBusiness & Commerce

Overview

AI-generated overview

Hosted causal-check service that lets an assistant test a "X drove Y" claim against your data and get a pass, caution or hold verdict before acting.

What you can do
  • Review a causal claim: pass cause and effect columns plus a dataset and get a verdict, naive correlation versus adjusted effect, confidence and a plain-English recommendation.
  • Upload large datasets: request a one-time pre-signed upload link and dataset ID for CSVs over roughly 200 rows, then review by dataset ID.
  • Tune the analysis: name known confounders, a time column, a treatment step, subgroup columns, sensitivity checks, a seed, and per-step rule or LLM configuration.
When to use it
Use it when an agent is about to act on a claimed cause-and-effect relationship, such as scaling ad spend because ROAS or conversions look good, changing bids, or shipping a discount, and you want a statistical sanity check first. It suits marketing and budget decisions where confounders could make an apparent lift misleading.
Requirements
Remote streamable HTTP endpoint; no local package needed. A Syl Guardian API key is required in the X-API-Key header, obtained as a trial key from the provider. Listing tools works without a key; each review counts against the plan or trial quota, while requesting an upload link does not.
Before you install
Your dataset is sent to a third-party hosted service; uploaded files are visible only to the uploading key, are single-use, and are deleted when reviewed or after 30 minutes. Reviews consume plan or trial quota. Default cleaning and discovery steps use an LLM, which can change the estimate; set them to rule for strict reproducibility. Verdicts are statistical guidance, not a guarantee.

Installation

In SourceWeft

  1. Open Syl Guardian in the dashboard and add it to a workspace.
  2. Connect X-API-Key credentials. They are stored privately and never shown on public pages.
  3. Enable the server for the chats that should use its tools.

Web executable via Streamable HTTP. Remote servers run from the web runtime once configured in a workspace.

Use with an agent

Paste this prompt into Claude Code, Codex, Cursor or another agent — or into SourceWeft chat. The agent reads this server's install guide, shows you its publisher, endpoint and sign-in, and adds it to your client once you agree. Keys never go into a command.

Read https://sourceweft.com/mcp/io.sylai%2Fguardian/install.md and connect the MCP server it describes to my client. Before changing any config, show me its publisher, endpoint and sign-in method and wait for my OK. Never put an API key in a command or in a file I would commit; ask me where it should come from.

Read the install guide the agent follows

Other MCP clients

Add this to your client's mcpServers config.

{
  "mcpServers": {
    "syl-guardian": {
      "type": "http",
      "url": "https://guardian.sylai.io/mcp",
      "headers": {
        "X-API-Key": "<YOUR_API_KEY>"
      }
    }
  }
}

README

Syl Guardian MCP

Is this ROAS / spend-to-revenue lift actually causal?

Syl Guardian is a Model Context Protocol (MCP) server that works as a causal-validation agent guardrail. When an AI agent (Claude or any MCP client) is about to act on a claim about ad spend or budget, such as "this campaign's ROAS is 4x, scale it up" or "ad spend drove new customers", Guardian checks the claim against your data and returns a pass, caution or hold verdict, with the naive correlation versus the confounder-adjusted causal effect, a confidence score and a plain-English recommendation.

Every number is computed deterministically by statistical code and never by an LLM. By default the summary is a fixed template. For strict reproducibility, set cleaning and discovery to rule in config: the default (llm) for those two steps can change the adjustment set, and so the estimate. See Engine config and Determinism and reproducibility.

This repository holds the public listing metadata and connection instructions for the hosted Guardian MCP server. Guardian itself is a hosted service.

Connect

Claude Code:

bash
claude mcp add --transport http syl-guardian https://guardian.sylai.io/mcp \  --header "X-API-Key: <your key>"

Claude Desktop (via mcp-remote):

json
{  "mcpServers": {    "syl-guardian": {      "command": "npx",      "args": ["-y", "mcp-remote", "https://guardian.sylai.io/mcp",               "--header", "X-API-Key:${SYL_API_KEY}"],      "env": { "SYL_API_KEY": "<your key>" }    }  }}

Then ask your agent: "Use guardian_review on this data: did ad_spend cause new_customers? Treat seasonality as a confounder."

Listing the tools does not require a key. A key is checked when guardian_review is called, and each review counts against your plan or trial quota. Requesting an upload link (guardian_request_upload) does not count toward quota.

Use with agents

Add this rule to your agent's instructions so it checks ad-spend and budget claims before recommending a change:

Whenever evaluating marketing campaigns, ad platforms, or budget allocation, verify the claimed effect is causal using the Syl Guardian MCP tool (guardian_review) before giving a final recommendation.

Ready-to-paste sections for CLAUDE.md, AGENTS.md and .cursorrules are in AGENT_RULES.md. Also available:

Python client

For Python agents and scripts, syl-guardian-client is a thin, MIT-licensed client for the hosted service. It only makes HTTP calls to https://guardian.sylai.io; every number is still computed deterministically by the service, never by an LLM. Set your key in SYL_GUARDIAN_API_KEY.

bash
pip install syl-guardian-client            # extras: [crewai], [langchain]
python
from syl_guardian_client import GuardianClient
result = GuardianClient().review(    "ad_spend", "conversion_value",    data=rows, time_col="date", step=500,    known_confounders=["brand_query_click_pct"],)result.verdict  # "pass" | "caution" | "hold"

Tool: guardian_review

Sanity-checks a causal claim before an agent acts on it.

ArgumentDescription
cause, effectRequired. Column names for the claim.
csv, data or dataset_idDataset as CSV text, a list of row objects, or the dataset_id of a previously uploaded file (see Large datasets). Exactly one.
known_confoundersOptional. Columns to adjust for; otherwise discovered automatically.
contextOptional business context, e.g. "Q3 promo evaluation".
units, stepDisplay-only unit hints; a treatment step to restate the effect in business terms.
time_col, adstock, seTime-series handling: row ordering, carryover effects, standard-error flavor.
test_designtrue or options. Also returns how long a spend-cut test needs to run.
cateOptional. List of columns to stratify by; also returns subgroup effects. Off by default.
sensitivityOptional. true also returns sensitivity checks on the estimate. Off by default.
seedOptional integer (default 42). Fixes every random draw; the seeds used are returned in stamp.
configOptional object choosing rule or llm per step: cleaning, discovery, estimator, summary. See Engine config.
estimatorOptional. Omit or auto (default): defers to config.estimator, which defaults to rule (deterministic choice). Or force one of ols_adjusted, aipw, ipw, psm, dml_forest. See Estimator choice and DAG.

The result includes a text summary (verdict, recommended action, effect versus correlation, interpretation) and the full structured response. Bad input (including an unknown config key or value), auth failures and quota errors come back as MCP tool errors with a descriptive message. Misspelled argument names are rejected, not ignored.

Engine config

config lets you choose, per step, whether the engine uses fixed rules or an LLM. Each value is "rule" or "llm". Omitted keys use the defaults:

StepDefaultWhat it controls
cleaningllmDataset cleaning: derived columns and null imputation. The LLM only picks a strategy per column (for example median or drop rows); the values are computed deterministically, and your cause and effect columns are never imputed.
discoveryllmPruning and orienting the causal graph. Guardian always receives your cause and effect, so it does not name them.
estimatorrulePicking the estimator from the supported set, based on each method's documentation.
summaryrulerule is a fixed template for audit trails that explains why: confounder importance, the interval in plain terms (in dollars when units are known), and why this adjustment set and estimator. llm is AI-written prose.

The model key is provided by the service; you never supply one. rule always works. If an llm step cannot run, it falls back to rule, and the result's engine_steps reports {requested, used, fallback_reason} for each step (for example llm_unavailable). Setting all four to rule makes no LLM calls.

Example: {"config": {"cleaning": "rule", "discovery": "rule"}}.

Determinism and reproducibility

Under the defaults, the same data and request give the same verdict, estimate and interval. Randomness uses a fixed seed that is returned. What can change the estimate:

SettingCan change the estimate?
cleaning: llmYes: the imputation strategy and which derived columns are dropped.
discovery: llmYes: the adjustment set.
estimator: llmYes: the choice of method.
summary: llmNo: prose only.

LLM calls run at temperature 0 with a pinned model, and each decision is recorded in llm_decisions and cached, but providers do not guarantee bit-identical output on a cache miss or model change, and the cache is in memory only. For strict reproducibility set cleaning and discovery to rule.

Estimator choice and DAG

With estimator omitted or "auto", the estimator comes from config.estimator. The default is rule: a deterministic choice (no confounders: naive OLS; binary treatment: AIPW; otherwise adjusted OLS). With config.estimator = "llm", an LLM picks one estimator (plus bounded parameters) from a fixed whitelist, filtered to what your data supports. It sees only a column schema summary, the DAG edges and the adjustment set, never your rows, and it never computes a number: the chosen estimator is run deterministically with fixed seeds. Passing a whitelist id forces that estimator with no LLM involved.

If the LLM is unavailable or returns an invalid or ineligible choice, or a requested estimator is ineligible for the data or fails, Guardian falls back to the deterministic rule. This is always reported, never hidden.

Every result includes these fields:

  • estimator: id, params, source, rationale and fallback_reason. source is rule (also the value when no LLM is available), llm, override, or fallback (an LLM choice or override was attempted but rejected or failed). rationale is LLM-written prose and is set only for llm. fallback_reason explains why the requested estimator was not used, otherwise null.
  • dag: the inferred causal graph, as nodes and edges of the form {"source": ..., "target": ...}. It reflects the cleaned data and any known_confounders.
  • engine_steps: requested versus used mode for each step, with any fallback reason.
  • stamp: a method and version stamp (core version, estimator, methods run, resolved config, seeds, models used, a data fingerprint, and the service name and version). If an answer changes between two runs, the stamp shows whether the data or a Syl release changed.
  • llm_decisions: the LLM decisions made on this review (empty when no step used an LLM).
  • confounder_importance: with summary: rule, how much the estimate moves when each adjustment variable is dropped, as a share of the total movement.
  • cate and sensitivity: present only when requested.

Tool: guardian_request_upload

Returns a one-time upload link for a dataset too large to pass inline.

Result fieldDescription
upload_urlURL to PUT the file to.
dataset_idPass this to guardian_review as dataset_id.
expires_atWhen the upload link expires.
max_bytesMaximum accepted upload size.

The result also includes a ready-to-run curl hint.

Large datasets

Use inline csv or data for small data. For more than about 200 rows, use the upload flow:

  1. Call guardian_request_upload, then upload the file with the returned URL:

    bash
    curl -T data.csv "<upload_url>"

    Gzip is allowed, e.g. curl -T data.csv.gz -H "Content-Encoding: gzip" "<upload_url>". The PUT response returns only the schema (columns, dtypes, n_rows), never rows.

  2. Call guardian_review with dataset_id instead of csv or data (they are mutually exclusive). Each uploaded dataset is single-use.

Uploaded datasets are visible only to the API key that uploaded them. Each dataset is deleted as soon as guardian_review runs on it, even if the review fails, so a retry needs a fresh guardian_request_upload. Unused uploads are deleted after 30 minutes.

A dataset_id can be reviewed once.

Example prompt: "My data is in sales.csv (50,000 rows). Request an upload link, upload the file with curl, then use guardian_review once with the returned dataset_id (uploads are single-use): did ad_spend cause new_customers?"

Support

Questions or issues: https://sylai.io or [email protected].

License

The files in this repository (metadata and documentation) are MIT licensed; see LICENSE. The Syl Guardian service is proprietary.

Source: README.md at commit b0c3dc0

Tools

2

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:

Parameterssecsvcatedataseedstepcauserequiredunitsconfigeffectrequiredadstockcontext+6 more

guardian_request_upload

Get a pre-signed URL for uploading a large CSV (more than ~200 rows). Use this instead of pasting rows into ``guardian_review``. Returns ``upload_url``, ``dataset_id`` and a ready-to-run ``curl`` command: run it (replace ``data.csv`` with your file; gzip is accepted with ``Content-Encoding: gzip``), then call ``guardian_review`` with ``dataset_id`` (and no ``csv``/``data``). The URL is single-use and expires after 30 minutes; the dataset is only usable by the same API key, and is single-use too: it is deleted when ``guardian_review`` reads it (even if that review fails), so request a new upload to retry. This call does not consume review quota.

Takes no parameters.

Version history

2
  1. v0.3.1LatestOct 29, 2026
  2. v0.3.0Oct 22, 2026

Score

100% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 daysRequired25 pts
  • Auth declaredRequired10 pts
  • Tools listedRequired15 pts
  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts

Other Sylai integrations