Skip to main content
Glama
Sign In
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

cricbuzz_match_overs

Fetch Cricbuzz over summaries for a match URL, returning over rows and live innings filter values with an is_complete flag; excludes ball-by-ball commentary.

Instructions

Get Cricbuzz over summaries. Returns every over-summary row present in the first-party Over-by-Over page payload and the live innings filter values. Some upstream snapshots include only a recent window; the response sets is_complete=false in that case. Full ball-by-ball commentary text is not included.

Input Schema

NameRequiredDescriptionDefault
match_urlYesCanonical Cricbuzz live-cricket-scores URL returned by /cricbuzz/matches

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.18

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations provided, the description carries the full disclosure burden and does well: it says the data comes from the first-party page payload, that some snapshots are partial and signal this via is_complete=false, and what is explicitly excluded (ball-by-ball text). It omits auth/rate-limit expectations, but the key trust-relevant caveat about partial coverage is disclosed clearly, which is the most important behavioral fact here.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short sentences, front-loaded with the action and followed by return shape, the partial-data caveat, and the exclusion. Every sentence adds something; there is no padding, though the caveat sentence could be marginally tighter.

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?

For a single-parameter read with no annotations and no output schema, the description supplies what the agent needs: what rows come back, extra filter values, the completeness flag semantics, and what is not included. Nothing material about calling it correctly is missing.

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?

Only one parameter exists and schema coverage is 100%, with the schema already noting the canonical Cricbuzz live-cricket-scores URL format returned by /cricbuzz/matches. The description adds no further per-parameter detail, so it matches the baseline-3 expectation for a fully documented single parameter rather than exceeding it.

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?

States a specific verb and resource ("Get Cricbuzz over summaries") and immediately qualifies the scope: every over-summary row from the first-party Over-by-Over payload plus live innings filter values. It carves itself out from the commentary sibling with "Full ball-by-ball commentary text is not included." It does not explicitly distinguish itself from cricbuzz_scorecard or cricbuzz_match_facts, which keeps it from a 5.

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

Usage Guidelines3/5

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

Usage is implied by the "over summaries" framing, and the exclusion of ball-by-ball commentary hints at when to reach for a different source. But there is no explicit "use this when..." statement, no mention of the scorecard or facts siblings as alternatives, and no prerequisites noted for the URL.

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

Deploy Server

Other Tools