A
license-
qualityD
maintenanceMCP server for secure BigQuery access across multiple Google Cloud projects, enabling querying, schema exploration, and data analysis with SQL validation and read-only controls.
2
MIT
Google Big Query
Server Details
The BigQuery remote MCP server is a fully managed service that uses the Model Context Protocol to connect AI applications and LLMs to BigQuery data sources. It provides secure, standardized tools for AI agents to list datasets and tables, retrieve schemas, generate and execute SQL queries through natural language, and analyze data—enabling direct access to enterprise analytics data without requiring manual SQL coding.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
MCP client
Glama
MCP server
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
100% free. Your data is private.
Tool Definition Quality
A4.2/5.0
Tool DescriptionsA
Average 4/5 across 6 of 6 tools scored. Lowest: 3.4/5.
Server CoherenceA
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.
Available Tools
6 toolsexecute_sqlADestructiveInspect
Run a SQL query in the project and return the result. Prefer the execute_sql_readonly
tool if possible.
This tool can execute any query that bigquery supports including:
SQL Queries (SELECT, INSERT, UPDATE, DELETE, CREATE, etc.)
AI/ML functions like AI.FORECAST, ML.EVALUATE, ML.PREDICT
Any other query that bigquery supports.
Example Queries:
-- Insert data into a table.
INSERT INTO my_project.my_dataset.my_table (name, age)
VALUES ('Alice', 30);
-- Create a table.
CREATE TABLE my_project.my_dataset.my_table (
name STRING,
age INT64);
-- DELETE data from a table.
DELETE FROM my_project.my_dataset.my_table WHERE name = 'Alice';
-- Create Dataset
CREATE SCHEMA my_project.my_dataset OPTIONS (location = 'US');
-- Drop table
DROP TABLE my_project.my_dataset.my_table;
-- Drop dataset
DROP SCHEMA my_project.my_dataset;
-- Create Model
CREATE OR REPLACE MODEL my_project.my_dataset.my_model
OPTIONS (
model_type = 'LINEAR_REG'
LS_INIT_LEARN_RATE=0.15,
L1_REG=1,
MAX_ITERATIONS=5,
DATA_SPLIT_METHOD='SEQ',
DATA_SPLIT_EVAL_FRACTION=0.3,
DATA_SPLIT_COL='timestamp') AS
SELECT col1, col2, timestamp, label FROM my_project.my_dataset.my_table;
Queries executed using the execute_sql tool will have the job label
goog-mcp-server: true automatically set. Queries are charged to the project specified
in the projectId field.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| 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. | |
| projectId | Yes | Required. Project that will be used for query execution and billing. |
Output Schema
ParametersJSON 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. |
Tool Definition Quality
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that queries are charged to the project specified in projectId and that a job label 'goog-mcp-server: true' is automatically set. It also shows destructive operations like DELETE and DROP, consistent with the destructiveHint annotation. While it doesn't go into permissions or side effects beyond that, with annotations provided, this is adequate additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is quite long due to many query examples, but it is front-loaded with a clear purpose statement and structured into capabilities, examples, and notes. The examples are useful for a powerful tool, though some could be trimmed. It earns a 4 rather than 5 because of the verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's broad capability, provides billing and job-label context, and includes many examples of supported SQL statements. The input schema's description notes the synchronous timeout behavior. Together, this makes the description quite complete for a complex tool, though it omits error handling or permission details.
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 coverage is 100%, so parameters query, projectId, and dryRun are already well-described in the input schema. The description adds minimal semantic value beyond the schema—it only mentions that projectId is used for billing. This matches the baseline for high schema coverage.
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 clearly states the tool runs a SQL query and returns the result, specifying its broad scope (any BigQuery-supported query). It explicitly differentiates from the sibling tool execute_sql_readonly by noting that readonly should be preferred, implying this one is for write/DDL operations. Examples of INSERT, CREATE, DELETE, DROP, and model creation further clarify 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?
The description gives explicit guidance by saying 'Prefer the execute_sql_readonly tool if possible', establishing when to use this tool versus the read-only alternative. It also provides examples of query types (INSERT, CREATE, DELETE, DROP) that this tool is meant for, giving the agent clear situational context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
execute_sql_readonlyARead-onlyIdempotentInspect
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 have the job label
goog-mcp-server: true automatically set. Queries are charged to the project specified
in the projectId field.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| 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. | |
| projectId | Yes | Required. Project that will be used for query execution and billing. |
Output Schema
ParametersJSON 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. |
Tool Definition Quality
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds meaningful behavioral context: the tool enforces a SELECT-only restriction and returns an error for other statement types, automatically sets a job label, and charges queries to the project in projectId. This goes beyond the annotations' safety profile, though it does not elaborate on result formatting or timeout behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than minimal, but the length is justified by practical examples that illustrate important query forms and the explicit restrictions. It is front-loaded with the core purpose and usage guidance, followed by examples and billing notes. The structure is logical, though slightly verbose due to the example block.
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?
Given the tool's complexity (query execution, constraints, billing, ML functions), the description covers all critical aspects: purpose, restrictions, alternatives, examples, documentation link, and behavioral side effects. The output schema handles return values, so the description is sufficiently complete for an agent to select and invoke the tool appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents all three parameters (100% coverage), so a baseline of 3 is appropriate. The description adds extra value by clarifying that projectId determines billing, and provides rich examples showing how the query parameter is used, including complex BigQuery ML and forecasting functions. This enriches parameter understanding.
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 clear, specific verb+resource: 'Run a read-only SQL query in the project and return the result.' It explicitly distinguishes from sibling tools by stating 'Prefer this tool over execute_sql if possible' and clarifying that it only handles SELECT statements, making it unmistakable what this tool does.
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?
The description gives explicit usage guidance: use this tool for read-only queries, prefer it over execute_sql, and avoid non-SELECT statements like INSERT/UPDATE/DELETE. It also explains the consequence of violating the restriction (error returned) and provides a link to query syntax documentation, covering both when and when-not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_dataset_infoARead-onlyIdempotentInspect
Get metadata information about a BigQuery dataset.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| datasetId | Yes | Required. Dataset ID of the dataset request. | |
| projectId | Yes | Required. Project ID of the dataset request. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| id | No | Output only. The fully-qualified unique name of the dataset in the format projectId:datasetId. The dataset name without the project name is given in the datasetId field. When creating a new dataset, leave this field blank, and instead specify the datasetId field. |
| etag | No | Output only. A hash of the resource. |
| kind | No | Output only. The resource type. |
| tags | No | Output only. Tags for the dataset. To provide tags as inputs, use the `resourceTags` field. |
| type | No | Output only. Same as `type` in `ListFormatDataset`. The type of the dataset, one of: * DEFAULT - only accessible by owner and authorized accounts, * PUBLIC - accessible by everyone, * LINKED - linked dataset, * EXTERNAL - dataset with definition in external metadata catalog, * BIGLAKE_ICEBERG - a Biglake dataset accessible through the Iceberg API, * BIGLAKE_HIVE - a Biglake dataset accessible through the Hive API. |
| access | No | Optional. An array of objects that define dataset access for one or more entities. You can set this property when inserting or updating a dataset in order to control who is allowed to access the data. If unspecified at dataset creation time, BigQuery adds default dataset access for the following entities: access.specialGroup: projectReaders; access.role: READER; access.specialGroup: projectWriters; access.role: WRITER; access.specialGroup: projectOwners; access.role: OWNER; access.userByEmail: [dataset creator email]; access.role: OWNER; If you patch a dataset, then this field is overwritten by the patched dataset's access field. To add entities, you must supply the entire existing access array in addition to any new entities that you want to add. |
| labels | No | The labels associated with this dataset. You can use these to organize and group your datasets. You can set this property when inserting or updating a dataset. See [Creating and Updating Dataset Labels](https://cloud.google.com/bigquery/docs/creating-managing-labels#creating_and_updating_dataset_labels) for more information. |
| location | No | The geographic location where the dataset should reside. See https://cloud.google.com/bigquery/docs/locations for supported locations. |
| selfLink | No | Output only. A URL that can be used to access the resource again. You can use this URL in Get or Update requests to the resource. |
| description | No | Optional. A user-friendly description of the dataset. |
| creationTime | No | Output only. The time when this dataset was created, in milliseconds since the epoch. |
| friendlyName | No | Optional. A descriptive name for the dataset. |
| resourceTags | No | Optional. The [tags](https://cloud.google.com/bigquery/docs/tags) attached to this dataset. Tag keys are globally unique. Tag key is expected to be in the namespaced format, for example "123456789012/environment" where 123456789012 is the ID of the parent organization or project resource for this tag key. Tag value is expected to be the short name, for example "Production". See [Tag definitions](https://cloud.google.com/iam/docs/tags-access-control#definitions) for more details. |
| restrictions | No | Optional. Output only. Restriction config for all tables and dataset. If set, restrict certain accesses on the dataset and all its tables based on the config. See [Data egress](https://cloud.google.com/bigquery/docs/analytics-hub-introduction#data_egress) for more details. |
| satisfiesPzi | No | Output only. Reserved for future use. |
| satisfiesPzs | No | Output only. Reserved for future use. |
| catalogSource | No | Output only. The origin of the dataset, one of: * (Unset) - Native BigQuery Dataset * BIGLAKE - Dataset is backed by a namespace stored natively in Biglake |
| datasetReference | No | Required. A reference that identifies the dataset. |
| defaultCollation | No | Optional. Defines the default collation specification of future tables created in the dataset. If a table is created in this dataset without table-level default collation, then the table inherits the dataset default collation, which is applied to the string fields that do not have explicit collation specified. A change to this field affects only tables created afterwards, and does not alter the existing tables. The following values are supported: * 'und:ci': undetermined locale, case insensitive. * '': empty string. Default to case-sensitive behavior. |
| lastModifiedTime | No | Output only. The date when this dataset was last modified, in milliseconds since the epoch. |
| isCaseInsensitive | No | Optional. TRUE if the dataset and its table names are case-insensitive, otherwise FALSE. By default, this is FALSE, which means the dataset and its table names are case-sensitive. This field does not affect routine references. |
| maxTimeTravelHours | No | Optional. Defines the time travel window in hours. The value can be from 48 to 168 hours (2 to 7 days). The default value is 168 hours if this is not set. |
| defaultRoundingMode | No | Optional. Defines the default rounding mode specification of new tables created within this dataset. During table creation, if this field is specified, the table within this dataset will inherit the default rounding mode of the dataset. Setting the default rounding mode on a table overrides this option. Existing tables in the dataset are unaffected. If columns are defined during that table creation, they will immediately inherit the table's default rounding mode, unless otherwise specified. |
| linkedDatasetSource | No | Optional. The source dataset reference when the dataset is of type LINKED. For all other dataset types it is not set. This field cannot be updated once it is set. Any attempt to update this field using Update and Patch API Operations will be ignored. |
| storageBillingModel | No | Optional. Updates storage_billing_model for the dataset. |
| linkedDatasetMetadata | No | Output only. Metadata about the LinkedDataset. Filled out when the dataset type is LINKED. |
| defaultTableExpirationMs | No | Optional. The default lifetime of all tables in the dataset, in milliseconds. The minimum lifetime value is 3600000 milliseconds (one hour). To clear an existing default expiration with a PATCH request, set to 0. Once this property is set, all newly-created tables in the dataset will have an expirationTime property set to the creation time plus the value in this property, and changing the value will only affect new tables, not existing ones. When the expirationTime for a given table is reached, that table will be deleted automatically. If a table's expirationTime is modified or removed before the table expires, or if you provide an explicit expirationTime when creating a table, that value takes precedence over the default expiration time indicated by this property. |
| externalDatasetReference | No | Optional. Reference to a read-only external dataset defined in data catalogs outside of BigQuery. Filled out when the dataset type is EXTERNAL. |
| defaultPartitionExpirationMs | No | This default partition expiration, expressed in milliseconds. When new time-partitioned tables are created in a dataset where this property is set, the table will inherit this value, propagated as the `TimePartitioning.expirationMs` property on the new table. If you set `TimePartitioning.expirationMs` explicitly when creating a table, the `defaultPartitionExpirationMs` of the containing dataset is ignored. When creating a partitioned table, if `defaultPartitionExpirationMs` is set, the `defaultTableExpirationMs` value is ignored and the table will not be inherit a table expiration deadline. |
| externalCatalogDatasetOptions | No | Optional. Options defining open source compatible datasets living in the BigQuery catalog. Contains metadata of open source database, schema or namespace represented by the current dataset. |
| defaultEncryptionConfiguration | No | The default encryption key for all tables in the dataset. After this property is set, the encryption key of all newly-created tables in the dataset is set to this value unless the table creation request or query explicitly overrides the key. |
Tool Definition Quality
A3.6/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is explicit. The description adds that it returns 'metadata information' rather than data, but it does not disclose other behavioral traits such as permission requirements or behavior for nonexistent datasets. No contradiction with annotations.
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 a single clear sentence, front-loaded with the action and object, with no redundant words. It is appropriately sized for a simple getter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple read-only nature, full parameter schema coverage, and available output schema, the description sufficiently conveys the tool's purpose. It could optionally note that the return value is the dataset resource object, but the output schema covers that, so the description need not explain return values.
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?
The input schema fully documents both required parameters (projectId, datasetId) with descriptions. The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 applies.
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 'Get metadata information about a BigQuery dataset' uses a specific verb and resource, clearly indicating it retrieves dataset-level metadata. This distinguishes it from sibling tools like list_dataset_ids (which only lists IDs) and get_table_info (which focuses on table metadata).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It does not mention conditions, exclusions, or related tools such as execute_sql_readonly or list_dataset_ids, leaving the choice to the agent without contextual help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_table_infoBRead-onlyIdempotentInspect
Get metadata information about a BigQuery table.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tableId | Yes | Required. Table ID of the table request. | |
| datasetId | Yes | Required. Dataset ID of the table request. | |
| projectId | Yes | Required. Project ID of the table request. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| id | No | Output only. An opaque ID uniquely identifying the table. |
| etag | No | Output only. A hash of this resource. |
| kind | No | The type of resource ID. |
| type | No | Output only. Describes the table type. The following values are supported: * `TABLE`: A normal BigQuery table. * `VIEW`: A virtual table defined by a SQL query. * `EXTERNAL`: A table that references data stored in an external storage system, such as Google Cloud Storage. * `MATERIALIZED_VIEW`: A precomputed view defined by a SQL query. * `SNAPSHOT`: An immutable BigQuery table that preserves the contents of a base table at a particular time. See additional information on [table snapshots](https://cloud.google.com/bigquery/docs/table-snapshots-intro). The default value is `TABLE`. |
| view | No | Optional. The view definition. |
| labels | No | The labels associated with this table. You can use these to organize and group your tables. 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 values are optional. Label keys must start with a letter and each label in the list must have a different key. |
| schema | No | Optional. Describes the schema of this table. |
| numRows | No | Output only. The number of rows of data in this table, excluding any data in the streaming buffer. |
| location | No | Output only. The geographic location where the table resides. This value is inherited from the dataset. |
| numBytes | No | Output only. The size of this table in logical bytes, excluding any data in the streaming buffer. |
| replicas | No | Optional. Output only. Table references of all replicas currently active on the table. |
| selfLink | No | Output only. A URL that can be used to access this resource again. |
| clustering | No | Clustering specification for the table. Must be specified with time-based partitioning, data in the table will be first partitioned and subsequently clustered. |
| description | No | Optional. A user-friendly description of this table. |
| creationTime | No | Output only. The time when this table was created, in milliseconds since the epoch. |
| friendlyName | No | Optional. A descriptive name for this table. |
| maxStaleness | No | Optional. The maximum staleness of data that could be returned when the table (or stale MV) is queried. Staleness encoded as a string encoding of sql IntervalValue type. |
| resourceTags | No | Optional. The [tags](https://cloud.google.com/bigquery/docs/tags) attached to this table. Tag keys are globally unique. Tag key is expected to be in the namespaced format, for example "123456789012/environment" where 123456789012 is the ID of the parent organization or project resource for this tag key. Tag value is expected to be the short name, for example "Production". See [Tag definitions](https://cloud.google.com/iam/docs/tags-access-control#definitions) for more details. |
| restrictions | No | Optional. Output only. Restriction config for table. If set, restrict certain accesses on the table based on the config. See [Data egress](https://cloud.google.com/bigquery/docs/analytics-hub-introduction#data_egress) for more details. |
| numPartitions | No | Output only. The number of partitions present in the table or materialized view. This data is not kept in real time, and might be delayed by a few seconds to a few minutes. |
| expirationTime | No | Optional. The time when this table expires, in milliseconds since the epoch. If not present, the table will persist indefinitely. Expired tables will be deleted and their storage reclaimed. The defaultTableExpirationMs property of the encapsulating dataset can be used to set a default expirationTime on newly created tables. |
| tableReference | No | Required. Reference describing the ID of this table. |
| cloneDefinition | No | Output only. Contains information about the clone. This value is set via the clone operation. |
| streamingBuffer | No | Output only. Contains information regarding this table's streaming buffer, if one is present. This field will be absent if the table is not being streamed to or if there is no data in the streaming buffer. |
| defaultCollation | No | Optional. Defines the default collation specification of new STRING fields in the table. During table creation or update, if a STRING field is added to this table without explicit collation specified, then the table inherits the table default collation. A change to this field affects only fields added afterwards, and does not alter the existing fields. The following values are supported: * 'und:ci': undetermined locale, case insensitive. * '': empty string. Default to case-sensitive behavior. |
| lastModifiedTime | No | Output only. The time when this table was last modified, in milliseconds since the epoch. |
| managedTableType | No | Optional. If set, overrides the default managed table type configured in the dataset. |
| materializedView | No | Optional. The materialized view definition. |
| numLongTermBytes | No | Output only. The number of logical bytes in the table that are considered "long-term storage". |
| numPhysicalBytes | No | Output only. The physical size of this table in bytes. This includes storage used for time travel. |
| tableConstraints | No | Optional. Tables Primary Key and Foreign Key information |
| timePartitioning | No | If specified, configures time-based partitioning for this table. |
| rangePartitioning | No | If specified, configures range partitioning for this table. |
| snapshotDefinition | No | Output only. Contains information about the snapshot. This value is set via snapshot creation. |
| defaultRoundingMode | No | Optional. Defines the default rounding mode specification of new decimal fields (NUMERIC OR BIGNUMERIC) in the table. During table creation or update, if a decimal field is added to this table without an explicit rounding mode specified, then the field inherits the table default rounding mode. Changing this field doesn't affect existing fields. |
| partitionDefinition | No | Optional. The partition information for all table formats, including managed partitioned tables, hive partitioned tables, iceberg partitioned, and metastore partitioned tables. This field is only populated for metastore partitioned tables. For other table formats, this is an output only field. |
| biglakeConfiguration | No | Optional. Specifies the configuration of a BigQuery table for Apache Iceberg. |
| numTotalLogicalBytes | No | Output only. Total number of logical bytes in the table or materialized view. |
| tableReplicationInfo | No | Optional. Table replication info for table created `AS REPLICA` DDL like: `CREATE MATERIALIZED VIEW mv1 AS REPLICA OF src_mv` |
| numActiveLogicalBytes | No | Output only. Number of logical bytes that are less than 90 days old. |
| numTotalPhysicalBytes | No | Output only. The physical size of this table in bytes. This also includes storage used for time travel. This data is not kept in real time, and might be delayed by a few seconds to a few minutes. |
| materializedViewStatus | No | Output only. The materialized view status. |
| numActivePhysicalBytes | No | Output only. Number of physical bytes less than 90 days old. This data is not kept in real time, and might be delayed by a few seconds to a few minutes. |
| requirePartitionFilter | No | Optional. If set to true, queries over this table require a partition filter that can be used for partition elimination to be specified. |
| encryptionConfiguration | No | Custom encryption configuration (e.g., Cloud KMS keys). |
| numCurrentPhysicalBytes | No | Output only. Number of physical bytes used by current live data storage. This data is not kept in real time, and might be delayed by a few seconds to a few minutes. |
| numLongTermLogicalBytes | No | Output only. Number of logical bytes that are more than 90 days old. |
| numLongTermPhysicalBytes | No | Output only. Number of physical bytes more than 90 days old. This data is not kept in real time, and might be delayed by a few seconds to a few minutes. |
| externalDataConfiguration | No | Optional. Describes the data format, location, and other properties of a table stored outside of BigQuery. By defining these properties, the data source can then be queried as if it were a standard BigQuery table. |
| numTimeTravelPhysicalBytes | No | Output only. Number of physical bytes used by time travel storage (deleted or changed data). This data is not kept in real time, and might be delayed by a few seconds to a few minutes. |
| externalCatalogTableOptions | No | Optional. Options defining open source compatible table. |
Tool Definition Quality
B3.4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds no additional behavioral context such as permission requirements or error conditions, but it does not contradict the annotations.
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 a single concise sentence that is front-loaded with the key verb and object, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple metadata retrieval tool with a well-defined schema and annotations, the description is adequate. The output schema presumably defines the return format, so the description does not need to enumerate metadata fields. However, it could explicitly mention the table-level scope to differentiate from dataset-level information.
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 coverage is 100% with each parameter described as 'Required. X ID of the table request.' The description adds no additional meaning beyond these schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('metadata information about a BigQuery table'). It is distinct from sibling tools like list_table_ids and get_dataset_info, but it does not explicitly differentiate itself from them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as get_dataset_info or list_table_ids. The description simply states what it does without giving selection criteria or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_dataset_idsARead-onlyIdempotentInspect
List BigQuery dataset IDs in a Google Cloud project.
Supports pagination. Use page_size to limit results and page_token to retrieve next page.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| pageSize | No | Optional. The maximum number of results to return in a single response page. If unset, the default page size of 5000 is used. | |
| pageToken | No | Optional. Page token, returned by a previous call, to request the next page of results. | |
| projectId | Yes | Required. Project ID of the dataset request. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| datasets | No | The datasets that matched the request. |
| nextPageToken | No | A token that can be used to request the next results page. |
Tool Definition Quality
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value by disclosing pagination behavior and noting that page_size and page_token control result pages, which goes beyond the annotations. It does not contradict any annotations.
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 two sentences with no wasted words. It front-loads the primary purpose in the first sentence and adds pagination detail in the second, making it easy to scan and understand.
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 tool has a simple list operation with an output schema and rich annotations. The description clearly states what it lists, the project scope, and pagination support. The output schema handles return value details, and annotations cover safety. No critical context is missing.
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 schema fully documents each parameter. The description mentions page_size and page_token but essentially repeats the schema's semantic content. It does not add new meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
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 clearly states the tool's function: 'List BigQuery dataset IDs in a Google Cloud project.' It uses a specific verb and resource, and the name and description distinguish it from siblings like list_table_ids and get_dataset_info. The mention of pagination adds helpful scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing dataset IDs and mentions pagination parameters, but it does not explicitly compare with alternatives or state when to use this tool over siblings. There is no exclusion guidance, so the usage context is clear but not fully elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_table_idsARead-onlyIdempotentInspect
List table ids in a BigQuery dataset.
Supports pagination. Use page_size to limit results and page_token to retrieve next page.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| pageSize | No | Optional. The maximum number of results to return in a single response page. If unset, the default page size of 5000 is used. | |
| datasetId | Yes | Required. Dataset ID of the table request. | |
| pageToken | No | Optional. Page token, returned by a previous call, to request the next page of results. | |
| projectId | Yes | Required. Project ID of the table request. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| tables | No | The tables that matched the request. |
| nextPageToken | No | A token that can be used to request the next results page. |
Tool Definition Quality
A4.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is clear. The description adds pagination behavior (use of page_size and page_token), which is useful context beyond the annotations. However, it does not mention anything else like result ordering or potential consistency caveats. This is adequate but not rich, so a 3 is appropriate.
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 two sentences long, front-loaded with the primary purpose, and every sentence adds value. There is no fluff or redundancy.
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?
For a simple listing tool with pagination, the description covers what it does and how to paginate. An output schema exists, so return-value details are not needed. The tool name and description together make the scope unambiguous. This is complete for the complexity level.
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?
The input schema has 100% coverage, with each parameter already described. The description reiterates page_size and page_token but does not add new meaning beyond the schema details. Since the schema handles the heavy lifting, a baseline of 3 is warranted.
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 clearly states the tool's purpose with a specific verb and resource: 'List table ids in a BigQuery dataset.' This distinguishes it from siblings like execute_sql (running queries), get_table_info (detailed table metadata), and list_dataset_ids (dataset-level listing). The scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool (to list table IDs in a dataset) and includes pagination instructions for use. It does not explicitly name alternatives or provide 'when not to use' exclusions, but the purpose statement and pagination guidance make the usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Servers
- Alicense-qualityBmaintenanceEnterprise-grade MCP server for Google Cloud BigQuery with keyless Workload Identity Federation authentication, enabling secure SQL query execution, dataset management, and schema inspection with comprehensive audit logging and encryption.MIT
- Alicense-qualityDmaintenanceProduction-ready MCP server for BigQuery that translates natural language questions to SQL, executes queries securely, and delivers results via stdio or HTTP for integration with GitHub Copilot, Power BI, and web applications.310MIT
- Alicense-qualityDmaintenanceA Model Context Protocol (MCP) server that enables LLMs to interact with Google BigQuery.MIT