Skip to main content
Glama
Sign In

PropLine — Sports Betting Odds & Prop Resolution

by io.github.proplineapi
OverviewDiscussionsAdmin

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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "webhook_id": "<webhook_id>"
    },
    "name": "propline_get_webhook_deliveries"
  }
}

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

  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
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources