Skip to main content
Glama
anythink-cloud

Anythink-MCP

Official

Charts: preview

charts_preview
Read-only

Preview the rows a chart configuration would plot against current project data without saving, so you can validate entity, grouping, measure and filters before creating it.

Instructions

Show the data a chart configuration would draw, without saving it. Runs a chart configuration against the project's current data and shows the points, totals or rows it would plot, trimmed to rows. Use it to settle entity, grouping, measure and filters before charts_create or charts_update; for a chart already saved, use dashboards_widget_preview. Returns JSON.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoEnd of a custom time window, e.g. 2026-03-31
aggNoHow to combine the --measure values: count (default), sum, avg, min or max
fromNoStart of a custom time window, e.g. 2026-01-01
rowsNoMost rows or points to show (default 50)
sortNoSort direction: asc or desc
typeNoChart type: column (bar chart), line, pie, area, stat, gauge or funnel
limitNoMost points or rows to plot
configNoOther chart settings as a JSON object, e.g. {"limit":10,"target":500} or funnelStages for a funnel. Typed options win over this. Setting names can be camelCase or snake_case
entityNoEntity whose records the chart plots (for an entity chart)
filterNoFilter as field:operator:value, e.g. status:eq:published. Operators: eq, ne, gt, gte, lt, lte, contains, in, exists, not_exists. Repeat for several fields. Replaces the chart's existing filters
sourceNoWhere the data comes from: entity (default), platform (usage metrics) or quota (plan limits)
targetNoGoal or warning level drawn on a stat or gauge
compareNoCompare with the previous period (true/false)
measureNoNumeric field to aggregate (needed unless --agg is count)
group_byNoField for the x axis, or the slices of a pie. A date field is bucketed with --interval
intervalNoBucket size for a date --group-by: hour, day, week, month, quarter or year
stack_byNoField that splits each bar or point into a second breakdown
timeframeNoTime window: all, 24h, 7d, 30d, 90d, 365d or custom
cumulativeNoPlot a running total (true/false)
target_modeNoWhat --target means: goal or warning
compare_daysNoHow many days back the comparison period starts (defaults to the length of the time window)
quota_metricNoPlan limit for a quota chart: storage, files, users, workflows or emails
compare_overlayNoDraw the previous period over the current one (true/false)
platform_metricNoUsage metric for a platform chart. List them with: charts platform-metrics
platform_periodNoWindow for a platform metric: day, week, month, quarter or year

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.37

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false). The description adds real value beyond them: it clarifies that nothing is saved, that it runs against the project's current data, that output is trimmed to rows, and that it returns JSON. It does not mention auth/permission needs or rate limits, keeping it short of a 5.

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 tight sentences, front-loaded with the core purpose, then usage, then return format. No filler; every sentence earns its place.

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?

For a 25-param, no-required preview tool with no output schema, the description covers purpose, when to use, and a rough return shape ('points, totals or rows', 'Returns JSON'). It is complete enough to call correctly, though it could say more about the returned structure since no output schema exists.

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% across all 25 parameters, so the schema already docs each option in detail. The description reinforces key concepts (entity, grouping, measure, filters, row trimming) but adds no syntax or format detail beyond the schema. Baseline 3 is correct when the schema does the heavy lifting.

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?

States a specific verb and resource: preview the data a chart configuration would draw without saving. It explicitly names what it produces (points, totals, rows) and distinguishes itself from `charts_create`, `charts_update`, and `dashboards_widget_preview`, so an agent can select it without opening any schema.

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?

Explicit when-to-use: settle entity, grouping, measure and filters before create/update. Also names the alternative for the already-saved case (`dashboards_widget_preview`). Both the positive condition and the routing alternative are spelled out.

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