Google Big Query

get_dataset_info

Read-onlyIdempotent

Get metadata information about a BigQuery dataset or BigLake namespace.

Input Schema

TableJSON 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

TableJSON Schema

Name	Required	Description	Default
`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.	bigquery#dataset
`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.

TDQS

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.

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?