Odds De-vig MCP Server
Server Quality Checklist
Latest release: v1.0.0
- Disambiguation4/5
The tools have mostly distinct purposes: sports list, today's games, upcoming odds, processed odds, event consensus, and API usage. However, 'get_processed_odds' and 'get_event_consensus' could overlap for agents looking for the best line on an event, though descriptions clarify that processed odds gives probabilities and consensus gives a single line.
Naming Consistency4/5All tools follow the 'get_' prefix with a resource, which is consistent. The naming is clear and predictable, but some names like 'get_upcoming_odds' and 'get_processed_odds' are similar in structure, which is minor. No mixing of conventions.
Tool Count5/5With 6 tools, the server is well-scoped for a specialized odds processing service. Each tool serves a distinct function, and the count is within the ideal 3-15 range, providing enough coverage without being bloated.
Completeness4/5The tool surface covers listing sports, fetching today's games, upcoming events, processed odds, consensus lines, and API usage. There are minor gaps such as no ability to fetch specific historical games or detailed event details beyond consensus, but the core workflow of getting and processing odds is complete.
Average 3.5/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto 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
- Behavior3/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. It discloses the key behavioral aspect (vig removal and probability calculation) which goes beyond a simple fetch. However, it does not mention rate limits, authentication, or output shape, and for an 8-param tool with no output schema, this is a moderate gap but not contradicting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, information-dense sentence that front-loads the core value proposition. Could arguably be more expensive with the parameter list, but it wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, no annotations, and no output schema, the description falls short. Key contextual gaps include: what does the return object look like, how does `removeOutliers` interact with `minBookmakers`, and what are the unit/semantics of odds returned. A tool of this complexity needs more than one sentence to be self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%—every parameter has a description plus defaults. Per the rubric, high coverage sets baseline at 3. The description itself adds no extra parameter context beyond what the schema already provides, so it cannot score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb-resource pairing with a specific qualifier: 'Get odds with vig removed and fair probabilities calculated.' This distinguishes it from the raw odds tool `get_upcoming_odds` by emphasizing the processing transformation. However, it doesn't name sibling alternatives explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like `get_upcoming_odds` or `get_event_consensus`. The description implies a use case for fair/probability-adjusted odds but lacks any explicit when/when-not framing or reference to sibling tools.
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?
With no annotations, the description must carry the behavioral transparency burden. It mentions 'processed odds' and 'API efficient' but does not disclose return structure, timezone semantics, pagination, or other behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose efficiently. Every word adds value, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter, and the description states the main output concept ('today's MLB games with processed odds'). However, without an output schema or usage context, the description leaves some gaps around expected response shape and when to choose this tool over siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the single parameter deVigMethod already described and constrained by enum values and a default. The description adds no additional parameter context beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets today's MLB games with processed odds, using a specific verb and resource. It distinguishes itself by scoping to today's MLB games, though it does not explicitly contrast with sibling tools like get_processed_odds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_upcoming_odds or get_processed_odds. The phrase 'API efficient' hints at a benefit but does not explain selection criteria or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/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. It does disclose the default time limit behavior, which is a useful non-obvious trait. However, it does not describe the response structure, data source, or whether odds are raw or normalized, leaving behavioral expectations incomplete for a read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the action and resource, with a short parenthetical for the key default behavior. Every word contributes value, with no repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description does not explain what the returned odds data looks like or how it relates to sibling tools such as get_processed_odds. The schema provides adequate parameter details, but the overall context for selecting and interpreting the result is incomplete, especially given the optional time-range parameters that could broaden the default 'today' scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 5 parameters with descriptions and defaults, giving 100% schema description coverage, so the baseline is 3. The description adds little beyond the schema, merely restating the time-window behavior in prose rather than enriching any specific parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly uses a specific action ('Get') and resource ('upcoming odds for sports events'), making the core purpose obvious. It doesn't explicitly differentiate from siblings like get_processed_odds or get_today_mlb, but the 'upcoming' and generic sports scope imply a distinct function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'limited to today by default' provides some contextual usage guidance, and the schema defaults reinforce the intended time window. However, there is no explicit guidance about when to prefer this tool over alternatives such as get_processed_odds or get_event_consensus, so the usage guidance remains mostly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/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. It describes the tool's output (consensus line) but does not disclose specific behavioral traits such as whether it performs computations like de-vigging, how it handles missing data, or if it is read-only. It only hints at calculation through parameters like deVigMethod and removeOutliers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that clearly states the tool's purpose without unnecessary words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and no annotations, the description provides minimal context. It does not explain return value structure, error handling, or prerequisites like what constitutes a valid eventId. However, the parameter schema is well-documented, which compensates somewhat.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all four parameters with descriptions. The tool description adds no extra meaning beyond what the schema provides. Baseline 3 is appropriate as the description does not compensate with additional insights.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get consensus line for a specific event' clearly indicates the tool retrieves consensus odds for a given event, with 'event' being the resource. It differentiates from siblings like 'get_today_mlb' and 'get_upcoming_odds' by focusing on consensus for a specific event rather than listings or raw odds, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an event ID is known and consensus data is needed, but does not explicitly state when to use it over siblings or when not to use it. Siblings like 'get_upcoming_odds' suggest alternatives for odds data, but no direct comparison is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only adds the operational detail that it makes one API call. It does not explain whether the operation is read-only, what exact statistics are returned, or any authentication/rate-limit implications, or missing for a fully transparent description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: a single sentence states the operation, and the parenthetical cost note ('makes 1 API call') is meaningful, and no words are wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple, no-argument tool with clear purpose, but there is no output schema and no description of the return shape or exact use of 'usage statistics' (e.g., remaining quota, used calls, reset time). The one API call warning provides some context, but the description remains slightly skeletal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters and 100% schema coverage, so there is no parameter documentation gap. Baseline for 0 params is 4; the description adds no param-related value because none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') with a clear resource ('API usage statistics'), clearly distinguishing it from sibling sports data tools like get_sports and get_upcoming_odds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It is obvious that this tool is for checking API usage, and the sibling tools are unrelated to usage statistics. However, the description does not provide explicit when-to-use guidance or mention any context/alternates/exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explicitly states that no API call is made and the returned list is 'limited', which meaningfully informs the agent about the tool's behavior. It could mention return format, but for a simple list this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that communicates the core action, scope, and key behavioral fact. No filler or redundant text exists, making it easy for an agent to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter static list tool, the description sufficiently covers what the tool does and its non-API nature. While no output schema is provided, the expected result is straightforward, and the sibling list offers enough situation context. Slightly more detail about the actual sports content could raise it to a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter definitions to explain. The schema fully covers the interface, and the description adds no ambiguity. Per the baseline for zero parameter tools, this scores at the baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get limited list of supported sports' clearly specifies the action (get), the resource (supported sports), and the scope (limited list). The parenthetical '(no API call)' further distinguishes it from sibling tools that likely fetch live data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage intent through '(no API call)', suggesting it is a cheap or instant local lookup. However, it does not explicitly state when to use this tool instead of siblings or provide exclusionary guidance, so it stops at implied guidance.
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:
Score Badge
Copy to your README.md: