Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official

cricbuzz_auction_results

Retrieve filtered and sorted player results from a completed Cricbuzz auction by tournament, year, currency, country, status, team, role, cap, and page.

Instructions

Get filtered and sorted Cricbuzz completed-auction players. Returns one 1-based page from the selected completed auction. Discover tournament/year/currency with cricbuzz/auction/seasons and the selected edition's Country, Status, Team, Role, Cap and Sort values with cricbuzz/auction/options. country_ids and statuses accept comma-separated values from those menus; the other filters accept one value. Pages return up to 20 rows; the source does not provide a total count or has-more flag.

Input Schema

NameRequiredDescriptionDefault
capNoOne Cap value from cricbuzz/auction/options; current values: Capped, Uncapped
pageNoOne-based page number; defaults to 1
roleNoOne Role from cricbuzz/auction/options; current values: Batter, Bowler, Allrounder, WK-Batter
sortNoDisplayed Sort label from cricbuzz/auction/options; current values: Recent, Featured, Base Price: High to Low, Base Price: Low to High, Final Price: High to Low, Final Price: Low to High
yearYesEdition from cricbuzz/auction/seasons: ipl 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022, 2023, 2024, 2025, 2026; wpl 2023, 2024, 2025, 2026, 2027; sa20 2027; hunm 2026; hunw 2026
team_idNoOne Team ID from cricbuzz/auction/options; current IPL 2026 values: 58, 59, 61, 62, 63, 64, 65, 255, 966, 971
currencyYesCurrency code from the selected edition: INR, USD, EUR, GBP, AUD, CAD, NZD, AED, ZAR, PKR, LKR, BDT, NPR
statusesNoComma-separated Status values from cricbuzz/auction/options; current IPL 2026 values: Sold, Unsold, Retained, RTM, Drafted, Replacement, Traded, Wild Card
tournamentYesTournament identifier from cricbuzz/auction/seasons; current values: ipl, wpl, sa20, hunm, hunw
country_idsNoComma-separated Country IDs from cricbuzz/auction/options; current IPL 2026 values: 96, 4, 6, 26, 9, 8, 2, 27, 527, 303, 14, 161, 72, 24, 13, 3, 23, 190, 11, 5, 384, 7, 15, 10, 12

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.18

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description carries the full disclosure burden and does it well: one 1-based page per call, up to 20 rows, and explicitly that the source exposes no total count or has-more flag — a genuinely important pagination constraint an agent would otherwise guess wrong. It omits failure behavior for invalid filter values and any auth/rate-limit notes.

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 sentences, front-loaded with what it returns, then how to source filter values, then cardinality, then pagination limits — a sensible priority order with no filler. There is mild redundancy between the discovery sentence and the schema's per-parameter 'from cricbuzz/auction/options' notes.

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 10-parameter tool with no output schema and no annotations, the description covers the two riskiest unknowns: page size and the absence of a has-more flag. What it does not cover is what a returned row actually contains, which the missing output schema leaves entirely undocumented, and the case-sensitivity of values pulled from the options menu.

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 coverage is 100%, so every parameter already carries its own description pointing at the same discovery endpoints and listing current values; this is the baseline-3 case. The description's one real addition is the cardinality rule (country_ids and statuses take comma-separated lists, the rest take a single value), but the schema already labels those two as comma-separated, making the added meaning marginal.

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 opening sentence names a specific verb and resource — 'filtered and sorted Cricbuzz completed-auction players' — which is enough to tell it apart from live-auction tools and from a single-player lookup. It stops short of explicitly naming the sibling that serves live auctions (cricbuzz_auction_live) or player detail (cricbuzz_auction_player), so differentiation is implied by 'completed' rather than stated.

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

Usage Guidelines4/5

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

It gives concrete preconditions: resolve tournament/year/currency via cricbuzz/auction/seasons and per-edition Country, Status, Team, Role, Cap and Sort values via cricbuzz/auction/options before calling. That is a clear usage recipe with named alternatives for discovery. It does not say when to prefer this over the live or upcoming auction endpoints, which is the one missing piece.

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