bet-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no overlap: fair.compute calculates fair odds, fixtures.list shows upcoming matches, match.snapshot provides team form and stats, odds.prematch lists market odds, and value.detect identifies value bets. The descriptions are specific and unambiguous, making it easy for an agent to select the right tool.
Naming Consistency5/5
All tool names follow a consistent dot-separated pattern (e.g., fair.compute, fixtures.list) with a clear category.action structure. This predictable naming convention enhances readability and usability across the tool set.
Tool Count5/5
With 5 tools, the server is well-scoped for its betting/soccer analysis domain. Each tool serves a unique and essential function, from data retrieval to analysis, without being overly sparse or bloated, making the count appropriate for the purpose.
Completeness4/5
The tool set covers core workflows for betting analysis: fetching fixtures, getting match stats, computing fair odds, retrieving market odds, and detecting value bets. A minor gap is the lack of tools for in-play odds or historical data, but agents can work around this with the provided tools.
Average 2.9/5 across 5 of 5 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the calculation method (Poisson semplice) and output types (probabilities and odds for specific markets), but lacks critical details like whether this is a read-only operation, if it requires specific permissions, rate limits, or what the response format looks like. For a computational tool with zero annotation coverage, this is insufficient.
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 description is concise and front-loaded in a single sentence that directly states the tool's function. It efficiently covers the core purpose without unnecessary words, though it could benefit from slight structural improvements like separating the calculation method from the output markets for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the computational nature of the tool, no annotations, and no output schema, the description is incomplete. It doesn't explain what the output looks like (e.g., structured probabilities/odds), error handling, or dependencies on external data (e.g., requiring match statistics from API-Football). For a tool that performs calculations with a single input, more context is needed.
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 has 100% description coverage, with the single parameter 'match_id' clearly documented as 'Fixture id da API-Football'. The description doesn't add any additional parameter semantics beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: calculating fair probabilities and odds using simple Poisson distribution for specific betting markets (1X2, Over/Under 2.5, Both Teams to Score). It specifies the verb 'calcola' (calculates) and the resource type (probabilities/odds), though it doesn't explicitly differentiate from sibling tools like 'odds.prematch' or 'value.detect' which might handle similar betting data.
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 guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context, or comparisons to sibling tools like 'odds.prematch' (which might provide pre-match odds) or 'value.detect' (which might detect value bets). It only states what the tool does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns data but doesn't specify if it's a read-only operation, whether it requires authentication, rate limits, error handling, or the format of returned data (e.g., JSON structure). For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior beyond basic functionality.
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 description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to understand quickly. However, it could be slightly improved by structuring key points (e.g., bullet points) for clarity, but this is minor.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a data retrieval tool with no annotations and no output schema), the description is incomplete. It doesn't explain the return values in detail (e.g., what 'forma' or 'classifica' mean), error cases, or how to interpret results. With no output schema and minimal behavioral context, the description fails to provide enough information for an agent to use the tool effectively beyond basic invocation.
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 has 100% description coverage, with 'match_id' documented as an integer from API-Football. The description adds no additional parameter semantics beyond what the schema provides, such as examples or constraints. Since schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract from the schema's information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns specific match data (shape, classification, goals scored/conceded, and recent results) for a requested match. It uses specific verbs ('Restituisce' - returns) and resources ('match richiesto' - requested match), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'fixtures.list' or 'odds.prematch', which might also provide match-related information.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing a valid match_id from API-Football, or compare its functionality to sibling tools like 'fixtures.list' (which might list matches) or 'odds.prematch' (which might provide odds). Usage is implied only by the tool's name and description, with no explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'normalizzate' (normalized) and 'lista bookmaker' (bookmaker list), hinting at data formatting and sources, but doesn't clarify if this is a read-only operation, rate limits, error handling, or output structure. For a tool with no annotations, this is insufficient.
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 description is a single, efficient sentence in Italian that conveys the core purpose without unnecessary words. It's appropriately sized and front-loaded, though some might argue it could be slightly more structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a single parameter with full schema coverage, the description is incomplete. It doesn't explain the return values (e.g., odds format, bookmaker list structure) or behavioral aspects like data freshness or limitations, leaving significant gaps for the agent.
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 has 100% description coverage, with 'match_id' documented as 'Fixture id di API-Football'. The description doesn't add any parameter details beyond this, so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Quote pre-match (1X2, Over/Under 2.5, BTTS) normalizzate con lista bookmaker.' It specifies the verb ('Quote') and resource (pre-match odds for specific bet types), though it doesn't explicitly differentiate from sibling tools like 'match.snapshot' or 'value.detect'. The purpose is clear but lacks sibling differentiation.
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 guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context, or exclusions. Given sibling tools like 'match.snapshot' and 'value.detect', the lack of usage guidelines leaves the agent uncertain about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool finds 'value picks' with an 'edge >= 5%', which implies some calculation or comparison, but doesn't describe what happens during execution (e.g., whether it fetches data, performs computations, or returns specific formats). For a tool with no annotations, this leaves significant gaps in understanding its behavior, such as error handling or output structure.
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, efficient sentence in Italian that conveys the core purpose without unnecessary words. It's front-loaded with the main action and result, making it easy to understand quickly. There's no wasted verbiage, and every part of the sentence contributes to the tool's definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a tool that compares market vs fair quotes to find value picks, the description is incomplete. There's no output schema, and the description doesn't explain what the output looks like (e.g., a list of picks with details). With no annotations and minimal parameter explanation, it fails to provide enough context for an agent to fully understand how to use and interpret results, especially for a potentially data-intensive operation.
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 schema description coverage is 100%, with the single parameter 'match_id' documented as 'Fixture id'. The description doesn't add any meaning beyond this, as it doesn't explain how the match_id is used (e.g., to fetch market and fair quotes for that specific match). Since the schema already fully describes the parameter, the baseline score of 3 is appropriate, indicating adequate but no extra value from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Confronta quote mercato vs fair per trovare fino a 3 value pick (edge >= 5%)' which translates to 'Compare market quotes vs fair to find up to 3 value picks (edge >= 5%)'. It specifies the action (compare market vs fair quotes), the resource (value picks), and the scope (up to 3 picks with edge >= 5%). However, it doesn't explicitly distinguish this from sibling tools like fair.compute or odds.prematch, which prevents a score of 5.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing a match_id from fixtures.list, or compare it to siblings like fair.compute (which might compute fair values) or odds.prematch (which might provide market quotes). There's only an implied context of finding value picks, but no explicit usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description states it returns match data, which suggests a read-only operation, but it doesn't address other behavioral aspects like rate limits, authentication needs, error conditions, or pagination. For a tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves beyond its basic function.
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 extremely concise and front-loaded, consisting of a single sentence that efficiently conveys the tool's purpose, scope, and output. Every word earns its place, with no wasted information or redundancy. The structure is clear and direct, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose and output fields, but lacks details on behavioral traits, error handling, or usage context relative to siblings. Without annotations or output schema, the description should do more to compensate, but it provides just enough for a minimal viable understanding.
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 schema description coverage is 100%, with the 'days' parameter fully documented in the schema (type, range, default). The description adds marginal value by contextualizing 'X giorni' as the timeframe for upcoming matches, but it doesn't provide additional semantic details beyond what's in the schema. This meets the baseline score of 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Ritorna i prossimi match di Serie A entro X giorni' (Returns upcoming Serie A matches within X days). It specifies the verb ('ritorna'), resource ('match di Serie A'), scope ('entro X giorni'), and output fields ('id, squadre, kickoff, venue'). However, it doesn't explicitly differentiate from sibling tools like 'match.snapshot' or 'odds.prematch', which prevents a perfect score.
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?
The description provides minimal usage guidance. It implies the tool should be used when you need upcoming Serie A matches within a specified timeframe, but it doesn't mention when to use this tool versus alternatives like 'match.snapshot' or 'odds.prematch'. No exclusions, prerequisites, or explicit alternatives are provided, leaving the agent with little context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![bet_mcp MCP server](https://glama.ai/mcp/servers/Valerio357/bet_mcp/badges/card.svg)](https://glama.ai/mcp/servers/Valerio357/bet_mcp)

Score Badge

Copy to your README.md:

[![bet_mcp MCP server](https://glama.ai/mcp/servers/Valerio357/bet_mcp/badges/score.svg)](https://glama.ai/mcp/servers/Valerio357/bet_mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Valerio357/bet_mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server