What can you do with this server?

LitVM TCG Oracle is an MCP server that gives AI agents access to verified trading card market data with on-chain cryptographic proofs across 25+ games (Pokémon, Magic: The Gathering, Yu-Gi-Oh!, One Piece, Disney Lorcana, and more). * Search trading cards: Full-text search across 440K+ TCG products, returning product IDs, names, games, and current market prices. * Get current & historical prices: Retrieve market price, low/buy-it-now price, and up to 365 days of daily price history for any card by name or product ID. * Verify prices on-chain: Obtain cryptographic Merkle proofs for trustless, on-chain verification of prices against the LitVM LiteForge blockchain — no blind trust required. * Monitor oracle status: Read live, un-cached on-chain data (Merkle root freshness, TWAP update counts, database statistics) directly from the LiteForge blockchain (Chain ID 4441). * Conformal risk forecasts: Get calibrated, distribution-free price forecasts with 50%/90% bands, VaR 95/99, Safe-Hold/Momentum letter grades, and a plain-English summary. * Monte Carlo simulations: Run stochastic price simulations (Geometric Brownian Motion or Merton Jump-Diffusion) calibrated from real market data, returning percentile bands, VaR, and CVaR metrics. * Market snapshots: View the top highest-value cards for any supported game, sorted by current market price. * AI agent integration: Connect easily with Claude, GPT, Cursor, and VS Code via the Model Context Protocol (MCP) using a single URL or local installation.

Which integrations are available for this server?

Provides on-chain verification of trading card prices against the LitecoinVM blockchain, enabling AI agents to cryptographically prove price integrity via Merkle proofs.

litvm-tcg-oracle

by sailorpepe

Overview Schema Related Servers Score Discussions

Python

Remote

Browse 446K+ cards with on-chain verified prices

🔌 Connect over MCP — one URL, no install

https://mcp.the-undesirables.com

No install, no account, no API key. 12 tools over streamable HTTP (MCP protocol 2025-06-18; legacy SSE also served). Free tools answer immediately. Paid tools return an x402 payment_required carrying amount, network, and payTo — an agent with a funded wallet can settle and retry in the same session. Settlement only occurs on a successful response; failed calls are never charged.

Claude Desktop / Perplexity — add it as a custom remote connector (Perplexity: Settings → Connectors → + Custom Connector → Remote).

Cursor / Windsurf / VS Code — clients that take a URL in config:

{
  "mcpServers": {
    "tcg-oracle": { "url": "https://mcp.the-undesirables.com" }
  }
}

Tools: search_tcg_products, market_snapshot, grade_card, grade_or_not, simulate_price, card_forecast, trending_cards, optimize_portfolio, recommend_workflow, check_accuracy.

Search is set-aware — search_tcg_products("Base Set Charizard") separates Base Set, Base Set 2, and Shadowless rather than returning every Charizard printing. Every result carries a set field and a product_id you can pass straight to the other tools.

Related MCP server: Sports Trading Card Agent

📑 Table of Contents

Why This Exists

AI agents are making decisions with market data — but how do they know the data is real?

Regular APIs require trust. You call an endpoint, you get a number, and you hope it's accurate. There's no way to verify it. For AI agents managing portfolios, executing trades, or assessing collateral, this is a problem.

This MCP server solves it. Every actively-priced product in the oracle is committed to a Merkle root on-chain hourly. Any agent can request a Merkle proof for any card and independently verify the price against the LitVM LiteForge blockchain — no trust required.

What Makes This Different

Feature	Regular Price API	LitVM TCG Oracle
Data source	Opaque server	13.5M+ verified market observations
Verification	Trust the server	Merkle proof → on-chain verification
Forecasting	None	Calibrated conformal risk forecast — honest VaR
Coverage	Limited	446K products, 284K actively priced
For AI agents	Manual integration	MCP — works in Claude, GPT, Cursor
Blockchain	None	LitVM LiteForge

Data Coverage

The oracle indexes the full TCGPlayer catalog and tracks live market prices:

Metric	Count	Description
Total catalog	446,694	All products across 25+ games and 85 categories
Actively priced	276,788	Products with a current `market_price > 0`
Price observations	13.5M+	Daily snapshots collected over months
Merkle-provable	276,788	Only actively-priced products are committed on-chain
Zero-price entries	~157K	Tokens, promos, bundles, foreign-market-only — searchable but not provable

Transparency note: Not every product in the catalog has a market price. ~157K entries are catalog metadata with no trading activity (token cards, unopened case listings, foreign-language promos, etc.). These are returned by search_cards but will return a 404 from get_merkle_proof because zero-price products are not committed to the Merkle tree. This is by design — you wouldn't commit unverifiable data on-chain.

Quick Start

Install

pip install litvm-tcg-oracle

For live on-chain contract reads (optional):

pip install litvm-tcg-oracle[chain]

Claude Desktop

Add to ~/.claude/claude_desktop_config.json:

{
  "mcpServers": {
    "litvm-tcg-oracle": {
      "command": "litvm-tcg-oracle"
    }
  }
}

Cursor / VS Code

Add to your MCP settings:

{
  "litvm-tcg-oracle": {
    "command": "litvm-tcg-oracle"
  }
}

Then ask your AI: "Search for Charizard Base Set and simulate the price over 90 days"

Tools

1. `search_cards` — Full-Text Search

Search the full 446K product catalog using FTS5 full-text search.

→ search_cards(query="black lotus", game="Magic", limit=5)

Covers 25+ games including: Pokémon, Magic: The Gathering, Yu-Gi-Oh!, One Piece, Disney Lorcana, Flesh & Blood, Dragon Ball Super, Digimon, Star Wars, Union Arena, MetaZoo, Cardfight Vanguard, My Hero Academia.

Returns product IDs needed for get_price and get_merkle_proof.

2. `get_price` — Price + History

Get current market price and daily price history for any card.

→ get_price(card_name="Charizard Base Set Holo", days=90)

Returns market price, low (buy-it-now) price, and a daily price array. This history is what powers the risk-forecast calibration — the same data the forecast engine uses to calculate drift, volatility, and conformal bands.

3. `get_merkle_proof` — On-Chain Verification

This is the key differentiator. Get a cryptographic proof that a card's price was committed to the LitVM LiteForge blockchain.

→ get_merkle_proof(product_id=84198)

Returns a bytes32[] proof array (19 hashes for the current tree) that can be submitted to the MerklePriceOracle contract on LitVM LiteForge to verify the price without trusting any server.

Verification flow:

Call get_merkle_proof(product_id) → receive proof + leaf data
Submit to MerklePriceOracle.verifyPrice() on LitVM LiteForge
Contract checks the leaf against the committed Merkle root
Returns true if and only if the price matches exactly

Leaf encoding (matches Solidity):

keccak256(bytes.concat(keccak256(abi.encode(
  productId, categoryId, name, marketPrice, lowPrice
))))

Standard: OpenZeppelin MerkleProof (double-hash, sorted pairs)

Only the 284K actively-priced products are in the Merkle tree. Zero-price catalog entries return a 404 — this is correct behavior.

4. `oracle_status` — Live On-Chain Status

Reads directly from the LitVM LiteForge blockchain via Caldera RPC — not cached data.

→ oracle_status()

Returns:

MerklePriceOracle: Merkle root, total products, freshness, total root updates
TCGPriceOracleV2: Total TWAP updates, last update timestamp, 660+ confirmed updates
Database: Card count, price rows, latest data date

5. `get_forecast` — Conformal Risk Forecast

The recommended, honest default forecast. Distribution-free, deterministic, never-under-protective — calibrated on real cross-card price history, no distributional assumption.

→ get_forecast(card_name="Charizard Base Set Holo")

Returns the agent-complete forecast: price, as_of, regime, point estimate, expected 30-day move, prob_up, 50%/90% bands, VaR 95/99, a Safe-Hold grade (downside / capital preservation), a Momentum grade (direction — or "NA" on a recent drift spike), and a one-line plain_english read.

