Skip to main content
Glama

PropLine — Sports Betting Odds & Prop Resolution

by io.github.proplineapi

Get webhook deliveries

propline_get_webhook_deliveries
Read-onlyIdempotent

Recent delivery attempts for one webhook (Streaming Lite tier and up), newest first — the debugging surface for 'why isn't my webhook firing'. Each row: status (pending/success/failed), HTTP response_code, attempts, delivered_at and the payload that was sent. A pending row with attempts > 0 is mid-retry-backoff; status 'failed' with response_code null means the endpoint was unreachable or timed out (8s). Page backwards through a deep queue with before_id = the smallest id on the previous page; a page shorter than limit is the last one.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoRows per page, 1-200. Default 50.
before_idNoCursor: smallest delivery id from the previous page.
webhook_idYesWebhook id (from propline_list_webhooks).

Schema Changelog

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

  1. Added

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds significant behavioral context beyond the annotations: it explains what the returned rows contain, how to interpret pending vs. failed status, the meaning of response_code null, and the 8-second timeout detail. It also explains pagination behavior. This is valuable context that the readOnlyHint/idempotentHint annotations do not cover.

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 compact yet information-dense. It front-loads the core purpose, then provides essential interpretation and pagination guidance within two sentences. Every sentence adds value: no filler, no repetition of schema details. The structure is efficient and scannable.

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?

The description is thorough given the tool's complexity. It explains the row structure, status semantics, error conditions, and pagination. The annotations cover safety (read-only, idempotent) and the schema covers parameters, so the description adds the remaining behavioral context. No output schema is present, but the description sufficiently outlines the data returned.

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 schema already documents all three parameters with descriptions, and the description adds extra nuance: it explains the pagination cursor (before_id = smallest id from previous page) and mentions the default limit of 50. The description also adds interpretative semantics for the status field, which is not a parameter but enhances understanding. Since schema coverage is 100%, the baseline is 3, but the added pagination and default-value context earn a 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 clearly states the tool's purpose: it retrieves recent delivery attempts for one webhook, listing them newest first. It specifies the resource (webhook deliveries), the action (get), and the scope (one webhook, newest first). It also differentiates itself from sibling tools by framing it as the debugging surface for webhook issues, which is distinct from the other propline_* tools.

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

Usage Guidelines5/5

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

The description provides clear usage guidance: it explains when to use this tool (to debug why a webhook isn't firing) and offers specific navigation instructions (using before_id for pagination, interpreting status entries). It also hints at alternatives by mentioning propline_list_webhooks as the source for the webhook_id, which helps distinguish this from listing tools.

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

All PropLine — Sports Betting Odds & Prop Resolution 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

A4.1/5.0
Disambiguation3/5

The tools are mostly distinct by purpose, but several overlap in areas like odds retrieval (get_odds vs get_best_line vs get_event_ev) and historical data (get_odds_history vs get_odds_closing vs export_odds_history). Descriptions are detailed and clarify distinctions, but the close functional relationships (e.g., get_event_movement vs get_odds_history) may cause selection ambiguity for an agent.

Naming Consistency4/5

The naming pattern is largely consistent: propline_<verb>_<noun> with verbs like get, list, export. Most tools follow this structure (e.g., get_event_results, list_events, list_sports). Deviations include 'propline_export_odds_history' (export instead of get) and a few longer names like 'propline_get_mlb_grand_salami' and 'propline_get_nhl_daily_goals_total' that break the simple verb_noun pattern but are still readable. Overall, the naming is predictable with minor exceptions.

Tool Count4/5

With 23 tools for a sports betting odds and prop resolution server, the count is on the higher side but still within a reasonable range given the domain's complexity (odds, EV, movement, results, player trends, webhooks, exports). Each tool serves a distinct function, though some could be consolidated (e.g., grand salami and NHL daily totals could be one). Slightly heavy but not excessive.

Completeness4/5

The tool set covers the core lifecycle: discover sports and events (list_sports, list_events), retrieve odds and markets (get_odds, list_event_markets), analyze EV and lines (get_event_ev, get_best_line, get_event_movement), track results and player stats (get_event_results, get_event_stats, get_player_history, get_player_trends), and backfill via exports. Missing features include webhook management (deliberately omitted) and possibly batch operations, but the surface is comprehensive for the stated purpose.

Resources