Skip to main content
Glama

add_combo_chart

Insert a combo chart with mixed series types and an optional secondary axis, enabling side-by-side comparison of measures with different units or a target line across actuals.

Instructions

Add a chart whose series are not all the same type, and may use a second value axis.

This is what add_chart cannot do. Reach for it when:

  • a measure needs a reference line across it — actuals as columns with a target as a line;

  • two measures share categories but not units — revenue in millions against a margin percentage. On one axis the percentage flattens to nothing along the bottom; on a secondary axis both are readable.

series: one entry per series, plotted in the order given: {"name": "Revenue", "values": [10, 12, 15], "type": "column", "secondary_axis": false, "color": [31, 73, 125], "data_labels": true, "label_position": "outside_end", "trendline": "linear"} "type" is required — column, stacked_column, bar, stacked_bar, line, line_markers, area, stacked_area. Pie and scatter cannot share a plot area with other types; use add_chart for those. "color" is [r, g, b]; omit to take the template's own chart palette, which is usually the right choice. "label_position" on a stacked series must be "center", "inside_end" or "inside_base" — a stacked segment has no outside. "trendline" is linear, movingAvg, exp, log, poly or power.

secondary_axis_title labels the right-hand axis; y_axis_title labels the left one. x_axis_title labels the category axis (see add_chart on why that is not the same as "the horizontal one").

The result is a real, editable PowerPoint chart, not a picture.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
topYes
leftYes
titleNo
widthYes
heightYes
seriesYes
categoriesYes
has_legendNo
slide_indexYes
x_axis_titleNo
y_axis_titleNo
legend_positionNobottom
presentation_idNo
secondary_axis_titleNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv2.6.0

TDQS

A4.6/5.0
Behavior4/5

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

Annotations only carry a title, so the description bears the transparency burden. It discloses the result type ('a real, editable PowerPoint chart, not a picture'), required series type, and constraints like stacked label positions and pie/scatter incompatibility. It does not explicitly state that the call mutates the presentation, but 'Add' plus the result statement make the create behavior clear.

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 organized with a purpose statement, use-case bullets, a structured series example, and axis-title clarification. Every section adds needed information without fluff, and the most important differentiator is front-loaded.

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?

The tool is complex with 14 parameters and no schema descriptions, but the description covers the hardest parts (series configuration and axis semantics) and the result type. It omits guidance on legend_position values and presentation/slide targeting, but those are either conventional or inferable from parameter names, and an output schema exists for return values.

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?

With 0% schema description coverage, the description provides essential semantics for the complex parameters: the full series entry format, allowed chart types, color format, label_position constraints, and trendline values. It also clarifies secondary_axis_title vs. y_axis_title vs. x_axis_title. However, it leaves legend_position, has_legend, categories, and layout parameters to inference from their names.

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 opens with a specific verb and resource: 'Add a chart whose series are not all the same type, and may use a second value axis.' It explicitly differentiates from add_chart by stating 'This is what add_chart cannot do,' making its purpose unmistakable.

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?

It gives concrete when-to-use scenarios (reference line across a measure, two measures with different units) and names the alternative: 'use add_chart' for pie/scatter charts that cannot share a plot area. This is explicit routing between siblings.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/photonn/dial-pptx-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server