Why conformal? Honest VaR: out-of-sample, a "5% VaR" means a ~5% loss happens about 5% of the time. No Monte Carlo, fully deterministic, anyone can reproduce it. Calls the free /api/v1/forecast/{product_id} endpoint.

6. `simulate_price` — Monte Carlo Simulation

An opt-in stochastic view — Monte Carlo price paths (Merton/GBM) calibrated from real market data. Use get_forecast for the honest default.

→ simulate_price(card_name="Charizard Base Set", days=30, model="merton")

How the Simulation Works

This is not placeholder math. Every simulation parameter is calibrated from real price observations stored in the oracle database.

Calibration Pipeline:

Card name → FTS5 search → product_id → price_history (up to 365 days)
  → weekly resampling (ISO week buckets)
  → log-returns between weekly closing prices
  → annualized drift (μ) and volatility (σ)
  → jump detection via 2σ threshold on time-scaled returns
  → 10,000 vectorized numpy simulation paths
  → percentile forecast bands + VaR/CVaR risk metrics

Why weekly resampling? Daily TCG prices have irregular gaps (weekends, holidays, no sales). Weekly resampling produces stable drift estimates by collapsing daily observations into ISO-week buckets and computing log-returns between weekly closing prices. This eliminates the √Δt scaling problem that plagues irregularly-spaced data.

Models (pass via model=, default merton):

For the calibrated conformal forecast (honest VaR + Safe-Hold/Momentum grades), use get_forecast above. The two models below are the stochastic Monte Carlo alternatives.

Geometric Brownian Motion (GBM)

dS = μ·S·dt + σ·S·dW

Standard log-normal diffusion — the foundation of Black-Scholes option pricing. Assumes continuous price movements with no sudden jumps.

Merton Jump-Diffusion (default)

dS = (μ − λk)·S·dt + σ·S·dW + J·S·dN

Extends GBM by adding Poisson-distributed price jumps to capture sudden market events — buyouts, influencer videos, ban lists, set reprints, tournament results.

Symbol	Meaning	Calibration
`μ`	Drift (annualized return)	Weekly log-return mean × 52
`σ`	Volatility	Weekly log-return stdev × √52
`λ`	Jump intensity (jumps/year)	Count of returns > 2σ, annualized
`μⱼ`	Jump mean	Average of detected jump returns
`σⱼ`	Jump volatility	Stdev of detected jump returns
`k`	Drift compensator	`E[eᴶ] - 1` (ensures fair pricing)
`dW`	Brownian motion	Standard Wiener process
`dN`	Jump arrival	Poisson(λ·dt)

Risk Metrics:

VaR 95%: "There is a 5% chance the price drops below $X over N days"
CVaR 95% (Expected Shortfall): "If that tail event occurs, the average loss lands at $Y"

Transparency:

param_source: "calibrated_from_market_data" — real parameters from this card's history
param_source: "default_tcg_priors" — insufficient data (<5 points), using conservative priors (3% drift, 40% vol)
Standard errors reported for μ, σ, λ to quantify parameter uncertainty
Mean-reversion detection via lag-1 autocorrelation

References:

Merton, R.C. (1976). Option pricing when underlying stock returns are discontinuous. Journal of Financial Economics, 3(1-2), 125-144.
Black, F. & Scholes, M. (1973). The Pricing of Options and Corporate Liabilities. Journal of Political Economy, 81(3), 637-654.

6. `get_market_snapshot` — Market Overview

Top cards by value for any game.

→ get_market_snapshot(game="Pokemon", limit=25)

Architecture

┌──────────────────┐       MCP (stdio)       ┌──────────────────────┐
│                  │ ◄─────────────────────► │                      │
│    AI Agent      │                          │  litvm-tcg-oracle    │
│  (Claude, GPT,   │                          │  MCP Server          │
│   Cursor, etc.)  │                          │  (pip install)       │
│                  │                          │                      │
└──────────────────┘                          └──────┬───────┬───────┘
                                                     │       │
                                          HTTPS      │       │  RPC
                                                     │       │
                                                     ▼       ▼
                                     ┌──────────────────┐  ┌─────────────┐
                                     │  Oracle REST API │  │  LitVM LiteForge  │
                                     │  (Mac Mini)      │  │  LitVM LiteForge │
                                     │                  │  │             │
                                     │  446K products   │  │  Merkle +   │
                                     │  13.5M prices    │  │  V2 Oracle  │
                                     │  FTS5 search     │  │  contracts  │
                                     └──────────────────┘  └─────────────┘

