Skip to main content
Glama

Metis — Save Project Figure

save_project_figure

Save a chart or visual as HTML to a project so it renders live on the project dashboard. Pass the project slug, title, and HTML; resaving with the same title replaces the figure.

Instructions

Save a finished chart or visual (HTML) to a project so it shows on the dashboard.

Use after drawing a figure as an artifact: pass the same self-contained HTML
(inline SVG, or a chart library loaded from a CDN). It is stored under the
project and appears in the Figures section of that project's panel on the
Work tab, where it renders live. Saving again with the same title replaces it.

Args:
    project_id: The project slug (as returned when the project was created).
    title: Short figure title, shown above it on the dashboard.
    html: The figure as HTML — a full page, or a fragment that will be wrapped.
    caption: One or two sentences on what the figure shows, including the
        denominator and data source.

Returns:
    Where it was saved and the dashboard link that shows it.

Input Schema

NameRequiredDescriptionDefault
htmlYes
titleYes
captionNo
project_idYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.5

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does well: it discloses storage location, that the figure renders live in the Work tab, and the important overwrite semantic ('Saving again with the same title replaces it') — an idempotency fact not inferable from the schema. It omits permissions, size limits, and failure behavior.

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

Conciseness4/5

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

Front-loaded with the purpose and the usage trigger before the parameter detail, and each section is scannable. The explicit Returns block is somewhat redundant given an output schema exists, and the prose is a touch longer than strictly needed.

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 four-parameter write tool with zero annotation coverage and no schema descriptions, the definition covers purpose, input format, storage, overwrite behavior, and destination. It lacks preconditions (does the project need to exist / be unarchived?) and any error or size-limit guidance.

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

Parameters5/5

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

Schema coverage is 0%, and the Args block compensates fully: project_id is identified as the project slug returned at creation, title as the dashboard label, html as accepting a full page or a fragment that gets wrapped, and caption as needing denominator and data source — real guidance, not restatement.

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 ('Save a finished chart or visual (HTML) to a project') plus the observable effect ('shows on the dashboard', 'Figures section of that project's panel'). An agent can distinguish it from artifact/registration siblings like save_viz_exemplar or register_code_artifact from the text alone.

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

Usage Guidelines4/5

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

Gives a clear trigger ('Use after drawing a figure as an artifact') and describes the input contract (same self-contained HTML, inline SVG or CDN-loaded library). It does not name an alternative or a when-not-to-use case, so it stops short of full routing guidance.

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