Skip to main content
Glama
SVerITG

Metis

by SVerITG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Metis — Save Viz Recipe

save_viz_recipe

Stores a visualization's reusable method—mark meaning, encoding, data contract, and caveats—so teams can recreate or validate charts independent of styling.

Instructions

Store the METHOD of a visualization — the half that survives a restyle.

A recipe is what makes a figure work: what the mark represents, what maps to
which channel, and what data shape it demands. Not the colours.

Args:
    name: Descriptive, e.g. "unit-dot transition flow".
    kind: chart | map | diagram | flow | table | layout.
    one_liner: What it shows, and why that framing beats the obvious one.
    encoding: What maps to position, colour, size, order.
    mark_unit: What ONE mark is. Usually the decisive choice — "one dot =
        one person" and "one bar = a percentage" are different arguments
        about the same numbers.
    data_contract: JSON object of role -> meaning, e.g.
        '{"unit_id":"one row per person","start_class":"origin group",
          "end_class":"destination group"}'
        The field that makes reuse mechanical. Without it the recipe is a
        description; with it, a dataset can be checked against it.
    interaction: static | hover | scroll-step | click-filter | animated.
    medium: html/d3 | ggplot2 | plotly | svg | leaflet.
    code: Working code if there is any. Never required — a recipe with a
        precise contract and no code is still reusable.
    caveats: How this figure can mislead. Please fill this in; a stored
        method with no stored failure mode is a way to be wrong faster.
    default_style: viz_styles.slug to use unless told otherwise.
    derived_from: viz_exemplars.slug this came from, copied verbatim.

Returns:
    The stored recipe, plus warnings for anything left dangling.

Input Schema

NameRequiredDescriptionDefault
codeNo
kindYes
nameYes
mediumNo
caveatsNo
encodingNo
mark_unitNo
one_linerNo
interactionNo
derived_fromNo
data_contractNo
default_styleNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.5

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and mostly does: it discloses that code is optional ('Never required'), that derived_from must be copied verbatim, that caveats is strongly expected, and that the write returns the stored recipe plus 'warnings for anything left dangling'. It stops short of saying whether a name collision overwrites or errors, or what permissions are needed.

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 a one-line thesis, then a clean Args block where each line earns its place. The opening framing prose ('the half that survives a restyle') is slightly literary for a tool spec but short enough not to be waste.

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?

A 12-param, annotation-free write tool is high-complexity and the description covers all parameters, the required-vs-optional intent, and the return behavior (reinforced by an output schema). The one real gap is idempotency/upsert behavior on duplicate names.

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 description coverage is 0% across 12 parameters, so the description must compensate and does: every field gets a semantic definition plus an inline example (mark_unit: 'one dot = one person'; data_contract: role -> meaning with a literal JSON sample). This is meaning an agent cannot get anywhere else.

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+resource ('store the METHOD of a visualization') and immediately scopes it against the sibling concern it is not — 'Not the colours' — which separates it from save_viz_style without opening either schema. The noun is then defined concretely as mark/channel/data-shape rather than styling.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: it says what to put in and that caveats should be filled, and implicitly distinguishes itself from the style tool. But there is no explicit 'call this when capturing a reusable method, use find_viz instead when retrieving' and no mention of siblings like save_viz_exemplar or check_viz_fit, which an agent could plausibly confuse it with.

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