Skip to main content
Glama

Lumify Sports Intelligence

get_live_score

Read-onlyIdempotent

Get a lightweight live score snapshot for an event: status, period, clock, per-participant score and period-by-period scores, and last-updated time. Cheaper and faster than get_event when you only need the score, not participants or venue. Capped at 20 calls/min per key (shared with GET /v1/events/{id}/score and list_events include_scores=true). For live updates prefer the SSE stream. Raises a not-found error if event_id doesn't exist.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
event_idYesEvent id, from list_events, query_events, or search results.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
clockNo
periodNo
scoresNo
statusNo
event_idNo
finishedNo
updated_atNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / event_id / description
      Added value: +"Event id, from list_events, query_events, or search results."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "clock": {
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "event_id": {
      +      "type": "integer"
      +    },
      +    "finished": {
      +      "type": "boolean"
      +    },
      +    "period": {
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "scores": {
      +      "items": {
      +        "properties": {
      +          "abbreviation": {
      +            "type": [
      +              "string",
      +              "null"
      +            ]
      +          },
      +          "is_winner": {
      +            "type": [
      +              "boolean",
      +              "null"
      +            ]
      +          },
      +          "name": {
      +            "type": "string"
      +          },
      +          "period_scores": {
      +            "items": {
      +              "type": "object"
      +            },
      +            "type": "array"
      +          },
      +          "role": {
      +            "type": "string"
      +          },
      +          "score": {
      +            "type": [
      +              "string",
      +              "null"
      +            ]
      +          }
      +        },
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "status": {
      +      "type": "string"
      +    },
      +    "updated_at": {
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    }
      +  },
      +  "type": "object"
      +}
  2. Changed2 schema fields changed
    • removedInput schema / properties / event_id / description
      Removed value: -"Event id, from list_events, query_events, or search results."
    • changedOutput schema / (root)
      Previous value: -{
      -  "properties": {
      -    "clock": {
      -      "type": [
      -        "string",
      -        "null"
      -      ]
      -    },
      -    "event_id": {
      -      "type": "integer"
      -    },
      -    "finished": {
      -      "type": "boolean"
      -    },
      -    "period": {
      -      "type": [
      -        "string",
      -        "null"
      -      ]
      -    },
      -    "scores": {
      -      "items": {
      -        "properties": {
      -          "abbreviation": {
      -            "type": [
      -              "string",
      -              "null"
      -            ]
      -          },
      -          "is_winner": {
      -            "type": [
      -              "boolean",
      -              "null"
      -            ]
      -          },
      -          "name": {
      -            "type": "string"
      -          },
      -          "period_scores": {
      -            "items": {
      -              "type": "object"
      -            },
      -            "type": "array"
      -          },
      -          "role": {
      -            "type": "string"
      -          },
      -          "score": {
      -            "type": [
      -              "string",
      -              "null"
      -            ]
      -          }
      -        },
      -        "type": "object"
      -      },
      -      "type": "array"
      -    },
      -    "status": {
      -      "type": "string"
      -    },
      -    "updated_at": {
      -      "type": [
      -        "string",
      -        "null"
      -      ]
      -    }
      -  },
      -  "type": "object"
      -}New value: +null
  3. Changed6 schema fields changed
    • changedOutput schema / properties / clock / type
      Previous value: -"string"New value: +[
      +  "string",
      +  "null"
      +]
    • changedOutput schema / properties / period / type
      Previous value: -"string"New value: +[
      +  "string",
      +  "null"
      +]
    • changedOutput schema / properties / scores / items / properties / abbreviation / type
      Previous value: -"string"New value: +[
      +  "string",
      +  "null"
      +]
    • changedOutput schema / properties / scores / items / properties / is_winner / type
      Previous value: -"boolean"New value: +[
      +  "boolean",
      +  "null"
      +]
    • changedOutput schema / properties / scores / items / properties / score / type
      Previous value: -"string"New value: +[
      +  "string",
      +  "null"
      +]
    • changedOutput schema / properties / updated_at / type
      Previous value: -"string"New value: +[
      +  "string",
      +  "null"
      +]
  4. Changed2 schema fields changed
    • addedInput schema / properties / event_id / description
      Added value: +"Event id, from list_events, query_events, or search results."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "clock": {
      +      "type": "string"
      +    },
      +    "event_id": {
      +      "type": "integer"
      +    },
      +    "finished": {
      +      "type": "boolean"
      +    },
      +    "period": {
      +      "type": "string"
      +    },
      +    "scores": {
      +      "items": {
      +        "properties": {
      +          "abbreviation": {
      +            "type": "string"
      +          },
      +          "is_winner": {
      +            "type": "boolean"
      +          },
      +          "name": {
      +            "type": "string"
      +          },
      +          "period_scores": {
      +            "items": {
      +              "type": "object"
      +            },
      +            "type": "array"
      +          },
      +          "role": {
      +            "type": "string"
      +          },
      +          "score": {
      +            "type": "string"
      +          }
      +        },
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "status": {
      +      "type": "string"
      +    },
      +    "updated_at": {
      +      "type": "string"
      +    }
      +  },
      +  "type": "object"
      +}
  5. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds material operational context they do not cover: a 20 calls/min per-key cap shared with two other endpoints, a preference for the SSE stream under live updates, and a not-found error when event_id is invalid.

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?

Four tight sentences with the payload, the cost/sibling comparison, the rate limit, and the error condition front-loaded in that order. No filler or restatement of the name.

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?

An output schema exists, so return-field detail need not be re-explained; the description still summarizes the payload shape. Rate limiting, error behavior, and the streaming alternative are all covered, leaving nothing an agent needs to call this correctly.

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?

Single required parameter with 100% schema description coverage, so the schema already documents event_id and its provenance (list_events, query_events, search results). The prose adds nothing beyond that, which is the expected baseline when the schema does the work.

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?

Names a specific verb and resource (get a live score snapshot) and enumerates the returned fields (status, period, clock, per-participant score, period scores, last-updated). It explicitly contrasts itself with the sibling get_event, so an agent can separate the two without opening either schema.

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?

States when to choose this over the alternative ("cheaper and faster than get_event when you only need the score, not participants or venue") and names a third option for live updates ("prefer the SSE stream"). Both a selection condition and an exclusion are given.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.