Skip to main content
Glama
andrewboe

ygo-format

by andrewboe

meta_inclusion

Read-only

Query Yu-Gi-Oh tournament inclusion stats: retrieve a card's recent top share and average copies by deck type, or a deck type's card inclusion table.

Instructions

How a card is played in recent tops (share of lists, average copies, by deck type), or a deck type's card inclusion table. Pass exactly one of card, deck_type (Yugioh Meta deck type name; near misses are suggested).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cardNo
daysNo
limitNo
formatYes
deck_typeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds one genuine behavioral note (near-miss deck type names are suggested), but says nothing about data freshness, time-window behavior, truncation, or result shape.

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?

Two dense sentences with the primary output description front-loaded and the parameter rule trailing. Nothing is padded, though the parenthetical stack makes the first sentence slightly hard to parse.

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

Completeness3/5

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

With five parameters, 0% schema coverage, and no output schema, the description covers the two main arguments and the exclusivity rule but omits the required-adjacent knobs (days, limit) and the format enum values. An agent can make a reasonable call but may misuse the undocumented controls.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must carry all parameter meaning. It explains card and deck_type (including the mutually exclusive rule) but never mentions format, days, or limit, leaving three of five parameters undocumented anywhere.

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?

The description names the resource (card inclusion stats in recent tops) and spells out the two distinct output modes: per-card play rate and a deck type's inclusion table. It's specific about what data comes back but never distinguishes itself from siblings like meta_snapshot or archetype.

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?

It gives an explicit operating rule: 'Pass exactly one of card, deck_type,' and hints that near-miss deck type names are resolved. That is clear selection guidance, though it doesn't say when to prefer this over meta_snapshot or other siblings.

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