ANIME INTELLIGENCE

ANIME INTELLIGENCE - Verify Listing Matches Exact Anime Collectible

listing_match

Read-onlyIdempotent

Verify whether a seller listing matches the exact Japanese anime collectible, edition or variant. Uses canonical identity, JAN/model evidence and stored marketplace match signals to detect wrong-version and name-collision risk. WHEN TO USE: Use immediately before purchase when the agent has a seller listing and identity mismatch could cause a bad order. A listing URL or title can be supplied; otherwise the service returns the strongest currently observed matched listings. WHY PAY: Pay before purchase when a wrong edition, rerelease or similarly named item would make the transaction incorrect even if the price looks attractive. BUYER OUTCOME: A listing-to-canonical match verdict that reduces wrong-item purchases. Price: 0.01 USDC via x402. Selection triggers: same product, same edition, does this listing match, correct version, wrong version, listing match, edition match. Common agent queries: does this listing match the exact anime figure edition | verify this eBay listing is the correct Nendoroid | is this Yahoo listing the same Japanese collectible | check wrong version risk before I buy. 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.6/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds meaningful behavioral context: it costs 0.01 USDC via x402, auto-ranks canonical product before payment, and falls back to returning the strongest observed matched listings when no URL/title is supplied. This goes beyond the annotations without contradicting them.

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?

The description is front-loaded with the core purpose and uses labeled sections (WHEN TO USE, WHY PAY, BUYER OUTCOME, selection triggers) for scannability. It is somewhat verbose and repeats the purchase context across sections, but each section still adds routing or behavioral value.

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 tool's complexity, the description covers input modes, payment expectation, fallback behavior, exclusions, and sibling differentiation. With an output schema present, it does not need to explain return values; the agent has everything needed to decide and invoke correctly.

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?

Schema coverage is 86%, so the baseline is 3. The description adds value by explaining that a listing URL or title may be supplied and that otherwise the service returns observed matches, and by clarifying that broad multilingual shopping queries are accepted and auto-ranked. This supplements the already-rich schema descriptions without duplicating them.

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 names a specific verb and resource: 'Verify whether a seller listing matches the exact Japanese anime collectible, edition or variant.' It clearly signals the tool's niche—listing-to-canonical match verification—and differentiates it from sibling tools like identify_anime_product and full_intelligence by focusing on wrong-version and name-collision risk.

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?

The description explicitly says 'Use immediately before purchase' and gives the selection triggers: same product, same edition, does this listing match, correct version, wrong version. It also states exclusions ('Do not use for anime news, plot, streaming or character biography questions') and names the alternative ('otherwise prefer Full Intelligence'), leaving no ambiguity about when to invoke it.

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.