Off-chain layer (REST API): Search, prices, market data, simulation calibration
On-chain layer (LitVM LiteForge RPC): Merkle root verification, oracle contract status, TWAP feeds

The Mac Mini runs the daily pipeline (scrape → price update → Merkle root → on-chain push) and serves the REST API. The MCP server is a thin client that any developer can pip install and connect to Claude, GPT, or Cursor.

Configuration

Variable	Default	Description
`LITVM_ORACLE_URL`	`https://oracle.the-undesirables.com`	Override the API base URL

Local Development

export LITVM_ORACLE_URL=http://localhost:8402
litvm-tcg-oracle

On-Chain Contracts

Contract	Address	Purpose
MerklePriceOracle	`0x96B124...170Cd`	Hourly Merkle root for 284K products
TCGPriceOracleV2	`0x697bF6...720E`	Hourly TWAP for top 50 blue-chip cards

Both contracts are deployed on LitVM LiteForge testnet (Chain ID 4441) via the Caldera RPC.

📝 License & Commercial Use

This project is licensed under the Business Source License 1.1 (BUSL-1.1).

We build in public and support the developer ecosystem — but we also protect the infrastructure and IP of The Undesirables LLC.

✅ What You CAN Do (Free)

Personal & Educational Use — Download, modify, and run locally for learning, research, or personal projects.
Non-Competing Applications — Integrate this MCP server into your app, provided your app does not offer TCG market intelligence, pricing aggregation, AI card grading, or on-chain price oracle services as its primary function.
MCP / Agent Integration — Connect your AI agent to this server for non-commercial use.
Community Contributions — Security audits, bug fixes, and PRs are always welcome.

🚫 What You CANNOT Do (Use Limitation)

Competing Oracle — You may not use this code to operate a competing price oracle service on LitVM LiteForge or any compatible chain.
Commercial Resale — You may not wrap our API, data pipelines, or AI models into a paid service without a commercial license.
Hosted SaaS — You may not host this software as a service for third parties without written permission.

🔓 Open-Source Conversion

On June 1, 2030 (or 4 years after the first public release of each version), this code automatically converts to the MIT License — fully open source, forever.

🤝 Commercial Licensing

Building a commercial product? Want guaranteed API access or white-label integration? Contact us:

📧 theundesirables7@gmail.com · 🐦 @undesirables_ai

Available Tools

7 tools

get_forecastA

Get the calibrated conformal risk forecast for a trading card.

This is the recommended, honest default forecast — distribution-free, deterministic, and never-under-protective. Unlike a Monte Carlo simulation it makes NO distributional assumption: the bands are calibrated on real cross-card price history, so the stated risk is honest out-of-sample (a "5% VaR" means a ~5% loss happens about 5% of the time). Each card also gets two plain-English letter grades.

ParametersJSON Schema

Name	Required	Description	Default
`card_name`	Yes	Card to forecast (e.g. "Charizard Base Set Holo")

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/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 full burden. It discloses that the forecast is distribution-free, deterministic, never-under-protective, and that risk values are honest out-of-sample. It also mentions 'two plain-English letter grades.' However, it could be more explicit about side effects or return behavior beyond the grade mention.

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 concise (~100 words) and front-loaded with the main purpose. Every sentence adds value, distinguishing the tool and its methodology without waste.

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 one parameter and the existence of an output schema, the description is fairly complete. It explains methodology and key traits, but could briefly mention what the output schema covers to enhance completeness.

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?

