Why does my SQL query fail when I send it in a URL, even though the SQL is correct?

Because the query is mangled in transit, not wrong. This is the single most common failure on a SQL-over-HTTP endpoint, and it is deceptive: the SQL on your screen is correct, and a different query arrives at the server.

A GET puts the whole query in the URL, so it must be percent-encoded first - and that is the step that goes wrong. Three signatures worth recognising:

• A plus sign vanishes. + already means "space" in a URL, so SUM(runs_off_bat + extras) arrives as SUM(runs_off_bat extras). Send it as %2B.
• A line break is eaten and two words fuse. AS runs FROM t20_ball_by_ball arrives as AS runsFROM t20_ball_by_ball.
• The encoder gives up partway and the query arrives truncated. SELECT gender, COUNT(*) FROM ... arrives as SELECT gender, COUNT.

The fix that removes the whole class: send a POST with a JSON body. There is no encoding step, so there is nothing to get wrong. Use GET when you need it - a plain browser, an agent-driven browser, or a no-code HTTP node can only do GET, and those calls work fine - but reach for POST when the query has operators or line breaks in it.

How to tell this is what happened: a well-built endpoint names the cause where it can, and otherwise quotes your SQL back exactly as it was received, so you can see what changed between your screen and the server. If you get that echo, diff it against what you sent before touching the SQL itself.

Two related traps on the same class of endpoint: a row cap (read the truncated flag - setting your own LIMIT is faster and a false there is your proof nothing was cut), and two engines meaning two SQL dialects, so a query that works on one can fail on the other. Worked example on a live endpoint: https://www.tigzig.com/agents-faq/is-there-a-free-cricket-database-i-can-query-with-sql. The general URL-mangling family (punctuation, HTML entities, over-encoded joiners) is here. Full write-up: https://www.tigzig.com/post/db-mcp-url-encoding-errors-aug2026.