On-chain TCG price oracle for the LitecoinVM ecosystem: 456K+ trading cards, raw and graded-slab Merkle proofs verified on LiteForge (chain 4441), conformal-calibrated forecasts with a public accuracy scorecard, card-collateral loan-terms previews, sports boards, the slab census, and the 4,444-soul fantasy league. 13 tools, all free, no keys.
Scored across 16 tools
Most tools are clearly separated by resource type (raw vs graded, forecast vs price, proof vs summary), and descriptions explicitly contrast get_forecast with simulate_price and get_merkle_proof with get_graded_proof. Some ambiguity remains around the suspended get_market_snapshot and the similarly named proof pair, but the descriptions mostly resolve these boundaries.
The set follows a consistent get_<noun> snake_case pattern, with descriptive names like search_cards, get_graded_asks, and get_forecast. It loses a point only because oracle_status drops the get_ prefix, making it a minor deviation.
Sixteen tools is on the heavy side, and the count is inflated by a suspended endpoint (get_market_snapshot) and non-TCG features like get_fantasy_league and get_sports_board. Most tools have distinct purposes, but the surface would be tighter and more scoped without those extras.
The read-only oracle covers its domain well: search, raw and graded pricing, two forecasting methods, Merkle proofs, census data, loan terms, status, and a self-audit scorecard. Minor gaps include the lack of a live replacement for the suspended market snapshot and per-card Japanese prices being exposed only via an external URL rather than a tool.
Observed graded-slab census totals: how many PSA/BGS/CGC/TAG slabs the oracle tracks circulating on the open market (cert-verified; a census of what is listed and pressing on price — NOT a pop report). Census leaves are committed on-chain daily.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by noting that data is cert-verified, limited to open-market circulation, and committed on-chain daily. These details convey important timing and trust characteristics beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with the core census concept in the first clause. The second sentence adds meaningful update-cadence information. Minor jargon like 'pressing on price' slightly reduces clarity, but the overall length is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with an output schema, the description covers the essential context: what is being counted, which grading companies are included, the market scope, and the update frequency. It does not discuss auth or rate limits, but no annotations suggest those are critical for this read-style tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain argument semantics. The input schema is empty and fully covered, and the description reinforces that this is a simple no-input query. This matches the baseline for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: returning open-market census totals for PSA/BGS/CGC/TAG slabs tracked by the oracle. It also draws an explicit distinction from a population report, which helps avoid misinterpretation. However, it does not directly differentiate from any sibling tool by name, so a small gap remains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when this tool is relevant—when you need market census totals rather than a population report—but it does not explicitly state conditions or point to alternatives. The 'NOT a pop report' phrase serves as a partial exclusion, but there is no direct guidance selecting this over related tools like get_market_snapshot or get_oracle_scorecard.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The Undesirables fantasy league on LitecoinVM: 4,444 AI personalities draft weekly fantasy lineups over the oracle's calibrated sports forecasts. Every lineup is merkle-committed to the PredictionRegistry on LiteForge (stream fantasy_souls) BEFORE games score. No token_id: league feed with standings and the week's commit txs. With token_id: that soul's lineup, personality traits, and drafting strategy.
| Name | Required | Description | Default |
|---|---|---|---|
| token_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose meaningful behavior: outputs are conditional on token_id, lineups are merkle-committed before games score, and commit transactions are returned. It does not state whether the tool is read-only, whether authentication is required, or how errors or rate limits behave.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences are reasonably sized and structured around the token_id branch, but the first sentence is atmospheric scene-setting rather than front-loaded function. The provenance sentence earns its place by explaining data commitment timing, and the final sentence delivers the key conditional behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the description need not detail return shapes, though it helpfully does. Given the single undocumented parameter and no annotations, it supplies enough context to call the tool correctly, but it omits safety/read-only semantics and sibling routing guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the single parameter, and it does: omitted token_id yields a league-level feed, while a provided token_id yields that soul's lineup and personality details. It does not explicitly clarify whether token_id=0 (the schema default) behaves like omission or like a real soul id, leaving a minor edge case ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what the tool returns for both modes: a league feed with standings and commit txs, or an individual soul's lineup, traits, and strategy. It distinguishes this from siblings via the fantasy league and PredictionRegistry context. A crisp verb like 'retrieve' is missing and the lore-heavy opening delays the functional statement, but purpose is still clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly explains the two usage modes through the token_id parameter (no token_id for league feed, with token_id for a soul's details). However, it gives no guidance on when to choose this tool over alternatives like get_sports_board or get_forecast, and no exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FROZEN INPUTS since 2026-09-07: the USD price series stopped, so this is computed from the last published prices; responses carry usd_panel {frozen: true, as_of}. Say "last published", never "today". 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.
| Name | Required | Description | Default |
|---|---|---|---|
| card_name | Yes | Card to forecast (e.g. "Charizard Base Set Holo") |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does so well: it discloses frozen inputs since 2026-09-07, that responses carry usd_panel {frozen: true, as_of}, the required terminology ('Say "last published", never "today"'), and the guarantees of being deterministic, distribution-free, and never-under-protective. These are substantive operational facts an agent could not infer from the schema alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The critical frozen-input caveat is correctly front-loaded, and each sentence adds information. It is somewhat verbose, with mild promotional framing ('honest', 'recommended') and a parenthetical VaR explanation that could be tightened, but there is no true filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value exposition is not required, yet the description still notes the usd_panel envelope and letter grades to set expectations. Combined with the frozen-input warning, sibling contrast, and honesty guarantees, nothing an agent needs to invoke this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single card_name parameter, so the schema already fully documents the input. The description adds no syntax, format, or resolution guidance beyond what the schema provides, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get the calibrated conformal risk forecast for a trading card') and immediately differentiates itself from the sibling simulate_price by contrasting its distribution-free calibration with Monte Carlo simulation. An agent can distinguish this from get_price, simulate_price, and get_market_snapshot without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It declares itself 'the recommended, honest default forecast,' which is a clear usage signal, and implicitly routes agents away from simulate_price for distribution-free needs. It does not, however, give explicit when-not-to-use conditions or name the alternative tool directly, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Graded-slab ASKING prices for one card — PSA/BGS/CGC medians by grade with listing counts, low/high, as-of per grade and the explicit price_basis (eBay asks, not sold prices). FREE, daily, merkle-committed on GradedPriceOracle. The LIVE value layer while the USD raw-card panel is frozen, and the basis of the graded-slab loan terms.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does well: it discloses that the tool is FREE, updated daily, merkle-committed on GradedPriceOracle, and explicitly states the price basis (eBay asks). This adds meaningful behavioral context beyond a simple 'get' tool, though it does not mention any side effects or auth requirements (likely read-only).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that front-loads its core purpose and packs in useful details (data basis, freshness, cost, oracle). It is efficient and avoids fluff, though it might be slightly run-on with multiple clauses; still appropriately sized for the information conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description doesn't need to explain return values. It explains the purpose, data basis, and operational traits well. However, it fails to explain the sole input parameter (product_id), which is a critical omission for a 1-parameter tool. This leaves the definition incomplete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only one parameter, product_id, with 0% description coverage. The tool description mentions 'for one card' but never explicitly maps product_id to a card identifier or explains what value to pass. The description focuses entirely on the output, leaving the only required parameter completely unexplained, which fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource and action: 'Graded-slab ASKING prices for one card' and enumerates the exact outputs (PSA/BGS/CGC medians, listing counts, low/high, as-of, price_basis). It clearly distinguishes itself from siblings by emphasizing 'eBay asks, not sold prices' and positioning itself as the LIVE value layer, separating it from raw-card price tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers clear context for when to use this tool ('the LIVE value layer while the USD raw-card panel is frozen' and 'the basis of the graded-slab loan terms'), implying it is the go-to for graded-slab ask prices. However, it does not explicitly name alternatives or exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Merkle proof for a GRADED-slab price on the GradedPriceOracle contract (LiteForge, Chain 4441). The graded price tree is committed on-chain daily — this proof lets any agent verify a slab price trustlessly, the same way get_merkle_proof verifies raw-card prices. Grades like 'PSA 10', 'PSA 9', 'BGS 9.5'.
| Name | Required | Description | Default |
|---|---|---|---|
| grade | No | PSA 10 | |
| product_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description adds meaningful behavioral context: the proof enables trustless verification, the price tree is committed on-chain daily, and any agent can verify. It does not explicitly state read-only/no side effects, but the Merkle-proof framing and 'any agent' phrasing strongly imply a non-mutating, accessible operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no filler. The first sentence states the core purpose, the second adds verification context and sibling distinction, and the third gives concrete grade examples. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema covers return values, and the description covers the contract, chain, verification mechanism, and sibling relationship. However, the meaning of product_id remains ambiguous, which is a significant gap for correct invocation. Overall it is mostly complete but not fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides useful grade examples like 'PSA 10' and 'BGS 9.5', but it does not explain what product_id refers to or how it relates to grade. This leaves a critical parameter under-defined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb and resource: fetching a Merkle proof for a graded-slab price from the GradedPriceOracle on a specific chain. It also distinguishes itself from get_merkle_proof by clarifying that get_merkle_proof handles raw-card prices while this one handles graded prices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied clearly: use this tool for graded slab prices, and use get_merkle_proof for raw-card prices. However, it does not explicitly state when not to use this tool or list exclusions/prerequisites beyond that analogy.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
FREE worked derivation of GRADED-SLAB lending terms (v2, 2026-09-12): live slab value (realized sales > delisting-inferred sales > ask median x 0.85) -> historical 99% tail of the underlying card -> liquidation buffer -> census liquidity cap -> max LTV, six steps shown. grade e.g. "PSA 10"; omitted = the slab's deepest-census grade. term_days: 7, 14 or 30. Only free-board slabs (top 250 by census depth) return the derivation; others 404 with a pointer to the paid quote ($0.10 x402, ~1,100 rated slabs). Raw-card quotes are no longer issued (USD level frozen 2026-09-07). Informational only — not financial advice.
| Name | Required | Description | Default |
|---|---|---|---|
| grade | No | ||
| term_days | No | ||
| product_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and delivers a lot: free tier, 404 behavior for non-qualifying slabs, the paid alternative and its price, a frozen USD level, and an informational-only disclaimer. It omits auth/rate-limit details, but the failure mode and cost profile are unusually well disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The content is dense but front-loaded — the derivation chain appears first via arrows, then defaults, then pricing/availability caveats. Given the domain complexity the length is justified, though the parenthetical pricing and date clauses stack up and slightly impede scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema already covers return values, so the description is free to spend its words on the derivation pipeline, eligibility, and commercial context — which it does. For a tool with branching availability and a paid fallback, nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, and it does for two of three parameters: grade is exemplified ("PSA 10") with the omitted-default semantics, and term_days enumerates the allowed values 7/14/30 (the schema has no enum). product_id is left unexplained, a modest gap in an otherwise compensating description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource — a worked derivation of graded-slab lending terms — and even enumerates the six computation steps, so the agent knows exactly what comes back. It names the paid-quote fallback rather than a sibling tool, but among siblings like get_price and get_market_snapshot the lending-terms scope is still identifiable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the availability condition clearly: only free-board slabs (top 250 by census depth) return the derivation, others 404 with a pointer to the paid quote. It also notes raw-card quotes are no longer issued. The routing logic is explicit, though it doesn't contrast this tool against any of the twelve sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The graded slabs the Loan-Terms Oracle will quote, best collateral first: grade, live ask median, census depth, liquidity tier, rank and a free_board flag (the top 250 by census depth carry a free derivation via get_loan_terms_preview). FREE. v2: graded slabs only — raw-card quotes stopped when the USD level froze 2026-09-07.
Returns a PAGE, not the whole book: the full universe is ~1,400 slabs and
serialises to ~865 KB, which would swamp an agent's context in one call.
total_matching and returned say what you are holding.
limit rows to return (default 50, max 500) tier 'deep' | 'moderate' | 'thin' | 'illiquid' free_board_only True to keep only slabs with a free worked derivation min_value_usd drop slabs whose ask median is below this (0 = no floor)
| Name | Required | Description | Default |
|---|---|---|---|
| tier | No | ||
| limit | No | ||
| min_value_usd | No | ||
| free_board_only | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure. It reveals the tool is FREE, returns a page not the full ~1,400-slab book, warns about ~865 KB serialization, and clarifies that raw-card quotes stopped in v2—exactly the kind of context annotations would otherwise provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: purpose is front-loaded, the pagination warning is critical, and the parameter block is compact and scannable. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 description covers pagination and parameter semantics, it is nearly complete. The only gap is that it doesn't explain how to fetch subsequent pages (no cursor or offset parameter is visible), which is a minor omission for a paginated tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates completely: it explains all four parameters (limit, tier, free_board_only, min_value_usd) with types, defaults, allowed values, and meaning. No parameter is left opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the graded slabs the Loan-Terms Oracle will quote, with a specific resource and scope. It also distinguishes itself from get_loan_terms_preview by noting the free derivation flag and the v2 shift to graded slabs only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description hints that get_loan_terms_preview is the alternative for free derivations on top-250 slabs, and explains the paginated nature of this tool. However, it does not explicitly state when to use this tool versus other siblings beyond that one mention.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
SUSPENDED 2026-09-12: the USD price panel behind /api/v1/market froze on 2026-09-07. The oracle answers {"status": "suspended"} with the reason and live alternatives (no charge). Prefer get_sports_board, get_loan_terms_preview (graded slabs, live) or get_census_summary. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| game | No | Game name (default "Pokemon") | Pokemon |
| limit | No | Number of cards to return (1-50, default 25) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well: it discloses the failure mode (oracle returns {'status': 'suspended'} with a reason), the freeze date that caused it, and the billing trait ('no charge'). It stops short of describing pricing when live or any rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The suspension notice is correctly front-loaded before the evergreen description. Minor redundancy between 'top trading cards sorted by value' and 'Returns the highest-value cards', and the trailing game list is bulky but functionally useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return shape need not be explained, and the description covers the current suspended state, alternatives, and valid game inputs. What is missing is guidance for post-suspension use, such as cost or freshness of prices once the panel is restored.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds real value the schema lacks by enumerating the 13 valid game values, effectively supplying the enum that the schema omits, plus noting the value-sorted return semantics tied to 'limit'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear verb and resource ('Get a market overview') plus the returned artifact ('highest-value cards ... with current market prices and low buy-it-now prices'). The suspension banner is front-loaded and the live-function description follows. It does not explicitly contrast with siblings like search_cards, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent away from this tool while suspended, naming three alternatives (get_sports_board, get_loan_terms_preview, get_census_summary) and noting they are live and uncharged. This is strong when-not guidance, but it never states when this tool should be chosen over search_cards or get_price once usable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 284K 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.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | TCGPlayer product ID (e.g. 98580 for Shadowless Charizard) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It states the tool returns a proof array, describes the daily Merkle root commitment, and discloses that only actively-priced products are included. The behavior is clear for a simple read-only proof fetch, though it does not describe error behavior or proof expiration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than minimal, but it is well-structured with a clear opening, contextual 'WHY THIS MATTERS' section, and a note that highlights a critical limitation. Each section serves a purpose for an AI agent deciding whether this tool is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, this description is complete: it explains what the proof is for, how it is produced, how to use it, and the key edge case where proof generation is impossible. Nothing essential is missing for correct invocation and selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for product_id, so the baseline is 3. The description adds extra semantic value by explaining that the product must be actively priced (market_price > 0) to have a proof, which goes beyond the schema's generic 'TCGPlayer product ID' description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Get a Merkle proof for on-chain price verification on LitecoinVM.' It further clarifies the deliverable as a proof array committed to the LitecoinVM blockchain by the oracle operator, making the tool's purpose unambiguous and distinct from a normal price lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains why an agent would want this tool instead of trusting regular API prices, which is strong contextual guidance. It also includes an explicit constraint: zero-price catalog entries cannot be proven. It does not name sibling alternatives like get_price or get_graded_proof, so it falls just short of full when-to-use versus alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The oracle's public accuracy record — verify before trusting. Rolling 30-day coverage on matured forecasts (recent: 90% bands covered 93%+ across 181K+ graded predictions), the souls' scored track record, and the blind slab study. Every scored prediction was committed to LiteForge
Base before its outcome existed, so the table cannot be curated.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It provides useful behavioral context: coverage is a rolling 30-day window over matured forecasts, and the data is claimed to be non-curatable because predictions were committed before outcomes existed. It does not explicitly state that the call is read-only or whether any access restrictions apply, but 'public accuracy record' and the get-style name make the safety profile reasonably clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core message: this is the oracle's accuracy record. The second sentence is dense and contains statistical detail, but it still earns its place by explaining the scoring scope and integrity guarantee. Minor jargon like 'souls' and 'blind slab study' slightly reduce clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description is largely sufficient: it explains what the scorecard contains and why it should be trusted. It could be more complete by explicitly differentiating from sibling tools, especially get_graded_proof, but the agent can still invoke and interpret the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter meanings, and its content about coverage and provenance adds contextual rather than semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a clear resource: the oracle's public accuracy record, and it specifies what it contains (rolling 30-day coverage, souls' scored track record, blind slab study). The purpose is implied through 'verify before trusting,' but there is no explicit action verb like 'returns' or 'retrieves.' It distinguishes from siblings like get_forecast and get_graded_proof conceptually, though not by name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'verify before trusting' gives an explicit use case: call this before relying on oracle predictions. It does not, however, mention alternatives or state when not to use it, such as pointing users to get_graded_proof for individual prediction evidence or get_forecast for current forecasts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FROZEN INPUTS since 2026-09-07: the USD price series stopped, so this is computed from the last published prices; responses carry usd_panel {frozen: true, as_of}. Say "last published", never "today". 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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations to lean on, the description carries the full burden and does disclose a significant operational trait: inputs are frozen since 2026-09-07, the USD series stopped, and responses carry usd_panel {frozen: true, as_of}. It even prescribes response phrasing ('Say "last published", never "today"'). It stops short of permissions, rate limits, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The critical frozen-data caveat is front-loaded, which is the right call for a stale-data warning. There is mild redundancy between 'Get the latest market price and historical price data' and 'Returns current market price, low (buy-it-now) price, and daily price history', but the block is otherwise tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value documentation is optional, yet the description still usefully sketches the returned fields and flags the frozen-data envelope. The main omission is any guidance on choosing between the two input modes when both or neither are supplied (no required params).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and each parameter already documents itself, so the baseline is 3. The description's 'fuzzy search' vs 'exact lookup' distinction largely restates the schema descriptions, and the `days` window parameter is not mentioned in prose at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Get the latest market price and historical price data for a trading card') and identifies the two input modes. It fails to differentiate from close siblings like get_market_snapshot or simulate_price, so an agent must infer which of these price-related tools is the right one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It tells the agent how to invoke it ('Provide either a card name (fuzzy search) or a TCGPlayer product ID') but gives no when-to-use/when-not guidance relative to get_market_snapshot, get_forecast, or simulate_price. Usage is implied rather than contrasted with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Daily sports movers — hot, high-volume players per live league with calibrated 7-day forecast context. The underlying stat panels are merkle-committed daily to SportsStatsRegistryV2 on LiteForge + Base. Off-season leagues report dormant instead of serving frozen numbers.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| league | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and it does disclose concrete behavior: daily cadence, live-league condition, merkle commitment, and off-season dormant reporting instead of stale numbers. This goes well beyond a generic getter, though it stops short of covering error cases or data volume limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences with no filler, front-loading the main output before adding provenance and off-season behavior. The second sentence's blockchain registry detail is niche but earns its place as behavioral context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, so return details don't need description. But the missing parameter semantics and lack of sibling differentiation leave gaps an agent must resolve before confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to explain both parameters. It only tangentially links 'league' via 'per live league' and says nothing about 'limit', its default, or the meaning of an empty string.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as a daily sports movers board for hot, high-volume players per live league, which distinguishes it from siblings like get_forecast or get_market_snapshot. However, it lacks an explicit verb like 'returns' or 'lists', so it reads more like a product label than a clear operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when daily sports movers are needed and mentions live leagues, but it never states when to prefer this over sibling tools or names any alternatives/exclusions. An agent must infer the use case from the noun phrase 'daily sports movers.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavior. It does so by stating that it reads directly from the LiteForge blockchain via Caldera RPC on Chain ID 4441, and that the data is not cached. It also lists the returned objects, giving the agent a clear expectation of freshness and scope. It omits failure modes and latency, but these are secondary for a status read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: purpose, key behavior, then bulleted return sections. Every sentence adds information, and the 'No arguments required' note cleanly wraps up the parameter story. It is easy to scan and parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-argument status tool, this description is complete. It explains the live on-chain nature, lists all four output groups, and references a chain ID and RPC endpoint. The presence of an output schema further covers the return structure, so nothing critical is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema is an empty object, so no parameter explanations are needed. The description explicitly confirms 'No arguments required,' which aligns with the schema and removes any doubt for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear action ('Get live status') and a specific resource ('TCG Price Oracle on LitecoinVM'). It enumerates the exact oracle components returned, distinguishing this from the data-retrieval sibling tools, which all have get_* names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description frames this as a live on-chain status read and explicitly contrasts with cached data, making its intended use clear. It does not name sibling alternatives or state when not to use it, but the zero-argument signature and status-oriented wording leave little ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FROZEN INPUTS since 2026-09-07: the USD price series stopped, so this is computed from the last published prices; responses carry usd_panel {frozen: true, as_of}. Say "last published", never "today". Search 446K+ trading card products by name using full-text search.
The catalog contains 446K products total — 284K 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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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") |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it does real work: it warns that price inputs are frozen, that responses carry usd_panel {frozen: true, as_of}, and even dictates phrasing ('say last published, never today'). It also discloses catalog composition (284K priced vs ~157K catalog-only with no price history), which tells the agent some results will lack prices. Auth, rate limits, and pagination behavior are not covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The frozen-inputs warning is usefully front-loaded, but '446K' is stated twice and the game list is a verbless fragment ('Disney Lorcana, Flesh & Blood, ...'). It is not bloated, but it has redundancy and an unanchored list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return fields need not be enumerated, yet the description still covers the critical caveat (frozen prices), catalog coverage, and the tool's role in the workflow. With no annotations, gaps like auth or rate limits remain, but nothing needed to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents query, game, and limit; baseline 3 applies. The description's list of supported games adds some context for the game filter, but it differs from the schema's own examples (Pokemon/Magic/Yu-Gi-Oh), which risks confusion rather than adding clean meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — 'Search 446K+ trading card products by name using full-text search' — and names the downstream consumers (get_price, get_merkle_proof) so the agent can place it as the catalog entry point among its siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies clear workflow context: this is the lookup step whose returned product IDs feed get_price and get_merkle_proof. It gives no explicit when-not or exclusion guidance, but the usage context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FROZEN INPUTS since 2026-09-07: the USD price series stopped, so this is computed from the last published prices; responses carry usd_panel {frozen: true, as_of}. Say "last published", never "today". 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 (26.9M+ 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.
| 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) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so unusually well: it discloses the frozen-input state since 2026-09-07, that prices are last-published rather than current, the usd_panel {frozen, as_of} response flag, the data provenance (real prices, 26.9M+ observations, 365-day history), and the degraded-mode behavior with its 'default_tcg_priors' label.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the most consequential fact (frozen USD series) and the routing rule, which is good discipline. The seven-step math walkthrough and the 'NOT fake data' reassurance are longer than strictly needed for tool selection, but they earn their place given trust concerns around synthetic data.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter simulation tool with a full output schema and no annotations, the description supplies the missing pieces an agent needs: data freshness caveats, the alternative sibling, the fallback path, and response labeling. Return-value detail is correctly delegated to the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so days, model, and simulations are already fully documented with ranges and defaults. The description explains the calibration pipeline but adds no syntax or behavioral detail about the parameters themselves, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Run a Monte Carlo price simulation for a trading card') and explicitly differentiates itself from the sibling get_forecast by naming the alternative's method (conformal VaR + Safe-Hold/Momentum grades) and its own (Merton/GBM stochastic paths). An agent can route between the two without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use guidance: use get_forecast for the 'honest DEFAULT forecast', use this tool when a stochastic Monte Carlo alternative is wanted, and notes it is 'opt-in'. It also names the exact conditions under which fallback priors apply (<5 data points).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_loan_universe4 fields changedInput schema / properties / free_board_onlyAdded value: +{
+ "default": false,
+ "type": "boolean"
+}Input schema / properties / limitAdded value: +{
+ "default": 50,
+ "type": "integer"
+}Input schema / properties / min_value_usdAdded value: +{
+ "default": 0,
+ "type": "number"
+}Input schema / properties / tierAdded value: +{
+ "default": "",
+ "type": "string"
+}get_graded_asksget_jp_summaryget_loan_universeget_loan_terms_preview1 field changedInput schema / properties / gradeAdded value: +{
+ "default": "",
+ "type": "string"
+}get_census_summaryget_fantasy_leagueget_forecastget_graded_proofget_loan_terms_previewget_market_snapshotget_merkle_proofget_oracle_scorecardget_priceget_sports_boardoracle_statussearch_cardssimulate_price
Add one secure layer between your agents and this server.