The schema has 100% description coverage for the single parameter 'card_name'. The description does not add additional meaning beyond the schema's example. Baseline score 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 'Get the calibrated conformal risk forecast for a trading card.' This is a specific verb+resource. It distinguishes from siblings like 'simulate_price' by explicitly contrasting with Monte Carlo simulation and positioning itself as the 'honest default forecast.'

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 provides implied usage guidance by calling it the 'recommended, honest default forecast' and contrasting with Monte Carlo simulation. It explains why it's distribution-free and never-under-protective, helping the agent understand when to prefer this tool, but does not explicitly state when not to use it or name specific alternatives.

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

get_market_snapshotA

Get a market overview — top trading cards sorted by value.

Returns the highest-value cards for a specific game with current market prices and low (buy-it-now) prices.

Games: Pokemon, Magic, Yu-Gi-Oh, One Piece, Disney Lorcana, Flesh and Blood, Dragon Ball Super, Digimon, Star Wars, Union Arena, MetaZoo, Cardfight Vanguard, My Hero Academia.

ParametersJSON Schema

Name	Required	Description	Default
`game`	No	Game name (default "Pokemon")	Pokemon
`limit`	No	Number of cards to return (1-50, default 25)

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

No annotations are provided, but the description fully discloses that the tool returns highest-value cards with current market and low prices. No hidden side effects are mentioned, and the read-only behavior is evident.

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?

Description is four sentences, front-loaded with the core purpose, and each sentence adds essential information without redundancy. Extremely efficient.

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 simplicity, the description covers the main functionality. An output schema exists (not shown) so return format details are not required. Minor gap: does not explicitly state descending sort order for 'sorted by value', but it's reasonably implied.

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 100%, providing baseline 3. The description adds value by clarifying that 'game' filters by game name and 'limit' controls number of cards, plus the output is sorted by value with price details—beyond the schema's concise descriptions.

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 it retrieves a market overview of top trading cards sorted by value for a specific game, listing supported games. This distinctively differentiates from sibling tools like get_price (single card) and search_cards (search).

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

Usage Guidelines3/5

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

The description implies usage for obtaining a high-level market snapshot, but does not explicitly state when to prefer this tool over alternatives or provide any usage restrictions.

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

get_merkle_proofA

Get a Merkle proof for on-chain price verification on LitecoinVM.

WHY THIS MATTERS FOR AI AGENTS: Regular API prices require trusting the server. Merkle proofs let you VERIFY the price on-chain without trusting anyone. The proof is a cryptographic guarantee that this exact price was committed to the LitecoinVM blockchain by the oracle operator.

The TCG Price Oracle commits 276K actively-priced products to a single Merkle root on LiteForge daily. This tool returns the proof array that can be submitted to the MerklePriceOracle smart contract to trustlessly verify any card's price.

NOTE: Only actively-priced products (market_price > 0) are included in the Merkle tree. Zero-price catalog entries cannot be proven.

ParametersJSON Schema

Name	Required	Description	Default
`product_id`	Yes	TCGPlayer product ID (e.g. 98580 for Shadowless Charizard)

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations, the description fully discloses behavioral traits: it returns a Merkle proof array, only works for actively-priced products (market_price > 0), and zero-price entries cannot be proven. It also explains the overall mechanism (Merkle root on LiteForge).

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 well-structured with sections, front-loading the purpose. While slightly verbose, every sentence adds value (e.g., why it matters, the oracle process, the zero-price note). It could be tightened but remains effective.

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 presence of an output schema (not shown but indicated), the description still provides essential context about what the tool returns (Merkle proof array) and its application. It also covers limitations (zero-price items) and the overall workflow, making it complete for an AI agent.

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 100% with a single parameter (product_id) described as 'TCGPlayer product ID.' The description adds a concrete example ('e.g. 98580 for Shadowless Charizard') and explains the role of the parameter in verification, adding value beyond the schema.

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 starts with 'Get a Merkle proof for on-chain price verification on LitecoinVM,' clearly stating the specific verb and resource. It distinguishes this tool from siblings like get_price by emphasizing cryptographic verification versus trusting a server.

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 explains when to use this tool (to verify prices on-chain without trusting a server) and provides context about the underlying oracle. It does not explicitly mention alternative tools or when not to use it, but the context implies other tools (like get_price) for trusted scenarios.

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

