Skip to main content
Glama

Autario Data Analytics Platform

publish_chart

Publish a chart via freeform Plotly spec. Use create_chart_from_spec instead unless you need a Plotly feature the Builder spec doesn't cover (custom shapes, multi-axis layouts, animation frames). Requires AUTARIO_API_KEY. Brand attribution + insight verification gate apply identically to create_chart_from_spec.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleYesChart title. Include time range in parentheses, use pipe | as separator (e.g. "GDP Growth | Major Economies (2000-2024)")
insightNo2-3 sentence data insight with specific numbers from the queried data. Must use verified numbers from query_dataset results, never from training data
narrationNoLonger description of the analysis methodology and context
dataset_idsYesArray of dataset UUIDs that this chart uses. Autario pulls real data from these datasets to ensure no hallucinated values
plotly_specNoPlotly specification with traces array and layout object. Traces use x_col/y_col for column references and group_by/group_value for filtering (e.g. {"traces": [{"x_col": "year", "y_col": "value", "group_by": "country", "group_value": "USA"}], "layout": {}})

TDQS

A4.3/5.0
Behavior4/5

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

Annotations indicate writing and non-destructive behavior. Description adds context about authentication (AUTARIO_API_KEY) and verification gates. While not detailing side effects or output, the annotations lower the burden, and the description provides additional useful behavioral context.

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?

Three sentences, each serving a distinct purpose: stating the tool's function, providing an alternative, and listing prerequisites. Front-loaded with the most important information. No wasted words.

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

Completeness3/5

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

Given the complexity (5 parameters, nested plotly_spec) and no output schema, the description covers purpose and comparison but lacks return value information and usage tips for the complex plotly_spec parameter. It is adequate but incomplete.

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 coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema; it repeats the concept of 'freeform Plotly spec' but does not elaborate on parameter usage or constraints. No extra value is provided.

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?

Description clearly states it publishes a chart using a freeform Plotly spec and distinguishes from create_chart_from_spec by noting that the latter should be used unless specific Plotly features are needed. The verb 'publish' and resource 'chart' are explicit, and sibling differentiation is provided.

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?

Explicitly instructs to use create_chart_from_spec instead unless Plotly features are required. Also mentions requirements: AUTARIO_API_KEY, brand attribution, and insight verification gate, providing clear context for when to use this tool.

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.

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