Skip to main content
Glama
vikranthviki

Causal Decision Agent

by vikranthviki

meglm

Read-only

Fit generalized linear mixed models to analyze grouped data, estimating fixed and random effects to support evidence-backed causal decision-making.

Instructions

Fit a generalised linear mixed model.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
yYesOutcome column. For binomial models this is the number of successes; pair it with ``trials=`` to model proportions.
tolNoOptimisation controls / CI width. The default ``tol=1e-8`` keeps the Laplace fixed-effect solution aligned with lme4/Stata reference likelihood optima on the parity fixtures. For AGHQ (``nAGQ > 1``), the default optimiser budget is internally tightened to ``maxiter=5000`` and ``tol=1e-12``; explicit user-supplied controls are respected.
nAGQNoNumber of adaptive Gauss-Hermite quadrature points per scalar random effect. ``1`` (default) == Laplace approximation. Use ``nAGQ=7`` to match Stata ``meglm intpoints(7)``; values ``> 1`` require a single scalar random effect (no random slopes).
alphaNoOptimisation controls / CI width. The default ``tol=1e-8`` keeps the Laplace fixed-effect solution aligned with lme4/Stata reference likelihood optima on the parity fixtures. For AGHQ (``nAGQ > 1``), the default optimiser budget is internally tightened to ``maxiter=5000`` and ``tol=1e-12``; explicit user-supplied controls are respected.
groupYesGrouping variable for random effects.
detailNoPayload 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
familyNo``'gaussian'``, ``'binomial'``, ``'poisson'``, ``'gamma'``, or ``'nbinomial'`` (alias ``'negbin'``).gaussian
offsetNoColumn of fixed offsets added to the linear predictor (e.g. ``log(exposure)`` for Poisson rate models).
trialsNoColumn of trial counts for binomial responses. Defaults to 1 (Bernoulli).
maxiterNoOptimisation controls / CI width. The default ``tol=1e-8`` keeps the Laplace fixed-effect solution aligned with lme4/Stata reference likelihood optima on the parity fixtures. For AGHQ (``nAGQ > 1``), the default optimiser budget is internally tightened to ``maxiter=5000`` and ``tol=1e-12``; explicit user-supplied controls are respected.
x_fixedYesFixed-effect regressors (intercept added automatically).
cov_typeNoRandom-effect covariance: ``'unstructured'`` (default), ``'diagonal'``, ``'identity'``.unstructured
x_randomNoRandom-slope variables; defaults to random intercept only.
as_handleNoIf 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_pathYesAbsolute 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_idNoOptional 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_columnsNoOptional column projection. Parquet/Feather/Stata loaders honour this for fast partial reads.
data_sample_nNoOptional uniform random subsample size (seed=0, deterministic) — useful on huge panels.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.7/5.0
Behavior2/5

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

The description adds nothing beyond the readOnlyHint annotation, which indicates the tool does not mutate data. It does not disclose any behavioral traits like how it handles missing data, whether it caches results (as_handle parameter implies caching), or what the output contains. Since the description carries the burden when annotations are minimal, this is a significant gap.

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

Conciseness2/5

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

The description is extremely concise (one sentence), but for a tool with 18 parameters and an output schema, this is under-specified rather than appropriately concise. It does not front-load any decision-relevant information or structure the content for quick scanning.

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

Completeness2/5

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

Given the tool's complexity (18 parameters, output schema), the description is far from complete. It omits usage context, typical workflows, output interpretation, and any caveats. While the schema carries a lot of weight, the description should at least mention when to use this tool or what makes it distinct.

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 parameters in detail. The description adds no extra parameter semantics beyond the one-liner, but it does not need to since the schema is comprehensive. Baseline 3 is appropriate.

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 clearly states the tool fits a generalized linear mixed model, which is a specific verb and resource. However, it does not distinguish itself from sibling tools like 'mixed', 'melogit', 'mepoisson', or 'menbreg' that also fit mixed models, so the agent might not know which one to pick without inspecting schemas.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus alternatives such as 'mixed' or other mixed-model siblings. The description offers no context about specific scenarios, data requirements, or exclusions, leaving the agent to infer usage from the name alone.

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

Deploy Server

Other Tools