Skip to main content
Glama

looker_export

Exports every row from each datasource behind a Looker Studio report to CSV. For multi-page reports, run it per page URL because only datasources on the opened page are visible.

Instructions

Export every row of each datasource behind a Looker Studio report to CSV.

Only datasources used on the opened page are seen; for multi-page reports call it per page URL.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "report_url": "<report_url>"
    },
    "name": "looker_export"
  }
}

Input Schema

NameRequiredDescriptionDefault
out_dirNo
page_sizeNo
report_urlYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It discloses an important limitation—only datasources on the opened page are seen—but omits prerequisites such as browser/session state, auth requirements, file overwrite behavior for out_dir, and potential export duration or rate limits.

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?

Two sentences, front-loaded with the core action and followed by the key page-scoping limitation. There is no redundant or filler content.

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

Completeness2/5

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

The output schema helps with return values, but the input schema has zero description coverage and there are no annotations. The description covers the core action and one page-scoping constraint, but does not compensate for missing parameter semantics or browser-state prerequisites.

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

Parameters2/5

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

Schema description coverage is 0% for all three parameters. The description indirectly implies a report URL via 'behind a Looker Studio report' and 'per page URL,' but it never explains report_url, out_dir, or page_size semantics, leaving two parameters completely undocumented.

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 states a specific verb and resource: export every row of each datasource behind a Looker Studio report to CSV. It clearly distinguishes this specialized export tool from the generic browser-automation siblings, and the page-scoping sentence further clarifies scope.

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?

It gives concrete usage context: only datasources used on the opened page are visible, and multi-page reports require calling the tool per page URL. It does not explicitly say the browser must already be navigated to the report or mention any alternative tools, but the operational guidance is clear.

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