What can you do with this server?

The CupOracle MCP server provides AI agents with live FIFA World Cup 2026 data, consensus betting odds, knockout bracket tracking, and autonomous premium edge buying via x402 micropayments on Injective EVM. * Free tools: Get fixtures (wc_fixtures), live scores (wc_live), consensus odds with implied probabilities (wc_odds), and knockout bracket status (wc_bracket). * Premium edge purchasing (wc_edge): Autonomously pay ~0.05 USDC via x402 (EIP-3009) for a CLV-audited edge and conviction ladder, with spend caps per call and session, and optional dry_run to test without spending. Degrades to free odds if source is down, ensuring no fabricated data. * Payment verification (receipt_verify): Validate any x402 USDC payment on Injective EVM, decoding block time, amount, payer/payee, and explorer link. * Wallet funding (wallet_fund_guide): CCTP runbook to bridge USDC from common chains onto Injective to fund the agent. * Spend audit (wc_spend_ledger): View purchase history, total spent, and remaining budget against session cap. * Seamless integration: Runs over stdio with minimal config (two free API keys; private key for payments) and can be added to Claude Desktop, Claude Code, or Cursor in one line.

Which integrations are available for this server?

Facilitates payments using Circle's USDC stablecoin and cross-chain transfers via Circle's Cross-Chain Transfer Protocol (CCTP) for funding the agent's wallet on Injective.

How do I use cuporacle-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@cuporacle-mcp analyze the next match for betting edge" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

cuporacle-mcp

by edycutjong

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Remote

Node.js TypeScript MCP Injective EVM x402 tsup Vitest License: MIT

# Claude Code — the 4 free data tools work with just two free API keys
claude mcp add cuporacle -- npx -y cuporacle-mcp

Published: cuporacle-mcp is live on npm (also mirrored to GitHub Packages as @edycutjong/cuporacle-mcp), so the npx -y cuporacle-mcp line above works today. Prefer source? git clone https://github.com/edycutjong/cuporacle-mcp && cd cuporacle-mcp && npm install && npm run smoke.

cuporacle-mcp is a standalone Model Context Protocol server that runs side by side with the Injective MCP server: 8 tools + 2 resources + 1 prompt over stdio. Free data tools work out of the box; wc_edge is a reference implementation of an agent buying and proving its own alpha keylessly via Injective's x402.

🧑‍⚖️ Notes for judges — reproduce in < 5 min

Zero-cost path. The four free tools (wc_fixtures, wc_live, wc_odds, wc_bracket) return real live World Cup 2026 data with just the two free API keys — no wallet, no funds.
The x402 buyer path runs with zero funds. wc_edge(matchId, dry_run: true) (or npm run paid-call-smoke) parses the recorded 402 quote, enforces the spend cap, and signs the EIP-3009 authorization locally — a deterministic proof of the payment client with no money moved and no fabricated receipt.

< 5-minute reproduce:

npm install
npm run smoke      # cold-start over stdio → lists 8 tools/2 resources/1 prompt + a live free call
npm test           # 63 vitest (schemas · spend cap · 402-parse · EIP-3009 sign · receipts · degrade)
npm run inspector  # official MCP Inspector conformance against the built dist/

Honestly gated (not faked) — and now proven for real: on 2026-07-18 the agent made its first real settled wc_edge purchase against the live LineLock API — 0.05 USDC on Injective EVM mainnet, receipt tx 0x89cd955cf4cab5efcb7a25cbc8e25851c8524a186f2aa449d11e4b598541a07d. Verify it yourself: receipt_verify("0x89cd…"). With zero funds, dry_run remains the reproduce path, and wc_edge still degrades to free odds — never an invented edge or receipt — full honest state in STATUS.md.

Related MCP server: ScoutAgent

💡 Why this exists

Agents have no first-class sports capability. Injective's own MCP server covers wallets, markets, CCTP and trading — but an agent asked "is tonight's match worth a bet?" has to hallucinate or scrape, and there's no pattern for an agent paying for premium data itself. CupOracle is that missing layer, built as a composable server that runs side by side with the Injective MCP server.

🧰 Tools

Tool	Gate	Returns
`wc_fixtures(date?)`	free	fixtures for a day or the next upcoming window
`wc_live(matchId)`	free	live score, minute, status
`wc_odds(matchId)`	free	consensus h2h odds + de-vigged implied probabilities
`wc_bracket()`	free	knockout bracket state (R16 → Final)
`wc_edge(matchId, maxSpend?, dry_run?)`	pays x402	CLV-audited edge + conviction ladder + receipt tx
`receipt_verify(txHash)`	free	verifies a receipt on Injective EVM (block time, amount, payee)
`wallet_fund_guide(chain?)`	free	CCTP runbook to fund the agent wallet
`wc_spend_ledger()`	free	the agent's own purchase history: entries + receipts + session total vs cap

Resources: wc://bracket, wc://ledger · Prompt: analyze-match(matchId).

🚀 Quickstart

1. Get keys

football-data.org free tier → FOOTBALL_DATA_KEY
the-odds-api.com free tier → ODDS_API_KEY

The four free data tools work with just these two keys. wc_edge additionally needs a payer wallet (see Funding).

2. Add to your harness

Claude Desktop (claude_desktop_config.json):

{
  "mcpServers": {
    "cuporacle": {
      "command": "npx",
      "args": ["-y", "cuporacle-mcp"],
      "env": {
        "FOOTBALL_DATA_KEY": "…",
        "ODDS_API_KEY": "…",
        "CUPORACLE_PRIVATE_KEY": "0x…",
        "CUPORACLE_MAX_SPEND": "0.50"
      }
    }
  }
}

Claude Code:

claude mcp add cuporacle \
  -e FOOTBALL_DATA_KEY=… -e ODDS_API_KEY=… \
  -e CUPORACLE_PRIVATE_KEY=0x… -e CUPORACLE_MAX_SPEND=0.50 \
  -- npx -y cuporacle-mcp

Cursor (.cursor/mcp.json):

{
  "mcpServers": {
    "cuporacle": { "command": "npx", "args": ["-y", "cuporacle-mcp"],
      "env": { "FOOTBALL_DATA_KEY": "…", "ODDS_API_KEY": "…" } }
  }
}

3. Ask

"What's tonight's Semi-Final, and is it worth a bet?"

The assistant lists the fixture (wc_fixtures), pulls odds (wc_odds), buys a vetted edge for ~5¢ (wc_edge) paying via x402 itself, and cites the receipt. Paste that hash into receipt_verify to confirm the payment on Injective. (Funded path — now exercised for real: first settled receipt 0x89cd955c…541a07d on 2026-07-18, see "Notes for judges". With no funds, wc_edge dry-runs or degrades to free odds and says so.)

🛠️ Injective technologies used

CupOracle is Injective-native by construction — remove any layer and it's just a scraper or a hosted API with a billing page.

#	Technology	Exact surface	Where
1	MCP Server	Publishes a complete server (stdio): 8 tools + 2 resources + 1 prompt, Inspector-conformance-checked. Extends the InjectiveLabs/mcp-server pattern and runs beside it.	the whole package
2	x402	Autonomous client: parses the 402 quote (`accepts` / `PAYMENT-REQUIRED`), signs an EIP-3009 transfer authorization, retries with `PAYMENT-SIGNATURE`, reads the receipt from `PAYMENT-RESPONSE`. Uses `@injectivelabs/x402` `./client` + `./eip3009`.	`src/x402/`, `wc_edge`
3	Agent Skills	Ships the `cuporacle` Skill: tool-selection table, spend policy, fund-if-broke runbook.	`skills/cuporacle/SKILL.md`
4	USDC + CCTP	Native USDC `0xa00C…235a` (Circle FiatTokenV2_2, EIP-3009). Funding path routes to the Injective MCP server's `cctp_supported_chains` → `cctp_attestation_status` → `cctp_mint`.	`wallet_fund_guide`, Skill
5	Injective EVM	Mainnet `eip155:1776` (Blockscout + `sentry.evm-rpc.injective.network`), testnet `eip155:1439`. `receipt_verify` reads the tx over the EVM RPC.	`src/networks.ts`, `receipt_verify`

Interop, not wrap. CupOracle does not reimplement chain ops or wrap the Injective MCP tools as its own — both servers run in the same harness and the Skill routes funding to Injective's tools. Honesty over land-grab.

🔄 The autonomous-payment loop (`wc_edge`)

flowchart TD
    A["POST /api/edge"] --> B["402 Payment Required<br/>accepts: network eip155:1776 · amount 50000 · asset USDC · payTo"]
    B --> C["spend-cap gate<br/>per-call max · per-session cap · ask human above cap"]
    C --> D["sign EIP-3009 authorization<br/>local viem signTypedData — no broadcast"]
    D --> E["retry with PAYMENT-SIGNATURE header"]
    E --> F["200 OK<br/>{ edge, ladder, pick_hash } + PAYMENT-RESPONSE { transaction: 0x… }"]
    F --> G["agent cites receipt_tx"]
    G --> H["receipt_verify(0x…)"]
    H --> I["block time + amount on Injective"]

Spending is auditable in-conversation via wc_spend_ledger (and wc://ledger). Failures teach: INSUFFICIENT_USDC carries the CCTP runbook; SPEND_CAP_HIT carries the cap and how to raise it (ask the human — the agent never raises its own).

💰 Funding the agent wallet

wc_edge needs a few cents of USDC on Injective. Generate a throwaway payer wallet and fund it via CCTP:

npx cuporacle-mcp init          # prints a fresh wallet address + key

Then call wallet_fund_guide (or ask your agent to) for the CCTP steps, executed with the Injective MCP server: account_balances → cctp_supported_chains → burn on Base (domain 6) → cctp_attestation_status → cctp_mint. Fund only cents; the default cap is 0.50 USDC.

🧑‍💻 Development

npm install
npm run smoke  # cold-start over stdio, list 8 tools/2 resources/1 prompt, one live call
npm test       # 63 vitest (schemas, spend cap, 402-parse, EIP-3009 sign, receipts, degrade)
npm run bench  # cache hit/miss + wc_edge dry_run (parse+sign) p50/p95
npm run build  # tsup → dist (publish-ready)
SMOKE_BIN=dist npm run smoke  # smoke the built artifact

npm run paid-call-smoke runs a real paid wc_edge end-to-end — it is funds-gated behind CUPORACLE_ALLOW_PAID=1 and a funded key, and otherwise falls back to a dry run.

🧪 Engineering harness & CI

This is a published npm library, not a web app — so the pipeline swaps the usual browser E2E / Lighthouse stages for the two proofs that actually matter for a stdio MCP server: a cold-start over real stdio (npm run smoke) and official MCP Inspector protocol conformance against the built dist/.

Multi-stage CI: Quality → Security → Build → MCP Conformance → Publish-readiness.

# ── Quality ─────────────────────────────────
npm run typecheck   # tsc --noEmit (strict)
npm test            # vitest — 63 passing
npm run ci          # typecheck + test + build + smoke (local gate)

# ── MCP "E2E" (no browser — this is the end-to-end proof) ──
npm run smoke       # cold-start over stdio → 8 tools / 2 resources / 1 prompt + a live free call
npm run inspector   # official MCP Inspector conformance against dist/
SMOKE_BIN=dist npm run smoke   # smoke the exact built artifact npm ships

# ── Security ────────────────────────────────
make security-scan  # npm audit + license-checker (no GPL/AGPL in prod deps)

Layer	Tool	Status
Type safety	TypeScript (`tsc --noEmit`, strict)	✅
Unit / contract tests	Vitest — 63 passing (schemas · spend cap · 402-parse · EIP-3009 sign · receipts · degrade)	✅
Protocol "E2E" (smoke)	MCP stdio smoke — cold-start lists 8 tools / 2 resources / 1 prompt + a live free call	✅
Protocol conformance	MCP Inspector (`@modelcontextprotocol/inspector`) — `tools/list` · `resources/list` · `prompts/list`	✅
Static analysis (SAST)	CodeQL (`javascript-typescript`, security-and-quality)	✅
Dependency updates (SCA)	Dependabot (npm + github-actions, weekly) + `npm audit`	✅
Secret scanning	TruffleHog (verified-only)	✅
Publish readiness	`npm pack` / `npm publish` dry-run gate (provenance publish is manual)	✅

No Playwright / Lighthouse — there is no browser surface to drive or audit. The equivalent guarantee is the stdio smoke + Inspector conformance above, both run in CI on every push and PR. Also see make help for the full target list.

⚙️ Configuration

Env	Default	Meaning
`FOOTBALL_DATA_KEY`	—	football-data.org key (free data tools)
`ODDS_API_KEY`	—	the-odds-api.com key (odds)
`CUPORACLE_PRIVATE_KEY`	—	payer wallet key for `wc_edge` (fund cents only)
`CUPORACLE_MAX_SPEND`	`0.50`	per-session USDC spend cap
`CUPORACLE_NETWORK`	`eip155:1776`	`eip155:1776` mainnet · `eip155:1439` testnet
`LINELOCK_URL`	`https://linelock.edycu.dev`	upstream edge provider

🧩 Extend it (add your own sport)

Each tool is { name, config, handler } (src/tools/). To add, say, a cricket server: copy a free tool, swap the data client in src/data/, register it in src/tools/index.ts. The x402 client (src/x402/) is sport-agnostic — reuse it to sell any premium signal. PRs welcome.

⚠️ Honest limitations

wc_edge depends on LineLock's /api/edge (a disclosed sibling project). If it's down, wc_edge degrades to free odds — it never fabricates an edge.
Free-tier data APIs cap request rates → 60s cache + committed snapshots (always labeled [snapshot]).
The payer keystore holds a real (tiny) balance. Spend caps default low; fund only cents. Windows keystore paths are documented, not hardened.

📄 License

MIT. "Football data provided by the Football-Data.org API."

Available Tools

8 tools

receipt_verifyVerify payment receiptA

Read-only

Verify an x402 USDC payment receipt on Injective EVM: reads the tx over RPC, decodes the USDC transfer, and returns block time, amount, payer and payee with an explorer link. Free.

ParametersJSON Schema

Name	Required	Description	Default
`txHash`	Yes	The receipt transaction hash to verify.
`network`	No	CAIP-2 network (default eip155:1776 mainnet).

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`asset`	Yes
`payee`	Yes
`payer`	Yes
`status`	Yes
`txHash`	Yes
`network`	Yes
`block_time`	Yes
`amount_usdc`	Yes
`block_number`	Yes
`explorer_url`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Annotations indicate readOnlyHint=true and openWorldHint=true. The description adds transparency by detailing the tool reads a transaction over RPC and decodes USDC transfers, which is consistent with read-only behavior. It does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that efficiently communicates the tool's purpose and behavior, with no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has an output schema, the description does not need to explain return values. It covers transaction type, process steps, and result fields. With full parameter schema coverage and two simple parameters, the description is complete.

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

Parameters3/5

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

Input schema coverage is 100% with descriptions for both parameters. The description adds little beyond the schema, only mentioning the default network (eip155:1776) which aligns with the enum. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool verifies an x402 USDC payment receipt on Injective EVM, specifying the process (reads RPC, decodes transfer) and output (block time, amount, payer, payee, explorer link). This distinguishes it from unrelated sibling tools like wc_bracket or wallet_fund_guide.

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

Usage Guidelines4/5

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

The description implies usage for verifying receipts and mentions 'Free.', providing clear context. However, it does not explicitly state when not to use the tool or suggest alternatives, though sibling tools are unrelated.

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

wallet_fund_guideFund the agent wallet (CCTP)A

Read-only

Return a CCTP runbook to move USDC from Base/Arbitrum/Ethereum onto Injective so the agent can pay for wc_edge. Routes the real moves to the InjectiveLabs/mcp-server (account_balances, cctp_supported_chains, cctp_attestation_status, cctp_mint). Free, read-only.

ParametersJSON Schema

Name	Required	Description	Default
`chain`	No	Source chain that holds your USDC (default: base).

Output Schema

ParametersJSON Schema

Name	Required	Description
`steps`	Yes
`destination`	Yes
`source_chain`	Yes
`runbook_markdown`	Yes
`usdc_on_injective`	Yes
`source_cctp_domain`	Yes
`injective_mcp_tools`	Yes

TDQS

A4.1/5.0

Behavior4/5

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

Annotations show readOnlyHint=true; description adds that it is free and read-only, and routes to other tools, providing useful context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no wasted words, well-structured and front-loaded with core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given output schema exists, description covers main functionality and routing, but misses prerequisites (e.g., having USDC on source chain).

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

Parameters2/5

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

The description mentions only Base/Arbitrum/Ethereum, while the enum includes five more chains, creating a contradiction that may mislead agents.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns a CCTP runbook for moving USDC from specific chains to Injective to fund the agent wallet for wc_edge, distinguishing it from sibling tools.

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

Usage Guidelines4/5

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

The description indicates use when the agent needs to fund wc_edge, but does not explicitly list when not to use or alternatives, though sibling tools are different.

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

wc_bracketWorld Cup knockout bracketA

Read-only

Current knockout bracket state (Round of 16 → Final) with scores and winners where known. Free.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`ascii`	Yes
`rounds`	Yes
`snapshot`	Yes
`attribution`	Yes

TDQS

A3.9/5.0

Behavior3/5

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

Annotations already declare readOnlyHint and openWorldHint, so safety profile is clear. The description adds 'where known' which signals that some match results may be missing, a useful behavioral detail. However, it does not add significant behavioral context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with key information about the bracket state. No superfluous text; every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters, presence of output schema, and annotations, the description is complete. It explains what the tool returns (bracket state, scores, winners) without needing more detail.

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

Parameters4/5

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

No parameters defined, so schema coverage is 100%. The description does not need to add parameter semantics. Baseline 4 for zero parameters applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool provides the current knockout bracket state from Round of 16 to Final, including scores and winners. This distinguishes it from siblings like wc_fixtures (all matches) and wc_live (live updates).

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives. The description only says 'Free' which hints at no cost but does not provide context or exclusions. Sibling tools exist (e.g., wc_fixtures, wc_live) with no comparison.

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

wc_edgeBuy a vetted edge (pays x402)A

Buy a CLV-audited edge + conviction ladder for one match from LineLock. The agent pays ~0.05 USDC ITSELF via x402 (spend-capped) and returns the edge plus the on-chain receipt tx to cite. Degrades to free odds if the upstream is down; never fabricates an edge or receipt. Use dry_run:true to prove the quote-parse + spend-cap path without paying.

ParametersJSON Schema

Name	Required	Description
`dry_run`	No	If true, parse the recorded 402 quote and enforce the spend cap WITHOUT paying (proof path). No receipt is produced. Default false (attempts a real, funds-gated purchase).
`matchId`	Yes	football-data match id (from wc_fixtures).
`maxSpend`	No	Per-call USDC ceiling for this purchase (e.g. 0.05). Never exceeds the session cap.

TDQS

A4.4/5.0

Behavior5/5

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

The description adds significant behavioral context beyond annotations: payment mechanism (x402 with spend cap), cost (~0.05 USDC), return includes receipt, degradation to free odds, and guarantee against fabrication. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (3 sentences), front-loaded with the core action, and every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers key aspects: what it does, cost, failure mode, dry run option, and data source (matchId from wc_fixtures). Missing details about the output format, but constraints (no output schema) justify minor gaps.

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

Parameters3/5

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

Schema coverage is 100%, so descriptions already explain parameters. The tool description adds minimal extra meaning, e.g., clarifying dry_run purpose, but does not substantially increase agent understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses specific verb 'Buy' and resource 'CLV-audited edge + conviction ladder' from 'LineLock', clearly distinguishing it from sibling tools like wc_fixtures or wc_odds.

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

Usage Guidelines4/5

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

The description explains when to use dry_run for testing, and mentions degradation behavior, but does not explicitly state when not to use the tool or provide direct alternatives.

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

wc_fixturesWorld Cup fixturesA

Read-only

List FIFA World Cup 2026 fixtures. Pass a date (YYYY-MM-DD) for that day, or omit to get the next upcoming matches (soonest first). Free.

ParametersJSON Schema

Name	Required	Description	Default
`date`	No	Optional day filter (UTC), e.g. 2026-07-14. Omit for the next upcoming fixtures.

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes
`matches`	Yes
`snapshot`	Yes
`attribution`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds value by noting the 'soonest first' ordering and the tool being 'Free', without contradicting annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short, front-loaded sentences with no extraneous information. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with one optional parameter and an output schema, the description covers all key behaviors: date filtering, default response, and ordering. Output format is handled by the schema.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. The description adds meaning by stating the default behavior when date is omitted ('next upcoming') and the format hint (YYYY-MM-DD), going beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List FIFA World Cup 2026 fixtures' with a specific verb and resource, and distinguishes from sibling tools like wc_bracket and wc_live by focusing on fixture listing.

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

Usage Guidelines4/5

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

It explains when to pass a date and what happens when omitted ('next upcoming matches'), but lacks explicit comparison or when-not-to-use advice. Still clear enough for an AI agent.

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

wc_liveWorld Cup live scoreA

Read-only

Live score, minute and status for one World Cup match by id. Reflects half-time / full-time / in-play state. Free.

ParametersJSON Schema

Name	Required	Description	Default
`matchId`	Yes	football-data match id (from wc_fixtures).

Output Schema

ParametersJSON Schema

Name	Required	Description
`away`	Yes
`home`	Yes
`score`	Yes
`minute`	Yes
`status`	Yes
`matchId`	Yes
`snapshot`	Yes
`attribution`	Yes
`kickoff_utc`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description does not need to repeat those. It adds minor context by mentioning 'free' and game states, but does not detail behavior like data freshness, rate limits, or required permissions. With annotations covering safety, a score of 3 is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences (18 words) that front-load the core action: 'Live score, minute and status for one World Cup match by id.' Every word adds value, no fluff or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the single parameter, clear schema descriptions, readOnlyHint, and an output schema (not shown), the description adequately covers what the tool returns (score, minute, status, states). It mentions 'free' as a minor trait. For a simple live-score retrieval tool, it is sufficiently complete, though lacking explicit mention of authentication or rate limits (likely not required due to openWorldHint).

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

Parameters3/5

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

The input schema already describes matchId as 'football-data match id (from wc_fixtures)' with constraints. The description repeats 'by id' but adds no new meaning. With 100% schema coverage, baseline is 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it provides live score, minute, and status for a single World Cup match by ID. It distinguishes itself from siblings like wc_fixtures (which likely lists matches) by specifying 'for one World Cup match by id' and mentioning game states (half-time, full-time, in-play).

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

Usage Guidelines3/5

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

The description implies usage for retrieving live data for one match but does not explicitly state when to use this tool versus alternatives (e.g., wc_fixtures for fixtures, wc_bracket for bracket). No exclusions or alternative suggestions are provided, leaving the agent to infer from sibling names.

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

wc_oddsWorld Cup consensus oddsA

Read-only

Consensus head-to-head odds (mean decimal price across books) and de-vigged implied probabilities for one match. Free. Odds appear only once both teams are known.

ParametersJSON Schema

Name	Required	Description	Default
`matchId`	Yes	football-data match id (from wc_fixtures).

Output Schema

ParametersJSON Schema

Name	Required	Description
`h2h`	Yes
`implied`	Yes
`matchId`	Yes
`snapshot`	Yes
`away_team`	Yes
`home_team`	Yes
`books_count`	Yes
`snapshot_utc`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Annotations indicate read-only and open-world hints; the description adds that the tool is free and data is conditional on teams being known, providing valuable behavioral context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise: two sentences that front-load the core purpose and key constraints (free, timing) without any filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple input schema (1 param) and presence of an output schema, the description covers the key aspects: what data is returned, that it's free, and when data is available.

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

Parameters3/5

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

The single parameter matchId is fully documented in the schema with description, and the description does not add further semantics beyond restating 'for one match'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it provides consensus head-to-head odds and de-vigged implied probabilities for a single match, using specific terms that distinguish it from sibling tools like wc_fixtures or wc_edge.

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

Usage Guidelines4/5

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

The description says it's free and odds appear only once teams are known, implying when to use; but it doesn't explicitly state when not to use or list alternative tools, though sibling context helps.

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

wc_spend_ledgerAgent spend ledgerA

Read-only

The agent's own purchase history: every wc_edge attempt with amount and receipt tx, plus the session total against the spend cap. Free, read-only — the audit trail for autonomous spend.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`entries`	Yes
`cap_usdc`	Yes
`paid_count`	Yes
`remaining_usdc`	Yes
`session_total_usdc`	Yes

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true; description adds that it is 'Free' and details what data it returns (every attempt, receipt tx, session total). No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence effectively packs all key information: purpose, contents, characteristics (free, read-only), and context (audit trail). No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has an output schema (not shown but present) and no parameters, the description fully explains what the tool returns and its purpose. Complete for an audit/log tool.

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

Parameters4/5

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

No parameters (empty input schema), so baseline is 4. Description correctly implies no inputs needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description states it is the agent's purchase history, listing specific contents (wc_edge attempts with amount and receipt tx, session total against spend cap). Clearly distinguishes from siblings like receipt_verify or wallet_fund_guide.

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

Usage Guidelines4/5

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

States it is a free read-only audit trail for autonomous spend, implying when to use (to review spending). Does not explicitly mention 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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

8 tool updatesv1.0.0Jul 17, 2026
- First observedreceipt_verify
- First observedwallet_fund_guide
- First observedwc_bracket
- First observedwc_edge
- First observedwc_fixtures
- First observedwc_live
- First observedwc_odds
- First observedwc_spend_ledger

Install Server

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

TDQS

A4.2/5.0

Scored 2026-07-17 04:51 across 8 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: payment receipt verification, wallet funding guide, bracket state, edge purchasing, fixtures listing, live scores, odds, and spend ledger. No two tools overlap in functionality.

Naming Consistency3/5

Tool names mix 'wc_' prefix for World Cup tools with non-prefixed names like 'receipt_verify' and 'wallet_fund_guide'. Within the wc_ group, naming patterns vary (bracket, edge, fixtures, live, odds, spend_ledger), lacking a consistent verb_noun structure.

Tool Count5/5

With 8 tools covering both World Cup data (fixtures, live scores, odds, bracket) and payment integration (receipt verification, funding guide, edge purchase, spend ledger), the count is well-scoped for the server's purpose.

Completeness4/5

The tool set covers essential operations for World Cup prediction and edge purchasing: viewing fixtures, live scores, odds, bracket, purchasing edges with payment verification, and a spend ledger. Minor gaps like missing match detail or team stats are acceptable for the niche.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

Crypto Prices Mcp
io.github.varvararatta
Unlock the power of real-time cryptocurrency data with our Crypto Price Insights MCP server.
Cryptocurrency Finance
2
mcp A
com.everstake
MCP server connecting AI agents to non-custodial staking data across 130+ networks.
Blockchain Cryptocurrency
1111
UnifAPIOAuth
com.unifapi
Hosted MCP server for live public-data APIs and Skills for AI agents.
Open Data Search AI & Machine Learning
2
crypto-defi-mcpOAuth
com.thenextgennexus
MCP server giving AI agents one-connection access to crypto & DeFi data: DeFi protocol TVL, stableco
Cryptocurrency Finance Blockchain
2

Related MCP Servers

wc26-mcp
jordanlyall
A
license
A
quality
C
maintenance
MCP server for FIFA World Cup 2026 data: matches, teams, venues, city guides, fan zones, visa info, injuries, odds, standings, bracket, and historical matchups. 18 tools, zero external API dependencies.
Updated 2 days ago (2026-09-09 12:49 UTC)
18
203
34
MIT
ScoutAgent
Blockchain Sports AI & Machine Learning
0xCaptain888
A
license
Not graded
quality
F
maintenance
MCP server that enables AI workflows to query on-chain AI Scout agents, leaderboards, and prediction markets on X Layer for the World Cup.
Updated 4 months ago (2026-05-22 08:04 UTC)
MIT
World Cup 2026 MCP Server
Sports Open Data
abaiii168
A
license
A
quality
F
maintenance
Free MCP server for the World Cup 2026 Tour public schedule API. It enables AI assistants to fetch the 2026 FIFA World Cup schedule, next match, match by ID, and dataset JSON-LD without an API key.
Updated 3 months ago (2026-06-15 10:24 UTC)
5
1
MIT
wcprediction-mcp
Sports RAG Systems
ajaleelp
F
license
Not graded
quality
B
maintenance
MCP server for a World Cup 2026 prediction game assistant, providing tools for live game data via PostgreSQL and semantic search over football articles via RAG.
Updated 2 months ago (2026-06-27 22:55 UTC)
-

🧑‍⚖️ Notes for judges — reproduce in < 5 min

💡 Why this exists

🧰 Tools

🚀 Quickstart

1. Get keys

2. Add to your harness

3. Ask

🛠️ Injective technologies used

🔄 The autonomous-payment loop (wc_edge)

💰 Funding the agent wallet

🧑‍💻 Development

🧪 Engineering harness & CI

⚙️ Configuration

🧩 Extend it (add your own sport)

⚠️ Honest limitations

📄 License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

🔄 The autonomous-payment loop (`wc_edge`)