Skip to main content
Glama

ParlayAPI

by io.github.JacobiusMakes

parlayapi_find_arbitrage

Find guaranteed-profit arbitrage opportunities across bookmakers.

Scans every event and returns bets where the combined implied
probability across the books is under 100%, so betting each side locks
in profit regardless of outcome. Soccer and other 3-way (home/draw/away)
markets are fully supported, including arbs anchored on the draw.

Args:
    sport_key: e.g. "baseball_mlb", "soccer_epl".
    min_profit: Minimum profit % to include (e.g. 1.5 for 1.5%). Default 0.
    exclude_exchanges: Drop arbs anchored on an exchange (novig/prophetx),
        whose asks can be no-volume. Default False.
    markets: Comma-separated market_keys to limit the scan (optional),
        e.g. "h2h,spreads,totals".

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
marketsNo
sport_keyYes
min_profitNo
exclude_exchangesNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.6/5.0
Behavior4/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 core detection rule (<100% implied probability), market support (home/draw/away including draw-anchored arbs), and the rationale/risk behind exclude_exchanges (no-volume asks). It does not discuss rate limits or execution caveats, but it transparently explains the main behavioral guarantees and caveats.

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?

First sentence front-loads the tool's purpose; the next sentence gives the underlying arbitrage rule; the Args block is compact and each line adds information not present in the schema. No filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the lack of an explicit return-value description is not a gap. The description covers the one required arg, all defaults, optional filters, supported market types, and a practical caveat about exchange asks, so an agent has enough to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, yet the Args block documents all four parameters with concrete examples (sport_key 'soccer_epl'), units and default values (min_profit '1.5 for 1.5%', default 0), optionality, and delimiter format for markets. This fully compensates for the empty schema descriptions.

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?

First sentence names an exact verb ('Find') and resource ('guaranteed-profit arbitrage opportunities across bookmakers'), and the body's 'combined implied probability under 100%' distinguishes it from related valuation tools like find_ev or find_middles. The distinction is functional rather than by name alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Describes clear use-case context: locating locked-in-profit arbs, including 3-way soccer/draw markets and optional exchange exclusion. It does not explicitly name when to prefer parlayapi_find_ev or parlayapi_find_middles, so it earns a 4 rather than a 5, but an agent can infer the right selection from the stated purpose.

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

All ParlayAPI toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.7/5.0
Disambiguation3/5

Most tools map to distinct workflows (raw odds, best-line, EV scan, arb, middle, single-bet grade, parlay grade), but several pairs are easy to mix up: find_ev vs best_bets both surface +EV opportunities, live_sports vs list_sports differ only in 'live', and verdict vs parlay_verdict have near-identical names. The detailed descriptions resolve most ambiguity, so it is not chaotic, but the boundaries are not all crisp.

Naming Consistency3/5

All names share the parlayapi_ prefix and snake_case, but the suffix style is inconsistent: some are verb-led (get_odds, find_arbitrage, set_bettable_books) and many are bare noun phrases (consensus, verdict, source_quality, magic_link). The live_* and best_* groups are internally consistent, but pairs like list_sports/live_sports and verdict/parlay_verdict add confusion.

Tool Count3/5

22 tools is on the heavy side for an MCP server, even though the sports-betting domain is broad. Each tool has a plausible purpose, but the public demo/metadata tools (live_command_center, book_coverage, source_quality, live_sports) could probably be consolidated or separated.

Completeness4/5

The surface covers the core domain well: sport discovery, game odds, props, consensus, best-line, EV, arbitrage, middles, single-bet verdicts, parlay verdicts, and account/signup flows. Minor gaps exist (no explicit book/market metadata list, no historical odds, no betting-account history), but agents can usually work around them.

Resources