How do I use Odds De-vig MCP Server?

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., "@Odds De-vig MCP Server Get today's MLB games with fair probabilities" 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.

de en es ja ko ru zh

Odds De-vig MCP Server

by Mavline

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Odds De-vig MCP Server

MCP server for fetching sports odds from The Odds API and removing the bookmaker margin (vig).

✅ Latest improvements (v1.1.0)

API Usage Tracking: All responses now include the remaining API call allowance
Retry Logic: Automatic retries on connection issues (3 attempts)
Better Error Handling: Improved network error handling
Response Format: Structured responses with summary and apiUsage

Related MCP server: mcp-odds-api

Features

Tools

get_sports - Get a list of supported sports (no API request)
get_today_mlb - Get today's MLB games with processed odds (cost-efficient)
get_upcoming_odds - Get raw odds (default: today's MLB games)
get_processed_odds - Get processed odds with the margin removed
get_event_consensus - Get the consensus line for a specific event
get_api_usage - Get API usage statistics (makes 1 API request)

Resources

odds://sports - List of supported sports (no API request)
odds://today-mlb - Today's MLB games with processed odds
odds://processed - Processed odds without margin (default: today's MLB games)

Margin removal methods

1. Proportional (default)

The simplest and most commonly used method:

fair_probability = implied_probability / total_implied_probability

2. Power (Shin)

A more complex method that takes the number of outcomes into account:

fair_probability = implied_probability^n / total_implied_probability^(n-1)

3. Additive

Distributes the margin evenly across all outcomes:

fair_probability = implied_probability - (total_vig / number_of_outcomes)

Installation and setup

# Установка зависимостей
npm install

# Сборка
npm run build

# Запуск
npm start

# Разработка
npm run dev

Configuration

Set the ODDS_API_KEY environment variable or use the default key:

export ODDS_API_KEY=your_api_key_here

⚠️ API Limits

IMPORTANT: The Odds API has a limit of 500 requests per month on the free plan!

Optimizations to save requests:

By default, only today's MLB games are requested
get_sports returns a hardcoded list without an API request
get_today_mlb is the most cost-efficient way to get data
All requests log API usage

Recommendations:

Use get_today_mlb for testing
Limit yourself to 20 requests per day for tests
Monitor usage via get_api_usage

Usage

Getting the list of sports (no API request)

{
  "tool": "get_sports"
}

Getting today's MLB games (cost-efficient)

{
  "tool": "get_today_mlb",
  "arguments": {
    "deVigMethod": "proportional"
  }
}

Getting processed odds

{
  "tool": "get_processed_odds",
  "arguments": {
    "sport": "americanfootball_nfl",
    "deVigMethod": "proportional",
    "removeOutliers": true,
    "minBookmakers": 3
  }
}

Getting the consensus line

{
  "tool": "get_event_consensus",
  "arguments": {
    "eventId": "event_id_from_api",
    "deVigMethod": "power"
  }
}

Data structure

ProcessedEvent

interface ProcessedEvent {
  id: string;
  sportKey: string;
  sportTitle: string;
  commenceTime: string;
  homeTeam: string;
  awayTeam: string;
  bookmakers: ProcessedBookmaker[];
  consensusLine?: {
    homeTeamFairOdds: number;
    awayTeamFairOdds: number;
    averageVig: number;
  };
}

ProcessedOutcome

interface ProcessedOutcome {
  name: string;
  americanOdds: number;
  decimalOdds: number;
  impliedProbability: number;
  fairProbability: number; // После удаления маржи
}

API Limits

CRITICAL: Limit of 500 requests/month!

Current optimizations:

Focus on MLB (plays daily)
Requests only for today's games
Hardcoded list of sports
Logging of every request

Monitoring:

{
  "tool": "get_api_usage"
}

Returns:

{
  "requestsUsed": "15",
  "requestsRemaining": "485",
  "monthlyLimit": 500,
  "eventsFound": 12
}

Next steps

Polymarket CLOB API Server - for fetching data from Polymarket
Comparison Server - for comparing lines and finding arbitrage
News/SERP Server - for fetching news and context

Available Tools

6 tools

get_api_usageA

Get current API usage statistics (makes 1 API call)

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

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/5

Is 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/5

Given 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/5

Does 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/5

Does 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/5

Does 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.

get_event_consensusA

Get consensus line for a specific event

ParametersJSON Schema

Name	Required	Description	Default
`eventId`	Yes	Event ID from The Odds API
`deVigMethod`	No	Method for removing vig (default: proportional)	proportional
`minBookmakers`	No	Minimum number of bookmakers for consensus (default: 3)
`removeOutliers`	No	Remove worst outlier bookmakers (default: false)

TDQS

A3.5/5.0

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/5

Is 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/5

Given 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/5

Does 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/5

Does 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/5

Does 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.

get_processed_oddsB

Get odds with vig removed and fair probabilities calculated

ParametersJSON Schema

Name	Required	Description	Default
`sport`	No	Sport key (default: baseball_mlb)	baseball_mlb
`markets`	No	Markets to get odds for (default: h2h)	h2h
`regions`	No	Regions to get odds for (default: us)	us
`deVigMethod`	No	Method for removing vig (default: proportional)	proportional
`minBookmakers`	No	Minimum number of bookmakers for consensus (default: 3)
`commenceTimeTo`	No	ISO datetime for latest commence time (default: tomorrow)
`removeOutliers`	No	Remove worst outlier bookmakers (default: false)
`commenceTimeFrom`	No	ISO datetime for earliest commence time (default: today)

TDQS

B3.1/5.0

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/5

Is 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/5

Given 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/5

Does 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/5

Does 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/5

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 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.

get_sportsA

Get limited list of supported sports (no API call)

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

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/5

Is 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/5

Given 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/5

Does 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/5

Does 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/5

Does 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.

get_today_mlbB

Get today's MLB games with processed odds (API efficient)

ParametersJSON Schema

Name	Required	Description	Default
`deVigMethod`	No	Method for removing vig (default: proportional)	proportional

TDQS

B3.1/5.0

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/5

Is 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/5

Given 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/5

Does 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/5

Does 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/5

Does 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.

get_upcoming_oddsB

Get upcoming odds for sports events (limited to today by default)

ParametersJSON Schema

Name	Required	Description	Default
`sport`	No	Sport key (default: baseball_mlb)	baseball_mlb
`markets`	No	Markets to get odds for (default: h2h)	h2h
`regions`	No	Regions to get odds for (default: us)	us
`commenceTimeTo`	No	ISO datetime for latest commence time (default: tomorrow)
`commenceTimeFrom`	No	ISO datetime for earliest commence time (default: today)

TDQS

B3.4/5.0

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/5

Is 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/5

Given 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/5

Does 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/5

Does 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/5

Does 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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv1.0.0Aug 22, 2026
- First observedget_api_usage
- First observedget_event_consensus
- First observedget_processed_odds
- First observedget_sports
- First observedget_today_mlb
- First observedget_upcoming_odds

Install Server

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

TDQS

A3.6/5.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/5

All 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/5

With 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/5

The 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.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Sports Game Odds A
io.github.pipeworx-io
Sports Game Odds MCP — wraps the Sports Game Odds API (sportsgameodds.com)
Sports Open Data
3321
Sorqen A
io.github.iFan6oy
Sportsbook-derived no-vig fair value with confidence, provenance, and history over REST/MCP.
101
PropLine — Sports Betting Odds & Prop Resolution A
io.github.proplineapi
Live odds, cross-book +EV and graded player-prop results across 27 books. Hosted endpoint included.
Sports Finance
2811
ParlayAPI A
io.github.JacobiusMakes
Sports odds, player props and source coverage for AI assistants. Connect with your own API key.
Sports Data Platforms
221

Related MCP Servers

Odds-API MCP Serverofficial
Sports
odds-api-io
A
license
A
quality
B
maintenance
Enables AI assistants to access sports betting odds data from 265+ bookmakers across 34 sports, including events, odds, historical data, arbitrage, and value bets.
Updated a month ago (2026-07-24 12:57 UTC)
22
91
1
MIT
mcp-odds-api
Sports Search
pipeworx-io
A
license
Not graded
quality
C
maintenance
Enables fetching sportsbook odds, live scores, and event information across 70+ books and 30+ leagues, with tools to list sports, get scores, and discover events.
Updated 11 days ago (2026-08-26 17:26 UTC)
14
MIT
PredictionMarketsPicks Quantofficial
Blockchain Finance
predictionmarketspicks
A
license
A
quality
A
maintenance
Prediction-market quant tools — expected value, Kelly sizing, Bayesian updating, odds conversion, base-rate gaps, cross-platform arbitrage, and mispricing edge — for Kalshi and Polymarket contracts, exposed as a remote MCP server.
Updated 5 days ago (2026-09-01 20:43 UTC)
10
6
15
MIT
propzapi
Developer Tools
paperandbeyond23-gif
A
license
Not graded
quality
B
maintenance
Props-first sports odds API with a hosted MCP server. Live odds and player props (moneyline, spreads, totals) across US sportsbooks, normalized to JSON. Tools: get_odds, get_props, get_events, get_books. API-key auth, free tier.
Updated 13 days ago (2026-08-24 19:25 UTC)
MIT No Attribution

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/Mavline/odds-devig-server'

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

Odds De-vig MCP Server

✅ Latest improvements (v1.1.0)

Features

Tools

Resources

Margin removal methods

1. Proportional (default)

2. Power (Shin)

3. Additive

Installation and setup

Configuration

⚠️ API Limits

Usage

Getting the list of sports (no API request)

Getting today's MLB games (cost-efficient)

Getting processed odds

Getting the consensus line

Data structure

ProcessedEvent

ProcessedOutcome

API Limits

Next steps

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Odds-API MCP Serverofficial

PredictionMarketsPicks Quantofficial

Latest Blog Posts

MCP directory API