Skip to main content
Glama

PropLine — Sports Betting Odds & Prop Resolution

by io.github.proplineapi
OverviewDiscussionsAdmin

Get graded prop results

propline_get_event_results
Read-onlyIdempotent

Pro-tier endpoint. Returns graded prop outcomes for a completed event — every Over/Under marked won, lost, push, or void with the actual stat value next to the line. The single most distinctive feature vs the-odds-api: they don't grade props at any tier. Free tier returns the same structure with resolution and actual_value redacted plus an upgrade pointer.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
marketsNoComma-separated market keys to restrict to (e.g. pitcher_strikeouts,batter_hits).
event_idYes
sport_keyYes
bookmakersNoComma-separated book keys to restrict to (e.g. bovada). Default returns all books; an unfiltered MLB game can run several MB, so pass one book when that is enough.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / bookmakers
      Added value: +{
+  "description": "Comma-separated book keys to restrict to (e.g. bovada). Default returns all books; an unfiltered MLB game can run several MB, so pass one book when that is enough.",
+  "type": "string"
+}
    • addedInput schema / properties / markets
      Added value: +{
+  "description": "Comma-separated market keys to restrict to (e.g. pitcher_strikeouts,batter_hits).",
+  "type": "string"
+}
  2. First observed

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare read-only, open-world, and idempotent behavior, so the bar for added value is met. The description adds the pro-tier requirement, the free-tier redaction of resolution and actual_value, and the payload-size warning (`unfiltered MLB game can run several MB`). These are useful behavioral insights beyond the structured annotations, with no contradiction.

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 three sentences, front-loaded with purpose ('Pro-tier endpoint. Returns graded prop outcomes...'), then adds tier and size context. Every sentence earns its place with no redundancy or filler.

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 read-only, idempotent tool with no output schema, the description covers the output structure, redaction behavior, and the large-payload caveat—enough for an agent to call it correctly. Minor gap: it does not specify what happens if the event is not yet completed, but the phrase 'completed event' implies that. Overall, it is nearly complete for the given complexity.

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 50% (markets and bookmakers have descriptions; sport_key and event_id are self-explanatory names). The description does not add parameter-level meaning—its mention of 'actual stat value' refers to output, not input. The payload-size hint is inside the bookmakers schema description, not the tool description, so the description itself adds little over the schema.

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 verb and resource: 'Returns graded prop outcomes for a completed event' with a specific output format (won/lost/push/void plus actual value). It distinguishes from a competitor API but not explicitly from sibling tools, relying on the name and context. It is specific and useful, but could be more explicit about how it differs from other propline_get_* tools like get_scores or get_event_stats.

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 versus sibling alternatives. The description mentions tier differences (pro vs free) but does not say 'use this when you need graded props' or point to any other tool for ungraded data. An agent is left to infer usage from the name and description without explicit routing or exclusions.

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