スポーツベッティング初のMCPサーバー。 あらゆるAIエージェントに、NBA、NHL、NCAAB、MLBの予想、オッズ、試合分析、パフォーマンス追跡へのライブアクセスを提供します。
mcp-name: io.github.seang1121/sports-betting-mcpMCP互換のAIエージェントをライブスポーツベッティング分析システムに接続します。すべての予想は試合開始前に記録され、最終スコアと照合されます。都合の良いデータだけを抽出することはありません。
指標 | 値 |
対象スポーツ | NBA, NHL, NCAAB, MLB |
ベットタイプ | マネーライン, スプレッド, トータル |
予想ソース | 12エージェントのコンセンサスモデル |
予想総数 | 3,859件以上（解決済み） |
プラットフォームユーザー | 30 |
ツール | 12個のMCPツール |
認証 | APIキー (X-API-Keyヘッダー) |
スポーツ | 予想数 | 勝利数 | 勝率 |
NBA | 1,267 | 762 | 60.1% |
NHL | 1,148 | 656 | 57.1% |
NCAAB | 1,149 | 549 | 47.8% |
MLB | 283 | 109 | 38.5% (2026年4月開始) |
すべての結果は get_win_rate ツールを使用してリアルタイムで照会可能です。数値は試合ごとに更新されます。
Related MCP server: sports-data-mcp-server
pip install sports-betting-mcpMCP設定（Claude Desktop、Cursor、Windsurf、Claude Codeなど）に以下を追加してください：
{
"mcpServers": {
"sports-betting": {
"command": "sports-betting-mcp",
"env": {
"SPORTS_BETTING_API_URL": "https://sportsbettingaianalyzer.com",
"SPORTS_BETTING_API_KEY": "your_api_key"
}
}
}
}変数 | 必須 | 説明 |
| はい | 認証用のAPIキー |
| いいえ | APIベースURL (デフォルトは |
Model Context Protocol をサポートするすべてのクライアント：
クライアント | ステータス |
Claude Desktop | 完全対応 |
Cursor | 完全対応 |
Windsurf | 完全対応 |
Claude Code (CLI) | 完全対応 |
任意のMCPクライアント | stdioトランスポート経由で完全対応 |
12個のツール。すべての呼び出しは、AIエージェントが推論、表示、または実行できる構造化データを返します。
ツール | 機能 |
| 信頼度スコアとエッジの内訳を含むすべてのAI予想（スポーツでフィルタリング可能） |
| その日最も信頼度の高い予想 |
| 現在未解決で、まだ進行中の予想 |
| 最近解決された予想（勝敗結果付き） -- 実績の確認用 |
| 試合の12エージェントによる完全分析：コンセンサス予想 + エッジの内訳 |
ツール | 機能 |
| 今日の試合のライブマネーライン、スプレッド、トータル |
| マルチエージェントシステムからのアクティブなアラート（ラインの動き、怪我の影響） |
ツール | 機能 |
| スポーツおよびベットタイプ別の勝率 |
| モデルのパフォーマンス：予想総数、直近20試合の勝率、信頼度ティア別の内訳 |
| 勝率によるユーザーランキング |
| ヘルスチェック -- アップタイム、データベース、スケジューラーのステータス |
各試合はマルチエージェントパイプラインを通じて処理されます：
12の専門エージェントが、勢い、対戦カード、怪我、休息、移動、一般のベッティング率、プロの資金の動き、歴史的トレンドなどを個別に評価します。
コンセンサスエンジンが12の意見を統合し、信頼度スコア付きの単一の予想を作成します。
エッジ計算が、モデルの暗黙の確率と現在の市場ラインを比較します。
予想は試合開始前に記録され、最終スコアと照合されます。事後的な編集は行われません。
信頼度スコアとエッジの内訳はすべての予想レスポンスに含まれているため、AIエージェントは推奨の根拠をフィルタリング、ランク付け、または説明できます。
APIには無料（すべてのAPIキー）とプロ（承認済みアクセス）の2つのティアがあります。
エンドポイント | メソッド | 機能 |
| GET | 信頼度スコア付きの今日のAI予想 |
| GET | FanDuel/BetMGMからのライブオッズ |
| GET | スポーツおよびベットタイプ別の勝率内訳 |
| GET | Covers.comからのアクティブな怪我人レポート |
| GET | 重要なラインの動き（プロの資金のシグナル） |
| GET | オッズのスナップショットとAI予想フラグ付きの今日の全スケジュール |
| GET | スポーツ、ベットタイプ、信頼度ティア別のモデルパフォーマンス |
| GET | リーダーボード — AI対人間の勝率 |
| GET | RSSソースからのスポーツニュースフィード |
| GET | 現在保留中（未解決）の予想 |
エンドポイント | メソッド | 機能 |
| GET | 完全な構造化予想 — 完全なエッジ内訳、プラス/マイナスのエッジ、根拠、スコアカード、対戦相手のオッズ、ラインの動き、品質フラグ |
| POST | 試合のオンデマンド12エージェント分析 — チーム名を送信し、完全なコンセンサスを取得 |
| GET | 勝敗、実際のスコア、利益、主要な貢献エッジを含む解決済み予想 |
| GET | 終値価値（CLV）分析 — ラインは有利に動いたか？ |
| GET | チーム名で勝敗記録を検索 |
| POST | 予想を記録（フリップフラグ、予想ソース追跡をサポート） |
| POST | 最大20件の予想を一括記録（予想ごとの成功/重複/エラー状態） |
| GET | 予想履歴 — 保留中、解決済み、勝率 |
| POST | Nimrodベットスリップ画像を生成 |
| POST/GET/DELETE | 予想イベントのWebhookを登録 |
| GET | すべての予想のフェード/フリップデータを含む — 対戦相手、ライン、オッズ |
/xk/full からのすべての予想には以下が含まれます：
{
"ai_pick": "Lakers -5.5",
"ai_verdict": "STRONG BET",
"ai_probability": "65%",
"ai_reasoning": "Lakers defense ranks top 5, opponent on B2B...",
"edges": [13 individual edge factors],
"top_edges": [top 5 positive],
"negative_edges": [top 3 negative],
"scorecard": [3 model scores],
"fade_pick": "Celtics +5.5",
"fade_team": "Celtics",
"fade_odds": "+105",
"fade_note": "Betting AGAINST the AI — take Celtics +5.5",
"line_moved": true,
"flags": ["line_moved"],
"data_quality": "good"
}予想を記録する際、pick_source を含めて意思決定タイプを追跡します：
model_agree — AIの予想に従う
flip — AIに逆らう（フェード）
manual_override — カスタム予想
これにより、時間の経過とともにモデル同意予想とフリップ予想の勝率比較が可能になります。
X-API-Key ヘッダーで認証します。sportsbettingaianalyzer.com で無料キーを取得してください。プロアクセスには管理者の承認が必要です。
コンポーネント | 技術 |
ランタイム | Python 3.10+ |
プロトコル | MCP (Model Context Protocol) |
トランスポート | stdio |
ビルド | Hatchling |
配布 | PyPI ( |
バックエンド | Flask + SQLite |
分析 | 12エージェントのコンセンサスパイプライン |
スポーツ | NBA, NHL, NCAAB, MLB |
Mortgage Rates MCP Server -- 17の貸し手、13のツール、リアルタイムの住宅ローン金利インテリジェンス
March Madness Bracket Predictor -- 5モデルアンサンブル、14年間のバックテスト、77%の精度、2026年の優勝者を正しく予測
Agent Command Center -- MCPサーバー、エージェント、フック、cronジョブ、リポジトリを自動検出するダッシュボード
Run full multi-agent analysis on a specific game. Uses 12 specialized agents to evaluate every angle.
Args: sport: Sport — 'nba', 'nhl', 'ncaab', or 'mlb' game_id: Game ID from the get_live_odds tool
Returns: Complete multi-agent analysis with consensus pick, confidence, and edge breakdown.
| Name | Required | Description | Default |
|---|---|---|---|
| sport | Yes | ||
| game_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey all behavioral traits. It mentions '12 specialized agents' and the return structure (consensus, confidence, edge), but omits details like execution time, failure modes, or required permissions. This is 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: a one-sentence purpose, followed by two bullet-like lines for parameters and return. Every word adds value, with no fluff or repetition. Front-loading the core action makes it easy to scan.
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 two simple required parameters, no nested objects, and an output schema, the description provides sufficient context. It explains the input sources and output structure. The sibling tools list confirms this is the only deep analysis tool, so the description stands alone well.
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 provides no descriptions (0% coverage), so the description adds significant value by clarifying the 'sport' allowed values and sourcing 'game_id' from get_live_odds. This meaningfully aids correct parameter usage beyond the raw 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 uses a specific verb ('analyze') and clearly identifies the resource ('game'). It distinguishes from sibling tools (get_live_odds, get_todays_picks, etc.) by highlighting the multi-agent analysis scope, leaving no ambiguity about the tool's unique function.
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 states the purpose and references the source of game_id ('from the get_live_odds tool'), which guides correct invocation. However, it does not include when-not-to-use or alternative tools for similar tasks, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get active alerts from the multi-agent system (line movements, injury impacts, etc.).
Returns: List of current alerts with severity and details.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It indicates the tool retrieves active alerts and returns a list with severity and details, but does not mention side effects or safety profile. Adequate for a simple 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?
Two sentences, concise and front-loaded. Every sentence adds value with 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?
Tool has no parameters and output schema exists; description suffices by explaining return content. Could clarify what 'active' means, but overall complete for a simple retrieval 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?
No parameters in schema; schema coverage is 100%. Baseline for 0 parameters is 4, description adds no param info but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Get' and the resource 'active alerts' with specific examples like line movements and injury impacts. Distinguishes from siblings like get_system_status and get_model_stats.
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?
No explicit guidance on when to use this tool versus alternatives. Usage is only implied, with no conditions or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recently completed (resolved) picks with results.
Args: limit: Number of recent completed picks to return (default 20, max 50)
Returns: List of completed picks with results (W/L) and details.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It accurately describes a read-only operation returning completed picks with results, which is transparent. However, it could be more explicit about ordering or time range (e.g., 'recently' is vague).
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 two sentences plus a structured Args/Returns section. Every sentence adds value without extraneous information.
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 and the presence of an output schema (not shown), the description provides sufficient context: it lists the output as 'List of completed picks with results (W/L) and details'. This is adequate for understanding the return value without being overly detailed.
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 adds significant meaning beyond the input schema: it explains the limit parameter's purpose (number of recent completed picks), default (20), and maximum (50). The schema only shows type and default, so the description provides essential constraints and context.
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 gets 'recently completed (resolved) picks with results', which distinguishes it from siblings like get_pending_picks (unresolved) and get_todays_picks (today's picks, potentially not completed).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for recently completed picks but does not explicitly provide when-to-use or when-not-to-use guidance compared to alternatives. The context from sibling names helps, but no direct exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the pick leaderboard showing user rankings by win rate.
Returns: Leaderboard with rankings, win rates, and total picks per user.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only states basic return fields (rankings, win rates, total picks). It does not disclose read-only nature, data freshness, ordering, or any side effects, leaving a gap for an agent assessing safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains what the tool returns (leaderboard with rankings, win rates, total picks). With an output schema present, the description does not need to detail return structure further, though ordering or scope could be added.
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 zero parameters, so the description has no need to add parameter info. The baseline score of 4 applies per guidelines for 0-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a pick leaderboard with user rankings by win rate, distinguishing it from siblings like get_win_rate (individual) and get_top_pick.
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?
No explicit guidance on when to use this tool vs alternatives; usage is implied from the description but no when-not or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current live odds for a sport from FanDuel and BetMGM.
Args: sport: Sport to fetch — 'nba', 'nhl', 'ncaab', or 'mlb'
Returns: Live moneyline, spread, and total odds for today's games.
| Name | Required | Description | Default |
|---|---|---|---|
| sport | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It states the tool retrieves 'live odds' and returns specific odds types (moneyline, spread, total), but does not disclose behavioral traits like rate limits, authorization requirements, or whether the operation is read-only. The description implies a read operation but lacks explicit safety guarantees.
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 front-loaded purpose sentence and an optional Args section. However, the Args format could be integrated into the main text for brevity; the current structure is still 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?
Given the presence of an output schema, the description need not detail return values, but it usefully summarizes what the odds include. For a simple tool with one parameter, the description covers essential aspects (sources, sport list, return type), though it omits edge-case behavior like handling invalid sports or empty games.
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% description coverage, leaving the parameter 'sport' underspecified. The description compensates by listing valid sport values ('nba', 'nhl', 'ncaab', 'mlb'), which adds essential meaning beyond the schema's type constraint.
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 verb ('Get'), resource ('live odds'), and data sources ('FanDuel and BetMGM'), distinguishing it from sibling tools like get_todays_picks or get_pending_picks which deal with picks rather than odds.
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?
No guidance on when to use this tool vs alternatives (e.g., when to use get_live_odds vs get_todays_picks). No explicit conditions or exclusions provided, leaving the agent to infer usage context from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get model performance statistics — win rates by confidence level, total picks, discipline.
Returns: Model stats including total picks, last 20 win rate, and confidence tier breakdown.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the tool returns stats but does not disclose behavioral traits such as whether data is live or cached, any authentication requirements, or performance implications. For a read-only tool with no parameters, the absence of such detail is acceptable but not ideal.
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 short (two sentences) and front-loaded with the core purpose. However, the 'Returns:' line is redundant with the first sentence and could be merged for greater conciseness.
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 parameters, clear output), the description adequately lists the returned metrics. An output schema exists, so deeper details are delegated there. Still, a brief mention of the output schema would improve 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 tool has zero parameters, and the input schema is fully covered (100%). The description adds no parameter semantics, but the baseline for zero parameters is 4. No further information is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves model performance statistics, including win rates by confidence level, total picks, and discipline. It is specific about the resource and metrics, but does not differentiate from the sibling tool get_win_rate, which likely provides a simpler overall win rate.
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 no guidance on when to use this tool versus alternatives like get_win_rate or get_completed_picks. It lacks any context for appropriate usage scenarios or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all currently unresolved (pending) picks waiting for game results.
Returns: List of pending picks with pick details and how long they've been pending.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses the return type and content (list of pending picks with details and pending duration). It implies a read-only operation without side effects, which is adequate for the tool's simplicity.
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 sentences, front-loading the action 'Get all currently unresolved (pending) picks'. No redundant information is present.
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 zero parameters and the existence of an output schema (which covers return values), the description is complete. It explains the purpose and return data adequately without needing further elaboration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100%. The description adds no parameter information, which is acceptable as there are none to document.
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 retrieves all currently unresolved (pending) picks waiting for game results. It distinguishes itself from sibling tools like get_completed_picks by specifying 'pending' status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for pending picks but does not explicitly provide guidance on when to use this tool versus siblings like get_completed_picks or get_todays_picks. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Health check — uptime, database status, API key status, and scheduler health.
Returns: Current system status including uptime, DB connectivity, and service health.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It lists what the tool returns (uptime, DB connectivity, service health), which gives some behavioral insight. However, it does not mention whether the operation is read-only, idempotent, or any side effects, leaving gaps in transparency.
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 sentences, clearly stating the purpose and the return information. It is front-loaded with the key purpose. Slight improvement could be a more structured list for the return values, but it remains 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?
Given the tool has no parameters and an output schema exists, the description adequately covers the return items (uptime, DB status, etc.). It is complete enough for an agent to understand what the tool does and what to expect.
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?
There are zero parameters, and the input schema has no properties with descriptions. The rule sets a baseline of 4 for 0 parameters, and the description does not need to add parameter information since there are none.
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 'Health check' and specifies what it checks: uptime, database status, API key status, and scheduler health. This precisely identifies the verb (get) and resource (system status), and distinguishes it from sibling tools that are unrelated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for checking system health, and since there are no other health-related sibling tools, the context is clear. However, it does not explicitly state when to use or not use this tool, which would improve guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get today's AI-generated picks with confidence and edge scores.
Args: sport: Filter by sport — 'nba', 'nhl', 'ncaab', 'mlb', or 'all' (default)
Returns: List of picks with pick name, bet type, line, odds, confidence, and edge score.
| Name | Required | Description | Default |
|---|---|---|---|
| sport | No | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes a read operation ('Get'), but does not explicitly state that it is read-only, safe, or any limits such as rate limiting or authentication requirements. However, the behavior is straightforward and not misleading.
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 no wasted words, front-loading the purpose in the first sentence. It includes structured Args and Returns sections. However, it could be slightly more streamlined by integrating the default value into the purpose sentence.
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 parameter, no output schema, no nested objects), the description is fairly complete. It details the return fields (pick name, bet type, line, odds, confidence, edge score). It lacks information on pagination or limits, but these are not critical for this type of tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description lists the acceptable values for the 'sport' parameter: 'nba', 'nhl', 'ncaab', 'mlb', or 'all' (default). This adds significant meaning beyond the schema, though it does not mention case sensitivity or error handling.
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: 'Get today's AI-generated picks with confidence and edge scores.' It specifies the verb 'Get', the resource 'today's AI-generated picks', and the included scores. It is distinct from sibling tools like get_top_pick (singular) and get_completed_picks (past).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for today's picks via the filter by sport, but provides no explicit guidance on when to use this tool versus alternatives (e.g., get_top_pick for a single pick, get_completed_picks for past picks). No exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the single highest-confidence pick available today.
Args: sport: Filter by sport — 'nba', 'nhl', 'ncaab', 'mlb', or 'all' (default)
Returns: The best pick with full analysis details.
| Name | Required | Description | Default |
|---|---|---|---|
| sport | No | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It discloses that the tool returns the best pick with analysis details, indicating a read operation. However, it lacks information on caching, freshness, or required permissions, which is acceptable for a simple tool but not thorough.
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 the core purpose in the first line followed by a succinct parameter and return value explanation. No extraneous information is present.
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 parameter, no output schema), the description is minimally adequate. It explains the parameter and return type at a high level but lacks details on the returned pick structure or analysis format. For a tool this straightforward, it suffices.
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 adds essential meaning to the sole parameter 'sport', listing allowed values ('nba', 'nhl', 'ncaab', 'mlb', 'all') and the default 'all'. This compensates for the 0% schema coverage completely.
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 retrieves the single highest-confidence pick available today. The verb 'Get' and resource 'the single highest-confidence pick' are specific, and it distinguishes from sibling 'get_todays_picks' which likely returns multiple picks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining the top pick, but does not explicitly state when to use this tool versus alternatives like get_todays_picks or analyze_game. No guidance on exclusions or prerequisites is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the betting analyzer's documented win rate with real resolved picks.
Args: period: Time period — 'all', '30d', or '90d'
Returns: Win rate, record, and breakdown by sport.
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | all |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses it retrieves documented win rate with resolved picks, implying a read operation. No contradictions, but lacks details on potential rate limits or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with structured Args/Returns sections. Every line is necessary; no fluff. Exceptionally concise.
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 low complexity and one parameter, description covers purpose, parameter options, and return structure. Output schema exists but isn't shown; description still provides key fields (win rate, record, breakdown). Missing guidance on when to use among siblings.
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 one parameter 'period' with only type and default. Description adds allowed values 'all', '30d', '90d', which is helpful. Without schema description coverage, this compensates well.
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 gets the betting analyzer's documented win rate with real resolved picks. It uses a specific verb (get) and resource (win rate), and distinguishes from siblings like get_model_stats or get_leaderboard.
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?
No guidance on when to use this tool versus alternatives like get_model_stats or get_leaderboard. The description only states what it does without providing context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_alertsget_completed_picksget_injury_reportget_leaderboardget_line_movementget_model_statsv1.0.0analyze_gameget_injury_reportget_line_movementget_live_oddsget_pending_picksget_system_statusget_todays_picksget_top_pickget_win_rateScored across 11 tools
Each tool targets a distinct function: odds retrieval, game analysis, pick management (today, top, pending, completed), alerts, model stats, leaderboard, win rate, and system health. No two tools overlap in purpose.
Ten of eleven tools follow the 'get_' prefix pattern (e.g., get_live_odds, get_todays_picks). The sole exception is 'analyze_game', which uses a verb_noun form. This is a minor deviation but still predictable and clear.
With 11 tools, the set is well-scoped for a sports betting analysis server. It covers all essential features without being bloated or sparse.
The tool surface covers the full workflow: fetching odds, analyzing games, retrieving picks (today, top, pending, completed), alerts, model stats, leaderboard, win rate, and system health. A minor gap is the lack of historical pick search or user-specific features, but core analysis is complete.
Live sports stats and pre-computed analysis for AI assistants across NBA, MLB, NFL, and NHL.
NBA/WNBA betting analytics: live odds, sharp fair prices, injuries, and prop verification.
Sports odds, player props and source coverage for AI assistants. Connect with your own API key.
NFL analytics tools for AI agents: stats, fantasy, injuries, schedules, and advanced analysis.