get_priceA

Get the latest market price and historical price data for a trading card.

Provide either a card name (fuzzy search) or a TCGPlayer product ID. Returns current market price, low (buy-it-now) price, and daily price history for the requested time window.

The price history is what powers the Monte Carlo simulation — it's the same data used to calibrate drift and volatility parameters.

ParametersJSON Schema

Name	Required	Description
`days`	No	Days of price history to include (1-365, default 30)
`card_name`	No	Card name to search (e.g. "Charizard Base Set Holo")
`product_id`	No	TCGPlayer product ID for exact lookup (e.g. 98580)

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior4/5

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

No annotations exist, so the description carries full weight. It discloses returns (current, low, history) and notes the data powers Monte Carlo simulation. While rate limits and error handling are omitted, the output schema covers return format, making this sufficient.

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 purpose and input options. The Monte Carlo sentence adds context but could be trimmed; it remains acceptable without being overly verbose.

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?

The tool has low complexity with an output schema. The description covers main outputs and input options. It does not mention pagination or prerequisites (e.g., using search_cards to find product IDs), but for a straightforward price tool, it is largely complete.

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 100%, but the description adds critical context: the exclusive-or relationship between card_name and product_id, and that card_name uses fuzzy search. This goes beyond the schema's individual parameter descriptions.

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 clearly states the tool gets 'the latest market price and historical price data for a trading card,' with specific verbs and resources. It distinguishes from siblings like search_cards (search vs get) and simulate_price (simulation), but does not explicitly differentiate from get_market_snapshot.

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

Usage Guidelines3/5

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

The description implies use when needing price data for a card and specifies input options (card name or product ID). It does not provide explicit when-not-to-use guidance or alternatives like search_cards for finding product IDs.

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

oracle_statusA

Get live status of the TCG Price Oracle on LitecoinVM.

Reads DIRECTLY from the LiteForge blockchain (Chain ID 4441) via the Caldera RPC endpoint — this is NOT cached data, it's a live on-chain read at the moment you call it.

Returns: • MerklePriceOracle: current root, total products, freshness, update count • TCGPriceOracleV2: total TWAP updates, last update timestamp • Network: connection status, chain ID, RPC URL, explorer link • Database: card count, price rows, latest data date (from API)

No arguments required.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It clearly states it performs a live on-chain read via Caldera RPC, not cached data, and lists return fields. However, it omits potential behavior like latency or endpoint reliability.

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 well-structured with clear sections for purpose, behavior, and returns. It is fairly concise for the depth provided, though slightly verbose in listing return fields.

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 has no params and an output schema exists, the description adequately covers the use case. It explains the live nature and return fields, but could mention error handling or edge cases.

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

Parameters5/5

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

No parameters exist, so baseline is 4. The description adds significant value by detailing the four return categories (MerklePriceOracle, TCGPriceOracleV2, Network, Database), which is beyond the empty input schema.

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 explicitly states 'Get live status of the TCG Price Oracle on LitecoinVM,' providing a specific verb and resource. It distinguishes from siblings like get_price or get_market_snapshot by focusing on overall oracle health.

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

Usage Guidelines3/5

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

The description implies usage for obtaining live on-chain oracle status, but lacks explicit guidance on when to use this tool versus alternatives (e.g., get_price for individual prices). No exclusions or alternative recommendations are provided.

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

search_cardsA

Search 433K+ trading card products by name using full-text search.

The catalog contains 433K products total — 276K are actively priced with current market data. ~157K are catalog-only entries (tokens, promos, bundles) with no price history. Disney Lorcana, Flesh & Blood, Dragon Ball Super, Digimon, Star Wars, Union Arena, MetaZoo, Cardfight Vanguard, and My Hero Academia.

Returns product IDs (needed for get_price and get_merkle_proof), card names, games, and current market prices.

ParametersJSON Schema

Name	Required	Description
`game`	No	Optional game filter (e.g. "Pokemon", "Magic", "Yu-Gi-Oh")
`limit`	No	Number of results (1-50, default 10)
`query`	Yes	Search term (e.g. "charizard base set", "black lotus", "luffy")

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior4/5

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

Without annotations, the description carries full burden. It discloses catalog size, active vs. catalog-only entries, and the return of product IDs. It implies a safe read operation but does not explicitly state nondestructive nature.

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 well-structured and front-loaded with the main purpose. It contains useful details but could be slightly more concise without losing information.

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 (search over 433K items), the description provides good context: catalog size, games, and return value usage. Output schema exists, so return values are handled. Minor gap: missing detail on search behavior (e.g., fuzzy matching).

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 coverage is 100% and schema descriptions are present. The description adds example search terms and mentions game filter but does not significantly enhance parameter understanding beyond the schema.

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 'Search 433K+ trading card products by name using full-text search' and lists specific games and what is returned. It distinguishes from siblings by noting that product IDs are needed for get_price and get_merkle_proof.

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 implicitly guides usage by stating it returns product IDs for other tools and mentions catalog details. However, it lacks explicit when-not-to-use or alternative guidance beyond the sibling list.

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

simulate_priceA

Run a Monte Carlo price simulation for a trading card (opt-in).

For the honest DEFAULT forecast — conformal VaR + Safe-Hold/Momentum grades — use get_forecast. This tool is the stochastic Monte Carlo alternative (Merton/GBM).

HOW THE MATH WORKS: This is NOT fake data. The simulation calibrates parameters from REAL market prices stored in the oracle database (12.7M+ price observations):

Look up the card → get product_id via FTS5 search
Pull up to 365 days of daily price history
Resample to weekly buckets for stable drift estimates
Compute annualized drift (μ) and volatility (σ)
Detect price jumps via 2σ threshold on time-scaled returns
Run 10,000+ vectorized numpy simulation paths
Return percentile forecast bands + risk metrics

If insufficient price history exists (<5 data points), conservative TCG market priors are used (3% drift, 40% vol) and clearly labeled as "default_tcg_priors" in the response.

ParametersJSON Schema

Name	Required	Description	Default
`days`	No	Forecast horizon in days (1-365, default 30)
`model`	No	"gbm" or "merton" (default "merton")	merton
`card_name`	Yes	Card to simulate (e.g. "Charizard Base Set Holo")
`simulations`	No	Number of Monte Carlo paths (100-50000, default 10000)

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

Behavior4/5

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

No annotations exist, so the description fully bears the transparency burden. It explains the math, data sources, calibration steps, and fallback priors in detail. However, it does not explicitly state if the tool is purely read-only or mention potential side effects, but the nature of simulation implies safety. Could also disclose rate limits or data freshness.

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 lengthy but well-structured with bullet points and clear sections. It efficiently explains a complex process without unnecessary fluff. Slightly verbose, but every sentence adds value for the intended technical audience.

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 complexity of Monte Carlo simulation, the description covers data source, calibration steps, fallback behavior, and output expectations. It references a sibling tool for default forecasting, setting complete context. With an output schema likely present, this description is fully adequate.

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?

Input schema covers all 4 parameters with descriptions, achieving 100% coverage. The description adds context like 'vectorized numpy simulation paths' and 'percentile forecast bands' that enrich understanding beyond schema, but does not introduce new parameter constraints not already in schema.

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 runs a Monte Carlo price simulation for trading cards, using specific verbs and resource. It distinguishes itself from the sibling 'get_forecast' by positioning as the stochastic Monte Carlo alternative, making the purpose unmistakable.

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?

Explicitly tells when to use this tool vs 'get_forecast': 'For the honest DEFAULT forecast... use get_forecast. This tool is the stochastic Monte Carlo alternative.' It also mentions opt-in, providing clear guidance on tool selection.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Disambiguation5/5

Each tool has a distinct purpose: search_cards for discovery, get_price for pricing, simulate_price for simulation, get_market_snapshot for overview, get_merkle_proof for verification, and oracle_status for system health. No overlap or ambiguity.

