Skip to main content
Glama

pulse_analyze

Estimate a causal effect from a dataset and answer a business question.

Provide exactly one of csv (CSV text) or data (list of row objects). Returns the full long-form Pulse report (the same answer an email reply contains) as the primary text content and as report in the structured result, followed by chart PNGs as image content blocks (unless include_charts is false). Structured fields: the adjusted effect size (ate/effect_size) with its confidence interval (ci_low, ci_high, ci_range), per-channel effects (channels, keyed by outcome), confidence, and caveats. A test_design (how long a spend-cut test would take to confirm the effect, and whether the data already suffices) is included only when the question asks about sample size, power, or how long a test would take, or when include_test_design is true; otherwise it is null. With include_guardian_verdict it also returns guardian_verdict {verdict: pass|caution|hold, reason}, computed locally. All numbers are deterministic statistics, never LLM-generated.

Args: question: The business question, e.g. "Does ad spend drive sales?". csv: Dataset as CSV text. data: Dataset as a list of row records (alternative to csv). cause: Treatment column (inferred from the question if omitted). effect: Outcome column (inferred if omitted). confounders: Columns to adjust for, in addition to those discovered. outcomes: Several outcome columns, for by-channel effects. time_col: Time column (used for the test-design cadence). include_guardian_verdict: Also return a pass/caution/hold verdict. include_charts: Attach chart images (DAG, effect, trend) as image content. include_test_design: Force the spend-cut test design / sample-size section on (true) or off (false). Omit (null) to include it only when the question asks about sample size, statistical power, or how long a test would take. estimator: Optional estimation method: ols_adjusted, aipw, ipw, psm or dml_forest (or "rule" for the deterministic default). Omit to follow config.estimator (default "rule"; "llm" lets the model choose from that list, falling back to the rule choice when no LLM key). config: Optional per-step engine config, e.g. {"summary": "rule"}. Keys: cleaning, discovery, estimator, summary; each "rule" (deterministic, no LLM call) or "llm" (LLM-assisted; falls back to rule and says so in engine_steps when no key is configured or the call fails). Defaults: cleaning=llm, discovery=llm, estimator=rule, summary=llm. All "rule" makes zero LLM calls. Numbers are deterministic in every mode.

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": {
      "question": "<question>"
    },
    "name": "pulse_analyze"
  }
}

Input Schema

NameRequiredDescriptionDefault
csvNo
dataNo
causeNo
configNo
effectNo
outcomesNo
questionYes
time_colNo
estimatorNo
confoundersNo
include_chartsNo
include_test_designNo
include_guardian_verdictNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / config
      Added value: +{
      +  "anyOf": [
      +    {
      +      "additionalProperties": {
      +        "type": "string"
      +      },
      +      "type": "object"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Config"
      +}
    • addedInput schema / properties / estimator
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Estimator"
      +}
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

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

With zero annotations the description carries the full burden, and it discloses a lot: charts are image content blocks unless disabled, test_design is conditionally null, guardian_verdict is computed locally, config steps can be rule or llm with documented fallbacks, and all numbers are deterministic. Remaining gaps are error behavior for missing/invalid data, size/latency limits, and an explicit statement that the call has no side effects.

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?

Front-loaded with purpose and the input constraint, then output shape, then per-argument detail — a sensible ordering. The main waste is redundancy: the include_test_design trigger condition is stated in the body and restated almost verbatim in Args, and the 'deterministic numbers' point appears twice.

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?

There is no output schema, so the description correctly spends its bulk on what comes back (long-form report, ate/ci fields, channels, caveats, optional test_design and guardian_verdict) and on the config/estimator fallback logic. For a 13-parameter tool this is close to sufficient; missing only failure modes and any data-size or permission preconditions.

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%, and the Args block fully compensates: all 13 parameters are documented with meaning, not just names ('confounders: columns to adjust for, in addition to those discovered', 'time_col: used for the test-design cadence'). It even enumerates estimator values (ols_adjusted, aipw, ipw, psm, dml_forest, rule) and the valid config keys and their defaults where the schema supplies only bare types.

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?

Opens with a specific verb+resource: 'Estimate a causal effect from a dataset and answer a business question.' An agent immediately knows this is causal-inference analysis over a supplied dataset, and the follow-up sentence pins down the required input shape ('exactly one of csv or data'). No siblings exist, so no differentiation is owed.

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?

Gives concrete invocation guidance: supply exactly one of csv or data, omit cause/effect to have them inferred, and how include_test_design (null/true/false) changes output. It does not state a general 'use this when…' rule or exclusion conditions, but with no sibling tools there is nothing to route against.

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.