ANIME INTELLIGENCE

ANIME INTELLIGENCE - Preorder Lottery and Purchase Deadline

purchase_deadline

Read-onlyIdempotent

Purchase-window intelligence for Japanese anime collectibles. Returns stored verified preorder, lottery, reservation or sales deadlines when available, with remaining time and a separate release schedule so agents do not confuse release dates with order cutoffs. WHEN TO USE: Use when an agent could lose the purchase opportunity by waiting: preorder closing, lottery entry closing, limited-order end or sales-end timing. WHY PAY: Pay when missing a verified order window can eliminate the purchase opportunity. Unknown deadlines are explicitly returned as unknown rather than inferred from release dates. BUYER OUTCOME: A clear deadline/open-status answer with no fabricated timing. Price: 0.01 USDC via x402. Selection triggers: deadline, preorder closes, lottery ends, reservation deadline, order window, sales end, how long left. Common agent queries: when does preorder close for this anime figure | how long is left to enter this Japanese lottery sale | is the limited order window still open | purchase deadline 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.6/5.0

Behavior5/5

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

Even with readOnly/openWorld/idempotent annotations, the description adds valuable behavioral context: it explicitly says unknown deadlines are returned as unknown rather than inferred from release dates, that release dates are kept separate from order cutoffs, that timing is never fabricated, and that payment is 0.01 USDC via x402. These details go well beyond the annotations.

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 longer than average but well-structured with labeled sections, front-loaded purpose, and practical query examples. Some redundancy exists between 'WHY PAY' and the later price line, but the structure aids an agent in quickly extracting when and why to call the tool.

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 an output schema exists and the description covers selection triggers, exclusion cases, payment, unknown-deadline behavior, and alternatives, nothing essential is missing for an agent deciding whether and how to invoke this tool. It even addresses multilingual shopping queries and payment ordering.

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 high at 86%, so the schema already documents most parameters, including query, id, lang, and buyer_country. The tool description mostly repeats query-level behavior already present in the schema, such as allowing broad shopping queries and auto-ranking before x402. It adds little new meaning per-parameter beyond what the input schema provides.

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 opens with a specific verb+resource: 'Purchase-window intelligence for Japanese anime collectibles' and explicitly enumerates the kinds of deadlines covered (preorder, lottery, reservation, sales). It differentiates itself from siblings by stating it is a 'specialist tool' that answers a single signal and directing agents to prefer Full Intelligence otherwise.

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 contains an explicit 'WHEN TO USE' section listing concrete trigger scenarios, a 'WHY PAY' rationale, and a clear exclusion: 'Do not use for anime news, plot, streaming or character biography questions.' It also names the alternative (Full Intelligence) and gives the condition for choosing this tool over 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.