Google Big Query

execute_sql_readonly

Read-onlyIdempotent

Run a read-only SQL query in the project and return the result. Prefer this tool over execute_sql if possible.

This tool is restricted to only SELECT statements. INSERT, UPDATE, and DELETE statements and stored procedures aren't allowed. If the query doesn't include a SELECT statement, an error is returned. For information on creating queries, see the GoogleSQL documentation.

Example Queries:

-- Count the number of penguins in each island.
SELECT island, COUNT(*) AS population
FROM bigquery-public-data.ml_datasets.penguins GROUP BY island

-- Evaluate a bigquery ML Model.
SELECT * FROM ML.EVALUATE(MODEL `my_dataset.my_model`)

-- Evaluate BigQuery ML model on custom data
SELECT *
FROM ML.EVALUATE(MODEL `my_dataset.my_model`, (SELECT * FROM `my_dataset.my_table`))

-- Predict using BigQuery ML model:
SELECT *
FROM ML.PREDICT(MODEL `my_dataset.my_model`, (SELECT * FROM `my_dataset.my_table`))

-- Forecast data using AI.FORECAST
SELECT *
FROM AI.FORECAST(TABLE `project.dataset.my_table`, data_col => 'num_trips',
  timestamp_col => 'date', id_cols => ['usertype'], horizon => 30)

Queries executed using the execute_sql_readonly tool will always have the job label goog-mcp-server: true automatically set in addition to any custom labels provided in the request. Queries are charged to the project specified in the project_id field.

Input Schema

TableJSON Schema

Name	Required	Description
`query`	Yes	Required. The query to execute in the form of a GoogleSQL query.
`dryRun`	No	Optional. If set to true, BigQuery doesn't run the job. Instead, if the query is valid, BigQuery returns statistics about the job such as how many bytes would be processed. If the query is invalid, an error returns. The default value is false.
`labels`	No	Optional. The labels associated with this query. Labels can be used to organize and group query jobs. Label keys and values can be no longer than 63 characters, can only contain lowercase letters, numeric characters, underscores and dashes. International characters are allowed. Label keys must start with a letter and each label in the map must have a different key.
`projectId`	Yes	Required. Project that will be used for query execution and billing.

Output Schema

TableJSON Schema

Name	Required	Description
`rows`	No	An object with as many results as can be contained within the maximum permitted reply size. To get any additional rows, you can call GetQueryResults and specify the jobReference returned above.
`errors`	No	Output only. The first errors or warnings encountered during the running of the job. The final message includes the number of errors that caused the process to stop. Errors here do not necessarily mean that the job has completed or was unsuccessful. For more information about error messages, see [Error messages](https://cloud.google.com/bigquery/docs/error-messages).
`schema`	No	The schema of the results. Present only when the query completes successfully.
`queryId`	No	Output only. The ID of the query.
`jobComplete`	No	Whether the query has completed or not. If rows or totalRows are present, this will always be true. If this is false, totalRows will not be available.
`totalSlotMs`	No	Output only. Number of slot ms the user is actually billed for.
`totalBytesBilled`	No	Output only. The total number of bytes billed for the query. Only applies if the project is configured to use on-demand pricing.
`numDmlAffectedRows`	No	Output only. The number of rows affected by a DML statement.
`totalBytesProcessed`	No	Output only. The total number of bytes processed for this query.

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint and idempotentHint annotations, the description discloses key behaviors: only SELECT queries are accepted, non-SELECT queries return an error, a job label is automatically set, and queries are billed to the specified project. This gives the agent useful operational context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-structured and purposeful. The purpose and restriction are front-loaded, followed by relevant examples and operational notes. The example queries earn their place because they demonstrate valid SELECT, ML.EVALUATE, ML.PREDICT, and AI.FORECAST usage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is complete for this tool: it states what the tool does, when to prefer it, what restrictions apply, what error behavior to expect, and provides concrete query examples. The output schema covers return-value expectations, so no additional return-format detail is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the parameter definitions already carry the semantic load. The description adds helpful examples and notes about billing, but it does not significantly expand on the parameter meanings beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Run a read-only SQL query in the project and return the result.' It also explicitly distinguishes itself from execute_sql by restricting to SELECT statements, so an agent can clearly identify its purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit routing instruction: 'Prefer this tool over execute_sql if possible.' It also defines when not to use it by stating that INSERT, UPDATE, DELETE, and stored procedures are not allowed and will produce an error, making the alternative usage clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Google Big Query tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0

Disambiguation5/5

Each tool has a distinct purpose: execute_sql and execute_sql_readonly are clearly separated by write/read access, while get_dataset_info, get_table_info, list_dataset_ids, and list_table_ids cover distinct metadata retrieval operations. No overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern: execute_sql, get_dataset_info, get_table_info, list_dataset_ids, list_table_ids. The verb clearly indicates the action (execute, get, list) and the noun indicates the target resource.

Tool Count5/5

With 6 tools, the set is well-scoped for a BigQuery server. It provides both query execution and metadata listing/inspection without unnecessary duplication or bloat.

Completeness5/5

The tool set covers both data manipulation and metadata discovery. The execute_sql tool supports all BigQuery SQL (SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, etc.), allowing full lifecycle management. Metadata tools provide listing and detailed info for datasets and tables, covering the core introspection needs.

Resources

Need Help?