Skip to main content
Glama

Get Jp Summary

get_jp_summary

The JAPANESE card market today as numbers — no card names or prices: cards priced this morning (365K+ across 24 games, ~167K with BOTH an ask and a dealer buyback bid), the bid as a share of ask per price band (a bulk floor under ~¥300, a real quote above), per-game depth, how much of the board moved since yesterday and a week ago, and the day's Merkle root with both chain txs. FREE. The Japanese panel is LIVE while the USD panel is frozen. Per-card is https://oracle.the-undesirables.com/jp/card/{game}/{set_code}/{card_id} (one card per request; there is deliberately no listing route).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations provided, the description carries the behavioral burden and does well: it discloses that the tool is FREE, that the Japanese panel is LIVE while the USD panel is frozen, and that per-card lookups are intentionally not available here. It does not mention rate limits or authentication, but for a zero-parameter summary tool this is a minor gap.

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

Conciseness5/5

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

The description is dense but well organized, front-loading the core purpose and then listing specific data elements. Every sentence adds value—scope, contents, cost/status, and the related per-card URL—without redundant filler.

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?

Given the output schema exists and the tool has no parameters, this description is complete enough for an agent to decide when and how to invoke it. It covers the data scope, current availability status, cost, and clarifies the boundary between this summary tool and per-card lookups.

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

Parameters4/5

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

The tool has zero parameters and 100% schema coverage, so the baseline is 4. The description adds relevant context by clarifying the absence of a listing route and providing the per-card URL, which helps the agent understand why no input parameters are needed.

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?

The description clearly identifies the tool as providing a numerical summary of the Japanese card market, explicitly stating what it includes (card counts, bid/ask ratios, per-game depth, movement, Merkle root) and what it excludes (card names or prices). It differentiates itself from siblings by being the Japanese panel, LIVE while the USD panel is frozen, and by noting there is deliberately no listing route.

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?

The description gives strong contextual cues: use this for the Japanese market summary as numbers, not for per-card queries, and the link for per-card data is provided. It does not explicitly name sibling tools or state when-not-to-use, but the LIVE vs frozen panel note and the no-listing-route statement effectively guide usage.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources