SiteCheck Agent Intel & Dev

Live sports from SofaScore. Without an event ID: every

dev_sofascore_live

Read-only

Live sports from SofaScore. Without an event ID: every match in play for a sport (football, basketball, tennis, ice-hockey, baseball, cricket, esports...) with event ID, competition, teams, live score and status. With an event ID: score by period, venue, incidents (goals, cards, substitutions with minute), live and pre-match odds by market, and team statistics (possession, xG, shots...). Price: $0.002 in USDC per successful call, paid with x402 (Base, Solana or Arc); failed calls are not charged.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "dev_sofascore_live"
  }
}

Input Schema

Name	Required	Description
`event`	No	SofaScore event ID for one match's incidents, odds and statistics
`limit`	No	Live list only: matches, 1 to 200 (default 50)
`sport`	No	football, basketball, tennis, ice-hockey, baseball, american-football, volleyball, handball, cricket, rugby, esports, table-tennis, futsal, mma (default football)
`competition`	No	Live list only: competition or country contains this text

Output Schema

Name	Required	Description	Default
`live`	No
`sport`	No
`source`	No
`results`	No
`checkedAt`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered; the description adds genuinely non-derivable context: a $0.002 USDC charge per successful call via x402 on Base, Solana or Arc, with failed calls not billed. That payment/auth behavior is exactly the kind of thing an agent needs before invoking. It stops short of explaining payment negotiation 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.

Conciseness4/5

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

The two modes are front-loaded in a single readable structure and the pricing caveat is placed last where it belongs. The long parenthetical sport list and the '(...)' enumerations of returned fields add length, though they carry real information rather than filler.

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?

With an output schema present, the description need not document return shapes, and it still summarizes them usefully while covering both invocation modes and cost. The only residual gap is operational detail around x402 payment flow and failure behavior, which is a minor omission for a read-only data 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?

Schema coverage is 100%, so the baseline is 3; the description earns above that by explaining the behavioral consequence of `event` (period scores, venue, incidents, odds, team stats) versus its absence (live list), and by tying `limit` and `competition` implicitly to the list mode, which the schema also states.

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 names a specific verb and resource (live sports data from SofaScore) and then splits the tool's two distinct behaviors explicitly: live match listing without an event ID, and per-match detail with one. The enumerated payload (incidents, odds by market, xG/possession statistics) tells an agent exactly what it gets, distinguishing it from sibling scoreboard tools like dev_espn_soccer_scoreboard or dev_flashscore.

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 'Without an event ID' / 'With an event ID' framing gives an agent a clear decision rule for the two modes. What is missing is any exclusion or routing advice against the many sibling sports tools (ESPN scoreboards, Flashscore, The Odds API) that overlap in coverage.

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

All SiteCheck Agent Intel & Dev tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?