ANIME INTELLIGENCE

ANIME INTELLIGENCE - Anime Collectible Price History

price_history

Read-onlyIdempotent

Stored asking-price history for the exact Japanese anime collectible across supported marketplaces. Returns 7/30/90/180-day ranges, daily medians, current percentile and trend without claiming completed-sale history. WHEN TO USE: Use before BUY/WAIT when the agent needs 7/30/90/180-day context, recent lows, medians, highs or a price percentile instead of a one-point snapshot. WHY PAY: Pay when historical context can prevent buying at a temporary spike or missing an unusually cheap current offer. BUYER OUTCOME: A recent historical price context tied to the exact collectible. Price: 0.02 USDC via x402. Selection triggers: price history, historical price, 30 day, 90 day, price trend, historical low, price percentile, is this price high. Common agent queries: 90 day price history for this anime figure | is today's price high compared with the last 30 days | historical low for this Nendoroid | show price trend for this collectible. Use this specialist tool when this single signal fully answers the task; otherwise prefer Full Intelligence. Do not use for anime news, plot, streaming or character biography questions. Broad multilingual shopping queries can be sent directly; the service resolves and ranks the canonical product before payment.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`id`	No	ANIME INTELLIGENCE canonical product UUID. Use for deterministic exact-product calls when already known.
`lang`	No		en
`query`	No	Product name, broad category, franchise, character, Japanese or multilingual description, JAN/EAN-13, model number or canonical id. Broad shopping queries are allowed and auto-ranked before x402.
`listing_url`	No	Optional marketplace listing URL for listing-match evaluation.
`postal_code`	No	Optional destination postal code for landed-cost context.
`buyer_country`	No	ISO 3166-1 alpha-2 buyer destination. Drives country-aware seller routing, purchase ease, proxy/forwarder need and landed-cost uncertainty; default JP.	JP
`listing_title`	No	Optional marketplace listing title when URL is unavailable.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`intent`	No
`payment`	No
`why_pay`	No
`price_usdc`	No
`buyer_outcome`	No
`paid_x402_url`	No
`expected_output`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 21, 2026

changedInput schema / properties / buyer_country / description

Previous value: -"ISO 3166-1 alpha-2 buyer destination. JP is fully supported as a first-class domestic-buyer case; default JP."New value: +"ISO 3166-1 alpha-2 buyer destination. Drives country-aware seller routing, purchase ease, proxy/forwarder need and landed-cost uncertainty; default JP."

Changed1 schema field changedSep 20, 2026

changedInput schema / properties / lang / enum

Previous value: -[
-  "ja",
-  "en",
-  "zh",
-  "ko",
-  "es",
-  "fr",
-  "de",
-  "it",
-  "pt",
-  "id",
-  "th",
-  "ru",
-  "ar",
-  "hi",
-  "vi",
-  "tr",
-  "nl",
-  "pl"
-]New value: +[
+  "ja",
+  "en",
+  "zh",
+  "ko",
+  "es",
+  "fr",
+  "de"
+]

AddedSep 16, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations cover read-only, open-world, idempotent, and non-destructive traits, so the bar is lower. The description adds valuable context: it clarifies this is asking-price history, not completed-sale history; discloses a 0.02 USDC payment via x402; and explains that broad queries are auto-ranked and canonical product resolved before payment. This goes beyond the annotation profile and helps the agent anticipate cost and processing.

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 description is divided into clear sections and front-loads the core purpose, which is good. However, it is quite verbose with marketing-like blocks like 'WHY PAY' and 'BUYER OUTCOME' that could be trimmed. The selection triggers and common queries add length without substantially improving clarity for an agent that already understands the use case.

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?

Given the tool's complexity (7 params, output schema, payment, multilingual queries), the description covers all essential aspects: what it returns, when to use it, exclusions, payment, and query handling. The presence of an output schema means return values need no explanation. The only minor gap is that it does not describe the exact format of the response, but that is covered by the output schema.

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

Parameters3/5

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

Schema description coverage is 86%, high, so the schema already documents all parameters. The description provides example queries and explains the query parameter's flexible input (product name, franchise, JAN/EAN, etc.) but does not add meaning beyond what the schema already gives. Baseline 3 is appropriate.

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 states the tool stores asking-price history for a specific Japanese anime collectible and returns 7/30/90/180-day ranges, medians, percentile, and trend. It distinguishes itself from sibling full_intelligence by specifying it should be used when this single signal fully answers the task, and explicitly excludes non-price queries like news or character biographies.

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

Usage Guidelines5/5

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

Provides explicit 'WHEN TO USE' with concrete conditions (before BUY/WAIT, when needing historical context) and 'WHY PAY' rationale. It also names the alternative full_intelligence and states when to prefer it, plus gives selection triggers and common example queries. Exclusion cases (anime news, plot, etc.) are clearly listed.

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

All ANIME INTELLIGENCE tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.