Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

cricinfo_live_matches

Retrieve Cricinfo's live-score list without parameters, covering live, upcoming, and recently completed matches with teams, scores, status, series, and scorecard URLs.

Instructions

Get Cricinfo live matches. Returns Cricinfo's current live-score list with no parameters, covering live, upcoming and recently completed matches. Each match has its title, format, state, status text, start date, series, both teams with scores, and a scorecard url you can pass to the match endpoint.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "cricinfo_live_matches"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.16.2

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations and no output schema, the description carries the burden and does so well: it enumerates the return shape (title, format, state, status text, start date, series, teams with scores) and surfaces the actionable 'scorecard url you can pass to the match endpoint.' It omits freshness/latency caveats common to live-score feeds, but the read-only nature is clear from 'Get.'

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?

Two sentences, front-loaded with purpose before return details, and every clause adds information. Minor redundancy in restating 'Cricinfo live matches' at the start of both the purpose and the returns sentence keeps it from a 5.

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 parameterless read tool with no output schema, the description adequately describes the payload and the downstream-useful url field. It is nearly complete; only the absence of any note on refresh cadence for live data holds it back.

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?

Zero parameters, so the baseline is 4. The description explicitly confirms 'with no parameters,' reinforcing that this is a parameterless call and no filtering is available.

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+resource ('Get Cricinfo live matches') and clarifies scope as 'live, upcoming and recently completed matches.' It distinguishes itself reasonably from cricinfo_scores/cricinfo_calendar by describing the live-score list, though it never names the sibling that would be preferred for a different scope.

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?

The description implies usage by noting the tool takes 'no parameters' and covers live, upcoming, and recently completed matches, so an agent can infer when it fits. However, it never says when to prefer it over cricinfo_scores, cricinfo_calendar, or cricinfo_match, so routing is left to inference.

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