Skip to main content
Glama
SVerITG

Metis

by SVerITG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Metis — Save Viz Exemplar

save_viz_exemplar

Records a data visualization you liked and why, capturing its source and provenance so your design recipes stay checkable against the original piece.

Instructions

Record a visualization you admired, and why. The provenance layer.

Call this the moment the researcher says they like something. It is the cheapest of the
three writes and the one that makes the other two honest: a recipe whose
origin is unrecorded cannot be checked against the thing it came from.

Args:
    title: What the piece is called.
    what_you_liked: In his own words where possible. The most valuable field
        in the row — "I like it" is not reusable, "the labels sit on the
        marks instead of in a legend" is.
    url: Where it lives.
    source: Publication, team or author.
    published: Date of the ORIGINAL, not of saving.
    kind: chart | map | diagram | flow | table | layout.
    screenshot_path: Local image, if the page cannot be refetched later.
    unverified: Anything in this row written from memory rather than a read.
        Say so here; a library that launders recollection into fact is worse
        than an empty one.

Returns:
    The stored exemplar and its slug — use that slug verbatim as
    `derived_from`, since slugs are truncated to 60 characters.

Input Schema

NameRequiredDescriptionDefault
urlNo
kindNo
titleYes
sourceNo
publishedNo
unverifiedNo
what_you_likedYes
screenshot_pathNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.5

TDQS

A4.1/5.0
Behavior3/5

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

No annotations exist, so the description carries the full burden. It discloses that this is a write and the cheapest of three, and explains why provenance matters, but says nothing about permissions, duplicate handling, overwrite/update semantics, or what happens on invalid input.

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

Conciseness3/5

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

The Args/Returns layout is clean and the key constraint (slug truncated to 60 chars) is actionable, but several sentences are philosophical rather than operational ("a library that launders recollection into fact is worse than an empty one"). It is longer than needed for eight parameters.

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?

Output schema exists, yet the description still adds the critical cross-tool fact that the returned slug must be used verbatim as derived_from. Combined with full param coverage, the only real gap for a write tool is failure/permission behavior.

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%, so the description does the entire job: it explains all eight params with intent, including the non-obvious ones ("published: Date of the ORIGINAL, not of saving", the unverified field's purpose, and what makes what_you_liked reusable). This is material meaning the schema cannot supply.

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 ("Record a visualization you admired, and why") and frames the tool's role as "the provenance layer," which distinguishes it conceptually from sibling write tools like save_viz_recipe and save_viz_style. An agent knows exactly what artifact this produces.

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 an explicit trigger ("Call this the moment the researcher says they like something") and positions it against the other two writes. It never names the alternatives explicitly (save_viz_recipe, save_viz_style), so the routing is inferable rather than stated.

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