Autario Data Analytics Platform

decompose_drivers

Read-onlyIdempotent

CONFOUNDER-AWARE DRIVER ANALYSIS: fits ONE multiple regression of the target on ALL candidates jointly, so each effect is estimated holding the other candidates constant. Distinguishes "it was the weather" from "a promo ran at the same time": candidates too entangled to separate (VIF > 5 or pairwise |r| > 0.8) are flagged not_separable (named pairs) instead of ranked with a confident wrong number. Returns per candidate: standardized coefficient (effect size), raw slope, p-value, VIF, pairwise r (for the pairwise-vs-joint contrast), and the best lead/lag vs the target. Use this instead of find_drivers when candidates may overlap (promo calendars, weather, seasonality) or when you need honest independent effect sizes. Omit entity for entity-less private KPI series. 2-15 candidates.

Input Schema

TableJSON Schema

Name	Required	Description
`time`	No
`entity`	No	Entity code (e.g. DEU). Omit for entity-less private series.
`max_lag`	No	Max lead/lag periods to scan per candidate (0 disables, default 5, max 20)
`candidates`	Yes	Candidate indicator ids to decompose jointly (2-15)
`target_indicator`	Yes	The KPI you want to explain

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds critical behavioral details: the statistical method (multiple regression), multicollinearity handling (flagging not_separable pairs), and output fields. No contradictions.

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 concise and well-structured: bold title, method explanation, collinearity handling, output, usage instruction, and entity note. Every sentence adds value, and key information is front-loaded.

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?

No output schema exists, but the description clearly explains the return per candidate. It covers constraints, when to use vs siblings, and entity behavior. Annotations cover safety, making this complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 80% (4 of 5 parameters have descriptions). The description adds context for entity omission and candidate count range, and implies max_lag scanning for lead/lag. It does not add details for time, but overall adds value beyond the schema.

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 clearly states it performs a multiple regression to decompose a target into driver contributions, accounting for confounders. It explicitly distinguishes itself from find_drivers by focusing on overlapping candidates and providing honest effect sizes.

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

Usage Guidelines5/5

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

The description explicitly says 'Use this instead of find_drivers when candidates may overlap or when you need honest independent effect sizes.' It also provides constraints: 2-15 candidates, omit entity for entity-less series, and max_lag default.

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

All Autario Data Analytics Platform tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0

Disambiguation4/5

Most tools are strongly domain-specific with clear boundaries, especially the 360 reports and dataset/chart CRUD tools. Some overlap exists around driver analysis (find_drivers, what_matters, decompose_drivers) and dataset discovery (search_datasets, discover_by_topic, list_indicators), but the descriptions make the intended use cases mostly distinguishable.

Naming Consistency4/5

The vast majority of tools follow a clear snake_case verb_noun or get_noun pattern, e.g. list_connectors, refresh_connector, query_dataset, delete_dataset. Minor deviations such as calculate, describe, bubble_or_not, what_matters, and the 360-style report names keep it from being perfectly uniform.

Tool Count2/5

48 tools is far beyond the 3-15 range and even beyond the 25-tool threshold for a heavy surface. The platform is broad and the tools are organized into domains, but the sheer number creates a high selection burden for an agent and suggests the server is trying to cover too many workflows in one toolset.

Completeness4/5

The toolset covers dataset lifecycle, chart lifecycle, data discovery, querying, statistics, app context, connectors, and admin reports remarkably well. Notable gaps are the lack of a delete_chart tool and no row-level update/delete for datasets, but agents can generally work around these or treat them as intentional platform constraints.

Resources

Need Help?