We do not generate SQL · the agent does · the pipeline is versioned
Text to SQL, and then what?
We do not generate SQL. Your agent does that, and it is already good at it. What it usually lacks is everything on either side of the query: the real schema going in, and somewhere durable for the answer to live coming out. That is what this server is.
A natural-language-to-SQL layer answers a question once, in one session, against one database. Three days later the question comes back, and nothing about the first answer helps.
What the agent gets here
datasources_get_schemas, datasources_get_tables, datasources_get_columns and datasources_preview_rows — the agent looks at the columns and a few real values first, so its SQL is grounded rather than inferred.
The query is saved as a template, referenced by a pipeline in declarative JSON. It has a name, parameters, and a diff. Somebody else can run it without asking the agent again.
Editing a released pipeline copies it to a draft; the release keeps running until a person releases the new one. Last quarter's number is reproducible because last quarter's SQL still exists.
Catalogued {domain}.{entity}.{failure} codes with details — a missing parameter, an unreachable datasource, a refused write — instead of a driver message to parse.
executions_get_result pages the real result through a cursor, so the agent checks its own answer against the data rather than declaring victory.
The server ships a debug_failed_execution prompt that walks a failed run to a diagnosis — the failure path, treated as a first-class part of the agent's job.
The question that stops a single-database text-to-SQL tool dead — "revenue by borough", where the trips are in Postgres and the zone lookup is in SQLite — is an ordinary pipeline here. Each source is read in place, staged into an in-memory database created for that one execution, and joined there. The worked example, with its SQL.
Asked before
No — your agent does that, and the page says so in its first sentence. What the server adds is everything on either side: the real schema going in, and a versioned, reviewable artefact coming out. The grounding tools are docs/mcp-server.md §6.1.
It becomes an artefact: the SQL is saved as a template referenced by a pipeline in declarative JSON — named, parameterised, diffable — so anyone can rerun it without asking the agent again. The pipeline shape is docs/pipeline-contract.md §3.1.
A catalogued {domain}.{entity}.{failure} code with details — a missing parameter, an unreachable datasource, a refused write — instead of a driver message to parse, so the agent can branch on the code. The error-code catalog is docs/pipeline-contract.md §13.
Yes — each source is read in place and staged into an in-memory database created for that one execution, and the join runs there as ordinary SQL. That is the staging join, and the worked example runs it on real NYC data. Staging is docs/staging.md §1.
The one you answered three times this month is the right pilot. On the demo stack, the answer becomes a pipeline with a version number — and the fourth time, nobody asks you.