Naming Consistency4/5

Most tools follow a consistent verb_noun pattern like get_price, search_cards, simulate_price. However, oracle_status is a noun_noun pattern and doesn't start with a verb, which is a minor inconsistency.

Tool Count5/5

With 6 tools, the server is well-scoped for a TCG price oracle. Each tool serves a necessary function without redundancy, and the count is appropriate for the domain.

Completeness5/5

The tool surface covers all essential operations for a price oracle: card search, price retrieval, market overview, price simulation, on-chain verification, and system status. No obvious gaps.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

tcgmcp A
com.tcgmcp
Live TCG card and decklist prices for AI assistants. 22+ games, no account, ready-to-buy links.
E-commerce & Retail Finance Games & Gamification
42
cardmind-mcp
io.github.nath-abhishek
MTG market data: search 114K+ cards, price signals, AI analysis. Free tier available.
Games & Gamification Search AI & Machine Learning
2
oracle A
com.dropwatchhq
MCP tools: collectible price-fairness, recall safety, drop tracking, card grading, settlements.
E-commerce & Retail Finance
52
LowlandData TCG Prices
io.github.AdrienHq
Daily EU card prices, deal detection and EU-vs-US arbitrage for 19 trading card games.
Games & Gamification E-commerce & Retail Finance
1

Related MCP Servers

Blockchain MCP Server
Blockchain Web3 & Decentralized Tech
lienhage
A
license
B
quality
D
maintenance
A Model Context Protocol server providing Ethereum blockchain tools, including vanity address generation and Cast command functionality for interacting with Ethereum networks through natural language.
Updated a year ago (2025-06-30 03:54 UTC)
14
27
MIT
Sports Trading Card Agent
Sports Finance Research & Data
rjexile
A
license
A
quality
D
maintenance
Real-time sports card pricing, market analysis, arbitrage detection, grading ROI, investment advice, and player stats (NBA/NFL/MLB). 9 tools for AI agents helping collectors and investors.
Updated 5 months ago (2026-03-24 22:25 UTC)
9
2
MIT
undesirables-mcp-server
AI & Machine Learning Image & Video Processing Cryptocurrency
sailorpepe
A
license
B
quality
A
maintenance
35+ tool MCP server for TCG collectibles and AI agents. Vision AI card grading (PSA/Beckett), Monte Carlo price simulation, AI music generation, local image generation, TTS, RAG memory, and financial analytics — all running 100% locally with zero telemetry.
Updated 23 days ago (2026-08-11 19:42 UTC)
36
2
Business Source 1.1
mcp-ygoprodeck
Games & Gamification Search
pipeworx-io
A
license
Not graded
quality
C
maintenance
Enables querying Yu-Gi-Oh! TCG card data, such as card information, sets, and prices, through natural language.
Updated 8 days ago (2026-08-26 17:51 UTC)
19
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sailorpepe/litvm-tcg-oracle-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

🔌 Connect over MCP — one URL, no install

📑 Table of Contents

Why This Exists

What Makes This Different

Data Coverage

Quick Start

Install

Claude Desktop

Cursor / VS Code

Tools

1. search_cards — Full-Text Search

2. get_price — Price + History

3. get_merkle_proof — On-Chain Verification

4. oracle_status — Live On-Chain Status

5. get_forecast — Conformal Risk Forecast

6. simulate_price — Monte Carlo Simulation

How the Simulation Works

6. get_market_snapshot — Market Overview

Architecture

Configuration

Local Development

On-Chain Contracts

📝 License & Commercial Use

✅ What You CAN Do (Free)

🚫 What You CANNOT Do (Use Limitation)

🔓 Open-Source Conversion

🤝 Commercial Licensing

Links

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

1. `search_cards` — Full-Text Search

2. `get_price` — Price + History

3. `get_merkle_proof` — On-Chain Verification

4. `oracle_status` — Live On-Chain Status

5. `get_forecast` — Conformal Risk Forecast

6. `simulate_price` — Monte Carlo Simulation

6. `get_market_snapshot` — Market Overview