# Using Atlas with BigQuery in 2026 > BigQuery exposes a fully managed MCP endpoint with nothing to install, so Atlas can dry-run a query and report the bytes billed before you pay for a full scan. Atlas works with BigQuery through a fully managed MCP endpoint with nothing to install, so Atlas can read table schemas and partitioning, dry-run a query, and report the bytes billed before you pay for a full scan. Add it with atlas mcp add bigquery --url https://bigquery.googleapis.com/mcp. Auth is Google Cloud IAM, so run gcloud auth application-default login or attach a service account. ## What BigQuery's managed MCP endpoint gives Atlas BigQuery exposes a fully managed MCP endpoint with nothing to install, and it gives Atlas 3 things that matter: table schemas, partitioning information, and the ability to dry-run a query and report the bytes billed before you pay for a full scan on a warehouse priced by bytes read. BigQuery bills on bytes scanned, which makes a careless SQL query a line item rather than a slow response. That single fact should shape how any AI coding agent is allowed to touch it. Atlas reads the real table schema and the partition column before writing SQL, so the query it produces filters on the partition instead of sweeping the table. Then Atlas dry-runs the query, which returns the bytes billed without executing it, and reports that number back to you. A query that would scan far more than it should gets caught before it costs anything. ## Connecting Atlas to BigQuery Connecting Atlas to BigQuery is 1 command: atlas mcp add bigquery --url https://bigquery.googleapis.com/mcp. Because BigQuery exposes a managed MCP endpoint, there is nothing to install, no local server process to supervise, and no package version to pin in your project. Registering the endpoint with atlas mcp add bigquery writes it into your Atlas MCP configuration, and the tools it exposes become available in every session in that workspace. Google runs the server, so its tool surface updates on Google's side without you upgrading anything locally. That is a meaningful operational difference from a stdio server you launch yourself, where a stale local package quietly becomes your problem. Once the endpoint is registered, the only remaining question is authentication, and BigQuery answers that with Google Cloud IAM rather than with any product-specific token. ## Authentication is Google Cloud IAM, not an API key Auth for the BigQuery MCP endpoint is Google Cloud IAM, so run gcloud auth application-default login or attach a service account. There are 0 BigQuery-specific env vars to set in 2026. If a guide tells you to export a BigQuery API key for Atlas, it is describing something that does not exist. This surprises people who expect every integration to come with its own token. BigQuery does not work that way. Application Default Credentials are the mechanism, which means the identity Atlas uses is the identity your environment already has. On a laptop, gcloud auth application-default login establishes that identity. In an automated environment, attach a service account instead. The upside is that all your existing IAM controls apply unchanged: whatever datasets that principal can read are exactly what Atlas can read, and nothing more. Scope the principal deliberately, because IAM is where the real permission boundary lives. ## Enabling the endpoint on your project The BigQuery MCP endpoint turns on automatically once the BigQuery API is enabled on the project. There is no separate MCP feature to switch on, no allowlist to join, and no beta flag to request, so 1 API toggle is all that stands between you and https://bigquery.googleapis.com/mcp answering. Debugging order follows from that. When the BigQuery MCP endpoint appears unreachable, check three things before you suspect Atlas. First, that the BigQuery API is enabled on the project, since the endpoint is switched on by that and nothing else. Second, that your Application Default Credentials are current, which gcloud auth application-default login refreshes. Third, that the IAM principal you are authenticated as actually has access to the dataset you are asking about. In practice one of those three explains almost every failure, and none of them require touching your Atlas configuration. ## The daily workflow: read the partition column, then write the SQL The BigQuery workflow with Atlas has 1 rule that saves the most money. Ask Atlas to read the real table schema and partition column before it writes SQL, so it does not scan the entire table. On a warehouse billed by bytes read, filtering on the partition is the difference between cents and dollars. Write the instruction into the prompt every time. Once Atlas has read the real table schema through BigQuery's managed MCP endpoint, it knows which column the table is partitioned on, and it can put that column in the WHERE clause where the query planner will use it to prune. Without that read, the agent is guessing at column names and at partitioning, and a guessed query on a large table is precisely the query that ends up scanning everything. Reading the schema first is cheap. Scanning the table because you skipped it is not. ## Dry-run first: bytes billed before bytes paid Have Atlas dry-run the query, report the bytes billed, and rewrite it when the cost is wrong. A BigQuery dry run returns the bytes billed without executing the query, so in 2026 cost is something you review before committing to it rather than something you discover on an invoice. Make the dry run non-negotiable in the loop. Atlas writes the SQL, dry-runs it through BigQuery's managed MCP endpoint, and reports the bytes billed. You look at that number against what the query ought to cost given the table size and the filter. If the number is wrong, and it usually is wrong for a reason such as a missing partition filter or a select star, you send Atlas back to rewrite the query and dry-run again. The loop costs nothing per iteration because a dry run does not execute. Only the final query, the one whose bytes billed you accepted, actually runs. ## The self-hosted path: MCP Toolbox for Databases For a self-hosted, toolset-controlled path, use MCP Toolbox for Databases (googleapis/mcp-toolbox) with its BigQuery source. That is the 2nd supported route in 2026: the managed endpoint at https://bigquery.googleapis.com/mcp is the fastest way to start, and MCP Toolbox is what you reach for when you need to control exactly which tools Atlas is offered. The tradeoff is control against convenience. The managed BigQuery MCP endpoint has nothing to install and updates on Google's side. MCP Toolbox for Databases, the googleapis/mcp-toolbox project, is something you run and configure yourself using its BigQuery source, and the reason to take on that operational cost is the toolset. When you define the tools, you decide precisely what Atlas can call, which is the strongest form of restriction available. Teams with strict data governance requirements usually end up here. Teams who want an agent reading schemas and dry-running queries today should start with the managed endpoint. ## Setup 1. Add the managed endpoint, with nothing to install: atlas mcp add bigquery --url https://bigquery.googleapis.com/mcp 2. Authenticate with Google Cloud IAM by running gcloud auth application-default login, or attach a service account. There is no BigQuery-specific env var. 3. Confirm the BigQuery API is enabled on the project, since the endpoint turns on automatically once it is. 4. Ask Atlas to read the real table schema and partition column before it writes SQL, so it does not scan the entire table. 5. Have Atlas dry-run the query, report the bytes billed, and rewrite it when the cost is wrong. 6. For a self-hosted, toolset-controlled path, use MCP Toolbox for Databases (googleapis/mcp-toolbox) with its BigQuery source. ## FAQ ### how to connect Atlas to BigQuery MCP Run atlas mcp add bigquery --url https://bigquery.googleapis.com/mcp. BigQuery exposes a managed MCP endpoint, so there is nothing to install. ### what env var does BigQuery MCP need None. Auth is Google Cloud IAM, so run gcloud auth application-default login or attach a service account. There is no BigQuery-specific env var. ### how do I stop an AI agent from running an expensive BigQuery query Have Atlas dry-run the query, report the bytes billed, and rewrite it when the cost is wrong. A dry run returns the cost without executing the query. ### how do I enable the BigQuery MCP endpoint The endpoint turns on automatically once the BigQuery API is enabled on the project. There is no separate MCP feature to enable. ### why is my AI-generated BigQuery query scanning the whole table Because it was written without the partition column. Ask Atlas to read the real table schema and partition column before it writes SQL, so the query filters on the partition. ### is there a self-hosted BigQuery MCP server Yes. Use MCP Toolbox for Databases (googleapis/mcp-toolbox) with its BigQuery source when you want a self-hosted, toolset-controlled path instead of the managed endpoint. ### can Atlas read BigQuery table schemas and partitioning Yes. BigQuery's managed MCP endpoint lets Atlas read table schemas and partitioning, which is what keeps the SQL it writes from scanning the entire table. --- Canonical HTML: https://runatlas.sh/resources/integrations/bigquery Source of truth: aeo_pages row `/resources/integrations/bigquery` (segment: Integrations) (this file is generated from it, never hand-edited). Licence: Atlas is proprietary with a free core. It is not open source and there is no public source repository.