looker-studio-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LOOKER_STUDIO_MCP_PROJECT | No | Default project for BigQuery tools. Overrides the project_id setting in the config file. | |
| LOOKER_STUDIO_MCP_HEADLESS | No | Set to false to run the browser in headed mode (or use the --headed CLI flag). Overrides the auth.headless setting in the config file. | |
| LOOKER_STUDIO_MCP_CREDENTIALS_FILE | No | Path to a service account or authorized_user JSON credentials file. Overrides the auth.credentials_file setting in the config file. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| check_authA | Check the Google API credentials (BigQuery) and the signed-in Looker Studio browser profile. Use first when other tools fail with auth errors. |
| list_datasetsC | List the BigQuery datasets of a Google Cloud project. |
| list_tablesB | List the tables and views of a BigQuery dataset. |
| describe_tableA | Show the fields of a table or view, its row count and, for views, the SQL. |
| run_queryA | Run one SELECT in GoogleSQL and return the rows as a table. Writes are refused. Use dry_run to check a query and how many bytes it scans before running it. |
| list_reportsB | List the Looker Studio reports of the signed-in account, optionally filtered by name. |
| list_report_pagesC | List the pages of a Looker Studio report. |
| screenshot_reportA | Take a PNG of a report page in view mode, to check charts after editing. |
| list_componentsA | List the charts, texts and shapes of a report page with their index, kind and layout (x, y, width, height in px). Indexes go back to front; other component tools take them. |
| describe_componentA | Show every Setup and Style setting of one component with its exact label and current value. Use it to learn the labels update_component and the style options accept. |
| build_report_linkA | Build a Looker Studio Linking API URL that creates a report (blank or copied from a template) connected to BigQuery tables. The user opens it to confirm. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 11 tools
Each tool targets a distinct resource+action: BigQuery querying (run_query, list_datasets, list_tables, describe_table) versus Looker Studio browsing (list_reports, list_report_pages, list_components, describe_component, screenshot_report), plus auth and link building. The parallel list/describe hierarchies are clearly separated by domain and no two tools overlap in purpose.
All names use a consistent snake_case verb_noun pattern (list_reports, describe_component, run_query, build_report_link, check_auth). There are no mixed conventions or vague verbs, making the naming highly predictable.
11 tools is well within the ideal range and each earns its place: reading BigQuery, reading reports/pages/components, auth checks, and link building. Nothing feels redundant or padded.
The surface is read-only yet descriptions reference editing operations that do not exist: describe_component tells you to learn the labels 'update_component' accepts, list_components says 'other component tools take' indexes, and screenshot_report is 'to check charts after editing'. Agents will hit dead ends because the referenced write/edit tools (e.g. update_component, add_component) are absent.