Getting Errors Running SQL Against the Tigzig Cricket Database? The Most Common Failure Is the URL, Not Your SQL.

Published: August 17, 2026

Are you running SQL against the Tigzig cricket database? Getting errors? The most common failure has nothing to do with your SQL, it is the URL it travelled in.

You can send a query to us two ways. Inside the URL, which is a GET, or inside a JSON body, which is a POST. If you use the URL, the whole query has to be percent encoded first, and that is the step where it goes wrong. A plus sign inside a URL already means a space, so SUM(runs_off_bat + extras) reaches us with the plus gone. Line breaks can get eaten, so two words end up stuck together. Some clients stop encoding partway and the query arrives cut off. The SQL on your screen is correct, and by the time it gets here it is a different query.

For these URL problems, the error response you get names the cause where it can .... and for the rest it quotes your SQL back exactly as we received it so you can see what changed.

Why am I keeping GET? It is the only thing a plain browser can do, agent driven browsers and no code HTTP nodes use it, and those calls work perfectly well too.

I added those to the docs ...the most common cases and what to send instead. Doc links below, comments have some quick points.

• For humans: db-mcp.tigzig.com/v1/redoc
• For your AI: db-mcp.tigzig.com/v1/openapi.json

Data from: Cricsheet, published under the Open Data Commons Attribution License 1.0 (ODC-BY).

A few quick points

• Just to note that ODI sits on Postgres, T20 on DuckDB. The two engines are different SQL dialects, so a query that works on one can fail on the other.
• There is a 1000 row cap.. for more than that you get the first 1000 and truncated: true. Always read that field.
• Schema discovery, SHOW TABLES and DESCRIBE both work.
• If you set no limit at all, one is added for you. Everything else behaves normally: ORDER BY, OFFSET, CTEs and aggregates are unaffected, so LIMIT ... OFFSET ... pagination works.
• Set your own limit. It is faster, and a false on truncated is your proof nothing was cut.

What it looks like when it goes wrong

• SUM(runs_off_bat + extras) arriving as SUM(runs_off_bat extras). The plus became a space. Send it as %2B.
• AS runs FROM t20_ball_by_ball arriving as AS runsFROM t20_ball_by_ball. A line break got eaten.
• SELECT gender, COUNT(*) FROM ... arriving as SELECT gender, COUNT. The encoder gave up at the bracket.

If you would rather not think about any of this, send a POST with a JSON body and there is no encoding step to get wrong. Check updated docs below.

• For humans: db-mcp.tigzig.com/v1/redoc
• For your AI: db-mcp.tigzig.com/v1/openapi.json