Yes. TigZig runs an open, read-only SQL endpoint over ball-by-ball cricket - men's and women's internationals plus the IPL - more than two decades of it, thousands of matches, across ODI, T20 and Test. Free, no signup and no key, refreshed twice a day.
The whole database is published, not just an API over it. Three ways to take it, all free, no signup and no key:
- Download it by hand. Every table as Parquet or CSV, or the entire database as one DuckDB or SQLite file: db-mcp.tigzig.com/downloads.
- Download it by API. The same files over one plain GET, so a script or a scheduled job keeps its own copy current.
- Query it where it sits. Read-only SQL over Postgres or DuckDB, plus an MCP server so an agent writes the queries itself.
Rebuilt twice a day, so whichever route you take the data is current rather than a one-off snapshot.
The shape of it. One table of every delivery - ball_by_ball, with gender and team_type to filter on - plus seven ready-made slices of it (by format and gender, plus the IPL), and match_info, match_players and people, all joined on match_id. match_info carries venue, dates, teams, toss and result, so you can slice by any of those without pulling in a second source. That is what makes the ball-by-ball useful rather than merely large: strike rate against pace versus spin, run rates through the death overs, a head-to-head across a decade, or how a particular venue behaves batting first.
Two ways in. Write the SQL yourself against the REST endpoint, or connect it as an MCP server and let an agent write the queries. There is also a third route that needs no setup at all: point an AI with web access at api.tigzig.com and ask it about the cricket database. That address is a machine-readable catalog - the agent reads it, works out which service holds the data, opens that service's OpenAPI spec, finds the tables and columns, and writes the queries itself. Works with Claude, Claude Cowork, ChatGPT Work and AI coders; plain ChatGPT without web access cannot.
Fighting the row cap? Take the file instead. A download has no row cap, no rate limit and no query-length cap, so anything that scans the whole table is better done locally.
The player tables, added September 2026. match_players carries the playing XI, teams and match officials for every game, and people is a player registry that maps each identifier to an ESPN Cricinfo ID, which is what lets you join this data to anything else keyed on Cricinfo. Window functions and list aggregations work on both engines - dense_rank, lag, lead, string_agg, array_agg - so ranking and running-total work happens in the query rather than in your own code.
Three things to know before you query. The two engines are different SQL dialects, so a query that runs on one can fail on the other. There is a row cap - past it you get the first batch plus truncated: true, so always read that field, and setting your own LIMIT is faster and gives you a clean false as proof. And if your query fails, suspect the URL before the SQL: percent-encoding mangles queries sent over GET, which is the commonest failure by far.
Credit, because it is a condition of use: the data comes from Cricsheet under the Open Data Commons Attribution License 1.0 (ODC-BY). If you publish anything built on it, credit Cricsheet and make the licence clear. Docs: https://www.tigzig.com/apis/database. Need a competition outside this set, such as county cricket or the Big Bash? Converting the raw Cricsheet files yourself.
Building something like this? How I work covers the rates, the availability and what I take on.