get_table_schemaLABSCO SUMMARY
Two tools and a list, for an agent you do not fully trust.
The design assumes the thing asking the question might be a customer-facing bot, a third-party tool, or a document carrying an injection. So the answer is a tiny surface, a table allowlist enforced in the parser, and a cost ceiling that is a property of the deployment rather than something you hope the model respects.
What it is
A BigQuery server you deploy into your own Google Cloud project on Cloud Run, reached over HTTPS with an API key in a header. It exposes exactly two things — reading the schema of tables you have allowlisted, and running SELECT queries against them — and enforces that in the application rather than leaving it to IAM alone.
What you get
- Schema reads for the allowlisted tables, returned in a shape that is the same for one table or many
- SELECT queries, with DDL, DML, scripting, multi-statement bodies and procedural constructs rejected by the SQL parser
- A hard allowlist of dataset and table pairs: a qualified reference into a dataset you did not allow is refused, a bare name that exists in two allowed datasets is refused as ambiguous, and CTE names are correctly exempt
- A dry run before every query, so one that would scan more than your ceiling is rejected without a BigQuery job being created or a byte being billed
- A row cap that truncates results server-side before they reach a context window
- Token-bucket rate limiting with burst, plus separate concurrency limits for queries and metadata calls
- Cached schema lookups and dry runs, with an admin endpoint to invalidate them after a schema change
- Configuration entirely through environment variables, so adding a table is a redeploy rather than a config file
Requirements
A Google Cloud project with Cloud Run, BigQuery, Secret Manager, Artifact Registry and IAM enabled, and a dedicated service account holding job-user on the project and data-viewer on each allowlisted dataset — nothing broader. Two keys, generated by you and stored in Secret Manager: one clients present on every request, one for the admin endpoint. Clients connect through an MCP proxy over streamable HTTP. Cloud Run scales to zero, which means near-nothing at idle and a few seconds of cold start on the first request unless you keep an instance warm. Deployment is regional, and the schema cache is per instance. What it deliberately does not do: no column-level masking, so allowlist an authorized view if your tables hold columns an agent should not see; no per-user attribution behind the shared key; no prompt-injection scanning; and no writes, ever.
Setup effort
Build from source — clone the repository, then follow the project's own run instructions
USE CASES
01
Letting an agent query the warehouse without opening the warehouse
The agent reads the schema of the tables you allowlisted and queries those, and nothing else in the project is reachable — the allowlist is enforced in the parser, not only in IAM.
02
Capping what one careless query can cost
Each query is estimated by a dry run first and refused if it would scan more than your ceiling, so no BigQuery job is created and no bytes are billed for the query that would have hurt.
03
Answering campaign questions across channels
With ad exports landed in one dataset, ask for the best-performing campaign over a period and get the query run against just those tables, truncated to a sane number of rows.
2 tools
Listed in project docs. Your client may show a different list.
query_assessmentsBEFORE YOU INSTALL
What to know first
Tools you get
2 tools named in the project's documentation. There is no write support, by design. Queries are limited by MAX_SCAN_MB, MAX_RESULT_ROWS, RATE_LIMIT_QPM and a dataset and table allowlist.
Requires
MCP_API_KEY in your environment
INSTALLATION
Connect your client
Server setup
TERMINAL
git clone https://github.com/hugonissar/bigquery-readonly-mcp-server.gitMCP Clients
Claude Desktop
CLAUDE DESKTOP · JSON
{
"mcpServers": {
"bigquery": {
"command": "/home/<YOUR_USERNAME>/.local/bin/uvx",
"args": [
"mcp-proxy",
"--transport",
"streamablehttp",
"-H",
"x-api-key",
"<YOUR_MCP_API_KEY>",
"https://<YOUR_BIGQUERY_READONLY_MCP_RUN>/mcp"
]
}
}
}/home/<YOUR_USERNAME>/.local/bin/uvx is the full path to uvx on your machine (which uvx prints it), and https://<YOUR_BIGQUERY_READONLY_MCP_RUN> is the URL of the Cloud Run service you deployed (keep /mcp on the end), and <YOUR_MCP_API_KEY> is the key you generated and stored as the mcp-api-key secret.
