Skip to main content
Glama
SVerITG

Metis

by SVerITG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Metis — Check Viz Fit

check_viz_fit

Validates whether a dataset can feed a saved visualization recipe with your proposed role-to-column mapping, reporting missing roles, nonexistent columns, unused fields, and caveats.

Instructions

Check that a dataset can feed a saved recipe. YOU propose the mapping.

The tool that makes "reproduce this with other data" a check rather than a
hunch — and it contains no cleverness on purpose. Reading that
`screening_mode` is the origin category in this dataset is semantics, which
is your job. Confirming that every role was accounted for, that each column
named actually exists, and that nothing was mapped which the recipe never
asked for is bookkeeping, which is this tool's job.

An earlier version guessed the mapping by comparing role names to column
names. It reported the same "0 matched" for a dataset built to fit and one
that could not fit at all, because roles are abstract precisely so they
carry no dataset's vocabulary. A check that cannot fail differently is
decoration, so it was removed.

Args:
    recipe: viz_recipes.slug.
    mapping: JSON object of role -> column in YOUR data, e.g.
        '{"unit_id":"health_zone","start_class":"endemicity_2015",
          "end_class":"endemicity_2025","group":"province"}'
    columns: Optional comma-separated full column list. Supply it and the
        check also catches a column you named that does not exist, plus
        reports what is left unused.

Returns:
    Ready or not-ready, what is missing, and the recipe's caveats — reprinted
    here because the moment of use is when a caveat is actually read.

Input Schema

NameRequiredDescriptionDefault
recipeYes
columnsNo
mappingYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.5

TDQS

A4.4/5.0
Behavior5/5

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

No annotations exist, yet the description carries the full burden: it declares the tool does no inference, lists exactly what it validates (role coverage, column existence, extraneous mappings), explains the historical failure that motivated the design, and describes the ready/not-ready return plus caveat reprinting. The non-guessing behavior is precisely the trait an agent most needs to know.

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?

Purpose and the agent's responsibility are front-loaded, and the Args/Returns blocks are tight. The paragraph about the earlier heuristic version runs long for what it establishes, and the rhetorical framing ('a check rather than a hunch', 'decoration') costs more words than the point requires.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a three-parameter validator with an output schema, every caller-facing question is answered: what to pass, what is validated, what the tool will not do, and what comes back. Nothing needed to invoke it correctly is missing.

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%, so the description must compensate and does: recipe is identified as a viz_recipes.slug, mapping is a JSON role->column object with a concrete example, and columns is an optional comma-separated list whose additive checking behavior is spelled out. All three parameters gain meaning not present in the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and scope: 'Check that a dataset can feed a saved recipe,' with the explicit division of labor that the agent proposes the mapping. The purpose is unmistakable, though it never names the sibling tools it borders on (find_viz, save_viz_recipe) to route the agent away from them.

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?

Clearly frames the use case ('reproduce this with other data') and tells the agent what it must supply versus what the tool checks, plus a conditional behavior for the optional columns argument. It stops short of explicit when-not guidance or naming alternatives.

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