undesirables-mcp-server
Server Details
Conformal TCG risk forecasts + AI card grading, x402 pay-per-call oracle, on-chain soul agents.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- sailorpepe/undesirables-mcp-server
- GitHub Stars
- 1
- Server Listing
- undesirables-mcp-server
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.1/5 across 12 of 12 tools scored.
Most tools have distinct purposes, but there is some overlap between card_forecast and simulate_price (both price predictions) and between grade_card and grade_or_not (both grading-related). Descriptions help clarify differences, but an agent might still misselect without careful reading.
Tools use snake_case, but patterns vary: some are verb_noun (check_accuracy, grade_card, optimize_portfolio), some are noun_verb (card_forecast, market_snapshot), and 'grade_or_not' and 'souls_in_wallet' use prepositions. This inconsistency could confuse agents expecting a uniform pattern.
With 12 tools covering search, forecasting, grading, portfolio optimization, and market trends, the count is well-scoped for a TCG market analysis domain. Each tool serves a clear purpose without being excessive.
The tool surface covers key operations: search, price forecast, grading, market snapshots, and trend detection. Minor gaps exist, such as lack of historical price data or detailed card info beyond search, but these are compensated by the existing tools. The soul-related tools are niche but fit the server's theme.
Available Tools
12 toolscard_forecastAInspect
Get the conformal-calibrated 30-day price forecast AND letter grades for a single card in ONE free call. Pass either a card_name (resolved to the best match) or a TCGplayer product_id.
FREE — no payment required. Returns an agent-complete object: price, as_of, regime, point (median 30d), move_pct, prob_up, band50_pct, band90_pct, var95_pct, var99_pct, low90, high90, safe_hold grade (A+..F), momentum grade (A+..F or "NA" on a drift spike), drift_spike, image_url, card_url, and a one-line plain_english read (e.g. "~12% chance it's below $Y in 30 days; Safe-Hold B, Momentum A").
Use this when a user asks "is this card a safe hold?", "what's the 30-day outlook?", "how risky is X?", or wants a quick grade on a card. Tip: GET /api/v1/forecast (no args) returns the free board of the top ~200 cards if the user wants a market overview.
| Name | Required | Description | Default |
|---|---|---|---|
| card_name | No | ||
| product_id | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully covers behavioral aspects: it states the tool is free, returns an 'agent-complete object' with detailed fields, and includes a plain_english output. It does not mention auth or rate limits, but the disclosed information is valuable.
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 front-loaded with the main purpose and is well-structured. It lists all return fields, which is thorough but slightly verbose. Still, every sentence adds value.
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 tool has no output schema, the description fully details the return object, including all fields and their meanings. It also provides usage tips and a reference to an endpoint for market overview, 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining the two parameters: card_name (resolved to best match) and product_id. This adds significant meaning beyond the schema's types and defaults.
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 explicitly states the tool's function: getting a conformal-calibrated 30-day price forecast and letter grades for a single card. It distinguishes from siblings by mentioning an alternative endpoint for a market overview and provides clear usage scenarios (e.g., 'is this card a safe hold?').
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 specific when-to-use guidance (e.g., asking about safe hold, risk, outlook) and a tip for an alternative (free board). It lacks explicit when-not-to-use or comparison to all siblings, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_accuracyAInspect
View TCG Oracle's public prediction accuracy dashboard. Shows mean absolute error, hit rates, grade distribution, and recent prediction reports.
FREE — no payment required.
Use this when: a user asks "how accurate is the grading AI?" or wants to verify the model's track record.
| Name | Required | Description | Default |
|---|---|---|---|
| game | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It describes the tool as read-only (viewing dashboard) and mentions it's free. No side effects are indicated, which is appropriate for a read 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 concise, with each sentence providing value. It front-loads the purpose and adds usage guidance in separate lines.
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 simple read tool with one optional parameter, the description covers the main functionality and usage. However, the missing parameter explanation and lack of output schema leave minor gaps.
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 single parameter 'game' has no description in the schema (0% coverage). The tool description does not explain its purpose or possible values, leaving the agent uninformed about how to use it.
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 'View TCG Oracle's public prediction accuracy dashboard' with specific metrics (mean absolute error, hit rates, etc.), making it distinct from siblings like 'card_forecast' or 'grade_card'.
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 includes 'FREE — no payment required' and specifies when to use: when user asks about accuracy or wants to verify track record. Provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
grade_cardAInspect
AI-grade a trading card image using a 3-stage pipeline: (1) Qwen Vision LLM analyzes corners, edges, surface defects (2) OpenCV measures exact centering ratios programmatically (3) BGS professional capping algorithm adjusts the final grade
Returns PSA/Beckett-calibrated subgrades and an overall condition score. Also includes a free ROI verdict (should you grade this card?).
PAID: $0.10 USDC per call (x402 payment on Base network).
Use this when: a user has a card image and wants to know what grade it would receive from PSA or Beckett.
| Name | Required | Description | Default |
|---|---|---|---|
| game | No | Pokemon | |
| image_url | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It describes a 3-stage pipeline, costs ($0.10 USDC per call), and the return of subgrades and ROI. It does not mention side effects or read-only nature, but the process is transparent enough.
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 well-structured with clear sections but slightly verbose. It front-loads the core purpose and provides useful pipeline details. Minor trimming could improve conciseness, but it remains effective.
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 description covers the main return values and cost, but lacks details on error handling, edge cases (invalid images), and the 'game' parameter. Given no output schema, it partially compensates but leaves gaps.
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. It mentions the required 'image_url' implicitly but fails to mention the optional 'game' parameter (default 'Pokemon'). This omission limits the agent's understanding of all parameters.
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 explicitly states it 'AI-grade a trading card image' and details the output (PSA/Beckett-calibrated subgrades, overall score, ROI verdict). The verb+resource is specific and clear, and the purpose is well-defined.
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 provides a clear use case: 'Use this when: a user has a card image and wants to know what grade it would receive from PSA or Beckett.' It lacks explicit when-not-to-use or alternatives, but the context is well-communicated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
grade_or_notAInspect
Answers: "Should I grade this card? Will I make money?"
Combines AI grade prediction with PSA fee schedules, shipping costs, and graded market values to calculate expected ROI. Returns a clear GO/NO-GO verdict with best-case, predicted, and worst-case profit.
PAID: $0.10 USDC per call.
Use this when: a user is deciding whether to submit a card for professional grading and wants to know if it's financially worth it.
| Name | Required | Description | Default |
|---|---|---|---|
| card_name | Yes | ||
| raw_price | No | ||
| service_tier | No | regular | |
| predicted_grade | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description discloses it is paid ($0.10 per call) and describes the verdict output with profit scenarios. However, it does not detail error handling, data sources, or assumptions, which would be valuable for a decision tool.
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 concise with a clear header, purpose, pricing, and usage guidance. Every sentence adds value. Could be slightly more structured (e.g., bullet points for parameters), but overall efficient.
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 description mentions the output includes best-case, predicted, and worst-case profit with a GO/NO-GO verdict, but lacks details on format or data. Parameter defaults are not explained. For a tool combining multiple inputs, more complete context would be beneficial.
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%. The description mentions the parameters in context but does not explain their meaning, defaults, or valid values (e.g., service_tier options). Users would need external knowledge to set values like raw_price or predicted_grade.
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 answers 'Should I grade this card? Will I make money?' and explains it combines AI grade prediction with fee schedules and market values to return a GO/NO-GO verdict. This distinguishes it from sibling tools like grade_card or market_snapshot.
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?
Explicit usage guideline: 'Use this when: a user is deciding whether to submit a card for professional grading and wants to know if it's financially worth it.' No mention of when not to use or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
market_snapshotAInspect
Daily TCG market snapshot with top movers, biggest gainers/losers, and volume leaders across all 13 supported card games. FREE — no payment required.
Use this when: a user asks "what's trending in the card market?" or "what cards are going up/down in value?"
| Name | Required | Description | Default |
|---|---|---|---|
| game | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions 'FREE — no payment required' and 'Daily', implying periodic updates. However, it doesn't detail data freshness, rate limits, or whether it's cached. Adequate but not comprehensive.
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 extremely concise (4 lines), front-loads the core purpose, and uses efficient phrasing. Every sentence adds value with no 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 simplicity of the tool (1 optional param, no output schema), the description covers purpose, usage context, and the free aspect. However, it omits parameter explanation, which is a notable gap for completeness.
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 description has 0% schema coverage and fails to explain the only parameter 'game'. Despite stating 'across all 13 supported card games', it doesn't clarify that the parameter can filter to a specific game. The description adds no value for parameter understanding.
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 'Daily TCG market snapshot with top movers, biggest gainers/losers, and volume leaders across all 13 supported card games.' It specifies the verb (snapshot), resource (market), and scope (all games), differentiating it from siblings like trending_cards or card_forecast.
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 explicitly tells when to use: 'Use this when: a user asks "what's trending in the card market?" or "what cards are going up/down in value?"' It lacks explicit when-not-to-use or alternatives, but the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
optimize_portfolioAInspect
Optimize a trading card portfolio using Markowitz mean-variance analysis with Merton jump-diffusion Monte Carlo simulations.
Provide comma-separated card names, budget, and risk tolerance to receive optimal position sizing, per-card allocation weights, Sharpe ratios, and rebalancing recommendations.
PAID: $0.50 USDC per call.
Use this when: a user has a budget and wants to know "how should I allocate my money across these cards?"
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| cards | Yes | ||
| budget | No | ||
| risk_tolerance | No | moderate |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses cost ($0.50/call) and methodology, but does not state if read-only, destructive, or rate limits. Adds moderate context beyond 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?
Well-structured, front-loaded with purpose, then outputs, cost, and usage hint. Each sentence is informative, not overly verbose.
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 no output schema, no annotations, and 0% parameter schema coverage, the description is incomplete. It fails to explain the 'days' parameter and does not describe return format or required permissions for a complex financial 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 coverage is 0%, so description must compensate. It explains 'cards', 'budget', and 'risk_tolerance' partially but omits 'days' parameter entirely. No details on valid values for risk_tolerance.
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 optimizes a trading card portfolio using specific methods (Markowitz, Monte Carlo) and gives a usage scenario, distinguishing it from siblings like market_snapshot or card_forecast.
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 says 'Use this when: a user has a budget and wants to know how to allocate money', providing clear context. Lacks mention of when not to use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recommend_workflowAInspect
Describe your goal in natural language and get a recommended sequence of TCG Oracle API calls to accomplish it.
FREE — no payment required.
Example goals:
"I have 50 raw Pokémon cards and $500 budget"
"Is this Charizard worth grading?"
"Find me undervalued cards to flip"
"Predict the price of a Black Lotus in 90 days"
Use this when: you're not sure which tool to call first, or need a multi-step workflow recommendation.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions 'FREE' but does not specify whether recommendations are executed or just suggested. Lacks details on side effects, auth, or 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?
Concise, well-structured: purpose statement, free-of-charge note, examples, and usage guidance. Every sentence adds value, no 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?
For a simple tool with one parameter and no output schema, the description covers purpose, input format, and when-to-use. No critical gaps given the complexity.
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?
With 0% schema description coverage, the description adds essential meaning: 'goal' should be a natural language description. Provides example goals, which greatly aids understanding.
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?
Clearly states the tool's function: accept a natural language goal and return a sequence of API calls. Distinct from sibling tools that perform individual tasks.
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 says 'Use this when: you're not sure which tool to call first, or need a multi-step workflow recommendation.' Provides clear context and implied alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_tcg_productsAInspect
Search 446K+ TCG products across 25+ card games. Returns card names and IDs, plus current market prices. FREE — no payment required.
Use this when: a user asks about a specific card, wants to find cards, or needs current pricing for any trading card game product.
HOW TO SEARCH (card name AND set name are both searchable): • Card name alone casts the widest net: "Charizard", "Black Lotus". • Add the SET to pin down a printing: "Base Set Charizard" returns the Base Set, Base Set 2 and Shadowless Charizards as separate entries. This matters — printings of the "same" card differ wildly in value. • Every result carries a "set" field. Use it to choose, then pass that result's product_id to the other tools (card_forecast, grade_or_not, simulate_price) — exact, and avoids re-searching. • Do NOT include rarity or condition words: "Holo", "1st Edition", "Shadowless", "PSA 10" are not indexed and will sink an otherwise-good query. "Base Set Charizard Holo" → drop "Holo". • Got nothing? Remove the rarity words first, then fall back to the plain card name.
| Name | Required | Description | Default |
|---|---|---|---|
| game | No | ||
| limit | No | ||
| query | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
In the absence of annotations, the description fully carries the burden. It discloses that the tool is free, what it returns, and key behavioral constraints (e.g., rarity words not indexed, printings vary). No contradictions. Lacks mention of rate limits or auth, but acceptable for a search tool.
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 front-loaded with the core purpose and structured with bullet points. It is reasonably concise, though a bit wordy. Every sentence adds value.
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 no output schema and no annotations, the description covers essential aspects: tool purpose, search strategies, expected output, and integration with siblings. Lacks pagination details but is complete enough for effective use.
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 description must compensate. It provides excellent guidance on the 'query' parameter but does not explicitly describe the 'game' or 'limit' parameters, nor their defaults. Partial compensation.
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 it searches TCG products across 25+ card games, returns card names, IDs, and current market prices. It distinguishes itself from siblings by noting that results include a 'set' field and product_id used by other 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?
Explicitly states when to use: when user asks about a specific card or wants pricing. Provides detailed search strategies: using card name vs. adding set, avoiding rarity/condition words, and fallback approach. Also explains how to pass results to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
simulate_priceAInspect
Predict future trading card value. The default model is the conformal-calibrated risk forecast (deterministic drift + regime-aware split-conformal bands, honest VaR/CVaR, plus Safe-Hold & Momentum letter grades). Monte Carlo GBM and Merton jump-diffusion are available opt-in via model="gbm" or model="merton".
Returns full forecast percentiles (5th–95th), model parameters, and confidence intervals with complete mathematical transparency.
PAID: $0.015 USDC per call.
Use this when: a user wants to know "what will this card be worth in 3 months?" or wants price trajectory predictions.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| model | No | conformal | |
| card_name | Yes | ||
| simulations | No | ||
| current_price | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses pricing ($0.015 USDC per call), model details (conformal, GBM, Merton), and output format (percentiles, parameters, confidence intervals). No annotations provided, so description carries full burden and does it well, though cost disclosure is notable.
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 purpose, then details. A bit verbose with technical model names but each sentence adds value. Could be slightly shorter, but structure is logical.
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 5-parameter prediction tool with no output schema, the description explains behavior and cost but lacks parameter details and full output format. More information would help the agent use it correctly, especially regarding the return structure.
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?
Input schema has 5 parameters with 0% description coverage. The description mentions 'model' options but does not explain 'days', 'simulations', or 'card_name'/'current_price'. Without parameter descriptions in the schema, the tool leaves the agent guessing about formatting or constraints.
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?
Clearly states 'Predict future trading card value' with specific verb and resource. Distinguishes default model and alternatives, and the description provides concrete use cases like 'what will this card be worth in 3 months?', making it easy for the agent to select over 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?
Explicitly says 'Use this when: a user wants to know...' giving clear context. However, it does not mention when not to use or alternatives beyond model selection, but the use cases are well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
soul_callsAInspect
Full public record for ONE Undesirable soul: every open (locked) prediction and its recent scored results. FREE — no payment required.
Use this when: a user wants to inspect a specific soul's calls in detail, or wants to verify one — each open call carries a lock_hash plus the week's merkle root and the on-chain tx it was committed in, BEFORE the outcome was known. That is what makes the record checkable rather than claimed.
Args: token_id: minted soul, 1-273.
| Name | Required | Description | Default |
|---|---|---|---|
| token_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses that the tool is free and returns specific data (lock_hash, merkle root, tx). However, it does not mention potential errors, rate limits, or authentication requirements, which are moderate gaps.
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 concise with two short paragraphs plus an Args line. It is front-loaded with the core purpose and adds value without unnecessary words.
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?
Despite no output schema, the description explains what the tool returns (open predictions, scored results, verification data) which is sufficient for a simple query tool. Minor gap: no mention of pagination if many results.
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 0% coverage, but the description adds significant meaning by defining token_id as a minted soul with range 1-273, compensating for the schema's lack of 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 clearly states the tool's purpose: retrieving the full public record for one specific soul, including open predictions and scored results. This distinguishes it from sibling tools like souls_in_wallet or market_snapshot.
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 explicitly says when to use this tool: when a user wants to inspect a specific soul's calls or verify them. It provides context but does not explicitly contrast with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
souls_in_walletAInspect
Show every Undesirable soul a wallet holds, with each soul's public prediction track record and its most recent calls. FREE — no payment, no signature, no wallet connection required.
Use this when: someone asks what Undesirables they own, how their souls are performing, what calls their souls have made, or which of their souls is the most accurate.
HOW IT WORKS • Ownership is read from Ethereum mainnet (ERC-721 0xA893648A701C03B14bF2FB767B72b2C55ed5c17A). Only the minted souls 1-273 have public records. • Nothing here is private, so you can look up ANY address — the caller does not have to prove they own it. Ask the user for their address. • Each minted soul locks 3 card predictions weekly, chosen deterministically from its on-chain personality traits. The oracle scores them 30 days later against real market prices.
WHAT YOU GET BACK • souls[] — per soul: rating (A+..F / UNRATED), matured, hits, hit_rate, brier, open_calls, and recent_calls with each call's outcome (hit / miss / push) • wallet_totals — combined open + matured calls and overall hit rate • best_soul — the holder's most accurate soul, once any have matured
HOLDERS WITH SEVERAL SOULS: this is a roster. Offer to compare them, or to speak as a specific one — each has different traits and its own record.
IMPORTANT — ratings mature on a schedule. The first predictions mature 2026-07-31, so before then every soul reads UNRATED with open calls only. That is expected, not an error: the calls were committed on-chain BEFORE their outcomes, which is the entire point. Say so rather than implying the soul has no history.
Args: address: 0x-prefixed EVM address to look up. calls: recent scored calls to include per soul (0-12, default 5).
| Name | Required | Description | Default |
|---|---|---|---|
| calls | No | ||
| address | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It explains free access, no authentication needed, data source (Ethereum mainnet), scope (only minted souls 1-273), and important timing details about ratings maturing on a schedule, ensuring the agent understands 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 description is lengthy but well-structured with sections (free note, usage, how it works, output, holder tips, important note). It is front-loaded with the main purpose and remains informative without 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?
Despite no output schema, the description explicitly details every field returned (souls array, wallet_totals, best_soul) and covers edge cases like UNRATED status before 2026-07-31, making it complete for the tool's complexity.
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%, but the description thoroughly explains both parameters: 'address' as a 0x-prefixed EVM address, and 'calls' as recent scored calls per soul with range (0-12) and default (5), adding significant meaning beyond the schema.
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 shows souls in a wallet with prediction records and recent calls. It uses a specific verb and resource, and the context distinguishes it from sibling tools like 'soul_calls' and 'check_accuracy'.
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 includes a 'Use this when' section listing specific queries, providing strong usage guidance. It also advises on handling holders with multiple souls, but does not explicitly state when not to use or list alternatives, though sibling tools exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
trending_cardsAInspect
Top trading cards by 30-day sales volume and price velocity. Covers all 13 supported TCG games.
PAID: $0.025 USDC per call.
Use this when: a user asks "what cards are hot right now?" or "what's selling the most?"
| Name | Required | Description | Default |
|---|---|---|---|
| game | No | ||
| limit | No | ||
| min_price | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool is paid and covers all games, but it does not describe the output format, ordering, authentication requirements, or edge cases (e.g., empty results). Adequate but could be more transparent.
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 extremely concise, with three short sentences that deliver the core purpose, coverage, cost, and usage guidance. No wasted words.
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 tool's simplicity (no output schema, 3 optional params), the description covers the essential purpose, cost, and usage context. However, it omits any mention of return format or results ordering, which would help an agent fully understand what to expect. Adequate but not fully complete.
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 three parameters (game, limit, min_price) with defaults, but the description mentions none of them. With 0% schema description coverage, the description fails to add any meaning beyond what the schema names imply. Parameter names are self-explanatory, but the description does not clarify their optionality or effects.
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 top trading cards by 30-day sales volume and price velocity, covering all 13 supported TCG games. This distinguishes it from sibling tools like card_forecast or market_snapshot, which focus on predictions or broader market views.
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?
Explicit usage guidance is provided ('Use this when: a user asks "what cards are hot right now?" or "what's selling the most?"'). It also mentions the cost per call. However, it does not specify when not to use it or suggest alternative tools for different needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.