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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds a meaningful trait beyond that: the tool only builds a URL and the actual report creation happens when the user opens it to confirm, which explains the read-only nature. It still omits auth requirements and error behavior.

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

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

Two tight sentences with the core action and the return artifact front-loaded; every clause carries information and there is no filler.

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

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

With no output schema, the description correctly states the return value (a Linking API URL) and the follow-up step (user opens it to confirm), which an agent needs before calling. It is slightly thin on the relationship between sources and template placeholders, but overall adequate for this three-parameter tool.

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

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

Schema description coverage is only 33%, so the schema does not fully carry the load. The description maps "blank or copied from a template" to template_report_id and "connected to BigQuery tables" to sources, but restates what the schema already says and adds nothing about report_name or how sources entries pair with template aliases.

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

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

Specific verb and resource: builds a Looker Studio Linking API URL that creates a report connected to BigQuery tables. It clearly distinguishes itself from siblings like list_reports, screenshot_report, or run_query, which do not construct a report-creation URL.

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

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

"The user opens it to confirm" gives workflow context that this produces a link rather than performing the creation, which is useful. However, there is no explicit when-to-use versus when-not statement, no mention of prerequisites (auth, config), and no routing to alternatives.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds useful context beyond that: it discloses that two distinct credential surfaces are validated (BigQuery API credentials and the Looker Studio browser session), which is the key thing an agent needs to interpret a failure. It does not describe the result shape, keeping it short of a 5.

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

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

Two sentences, no filler, and the most actionable information (the "use first on auth errors" trigger) is placed at the end as a clear directive. Every sentence earns its place.

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

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

There is no output schema, so the description carries the burden of explaining what the check returns (e.g., which surface passed or failed, or how to interpret a partial failure). It says what is checked but not what the agent will get back, which is a real gap for a diagnostic tool with no structured output.

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

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

The tool takes zero parameters, so per the baseline this dimension starts at 4. There is nothing for the description to clarify beyond what the empty schema already conveys.

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

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

States a specific verb ("Check") and names the two concrete resources it validates: the Google API credentials (BigQuery) and the signed-in Looker Studio browser profile. This clearly separates it from the data-oriented siblings (run_query, list_reports, etc.), though it doesn't name any sibling explicitly.

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

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

"Use first when other tools fail with auth errors" gives an explicit trigger condition that tells the agent exactly when to reach for this tool over retrying a failing sibling. It lacks a when-not clause, but the positive routing rule is unambiguous.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds useful behavioral context beyond that: it promises fidelity of the returned labels/values and ties the tool to a downstream workflow (update_component), which the annotations do not convey.

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

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

Two short sentences with no waste; the primary action is front-loaded and the secondary usage hint follows. Every clause earns its place.

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

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

With no output schema, the description partially compensates by stating what is returned (exact labels and current values), and pagination is covered by the schema's page parameter. It is nearly complete, though it says nothing about how component identity/indexing interacts with pagination across pages.

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

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

Schema description coverage is 100% and every parameter (page, index, report_id) is documented in the schema itself. The description adds no syntax, format, or defaulting detail for these parameters, so the baseline of 3 applies.

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

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

States a concrete verb and resource ('Show every Setup and Style setting of one component') plus scope ('exact label and current value'), which separates it from the sibling list_components. It does not explicitly contrast with siblings like describe_table or list_components, so it stops short of a 5.

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

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

Gives a clear reason to call it: to learn the labels that update_component and the style options accept, i.e. read-before-write reconnaissance. No when-not guidance or explicit alternative routing is offered, so it is clear context without exclusions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. Because no output schema exists, the description's disclosure of what is returned (field list, row count, and view SQL for views) carries real behavioral weight that the structured fields do not provide. It still omits error behavior (e.g. unknown table) and whether the row count is metadata-derived or a scan.

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

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

A single front-loaded sentence that states the resource first and then the returned artifacts, with no redundant or filler text.

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

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

For a simple read-only metadata lookup with no output schema, the description covers the essential return shape (fields, row count, view SQL) and the schema covers all inputs. Only edge-case behavior (missing table, permission failures) is absent, which is a minor gap.

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

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

Schema description coverage is 100%, with each of table_id, dataset_id, and project_id documented in the schema (including the config default for project_id). The description adds no parameter-level detail beyond that, so the baseline 3 applies.

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

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

The description states a specific verb ('Show') and resource (fields of a table or view), plus the extra returns of row count and view SQL, which clearly separates it from siblings like list_tables (enumeration) and run_query (execution). It never explicitly names a sibling, but 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.

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

There is no statement of when to use this tool versus alternatives such as run_query or list_tables, and no prerequisites (e.g. that the dataset/table must already exist, or that this is the inspection step before querying). Usage is only inferable from the tool name and the described output.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful semantics beyond that—index ordering is back-to-front and the indexes are the shared key for other component tools—but says nothing about empty pages, pagination, or failure behavior.

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

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

Two tight sentences with no filler. The payload content and field list come first, and the index-order/interop note is placed last as a supporting detail.

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

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

With no output schema, the description carries the return-value burden and does so by naming the fields returned (index, kind, layout with units in px). It is nearly complete for a simple read tool; only edge-case behavior (empty page, ordering guarantees beyond back-to-front) is left unspecified.

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

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

Schema description coverage is 100%, so both parameters (report_id, page) are already documented in the schema, including the 1-based/default-first-page semantics. The description adds no additional parameter meaning, so the baseline 3 applies.

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

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

The description names a specific verb (List) and resource (charts, texts and shapes of a report page) and enumerates the returned fields (index, kind, layout x/y/width/height). The phrase 'other component tools take them' also sets it apart from describe_component, which consumes rather than produces indexes.

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

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

Usage is implied rather than stated: the mention that other component tools consume these indexes hints at the workflow, but there is no explicit when-to-use/when-not guidance and no sibling is named as an alternative (e.g. vs list_report_pages). Adequate context, but the agent must infer the routing.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered by structured data. The description adds nothing beyond that: no pagination behavior, no result caps, no ordering, and no note about what happens when project_id is omitted (the default is only stated in the schema).

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

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

A single front-loaded sentence with zero filler. It is efficient, though arguably terse to the point of leaving useful context unsaid.

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

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

For a simple read-only list tool with full schema coverage and annotations covering the safety profile, the description is minimally viable. With no output schema, it would help to say what is returned (dataset IDs/names) or whether results are paginated.

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

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

Schema description coverage is 100% and the single project_id parameter is fully documented in the schema, so baseline 3 applies. The description adds no extra meaning about the parameter, such as format expectations or behavior when the default is used.

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

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

Clear verb+resource ('List the BigQuery datasets') with an explicit scope ('of a Google Cloud project'), which is more than a restatement of the name. However, it offers no differentiation from the sibling list_tables, which an agent could easily confuse it with.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives such as list_tables or run_query. Usage is only implied by the verb 'List'.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that: no pagination behavior, no note on what happens with an invalid report_id, no indication of who may read a report. It essentially restates the title.

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

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

One short sentence with zero filler and the key resource front-loaded. It is efficient, though its brevity edges into under-specification rather than tight writing.

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

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

For a simple read-only list operation with a single fully-described parameter, the description covers the essentials. Because there is no output schema, an agent still lacks any hint about the shape or size of the returned page list, and there is no mention of pagination, leaving a modest gap.

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

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

The single parameter is fully documented in the schema itself ('Report id or any URL of the report'), and schema coverage is 100%, so the baseline is 3. The description contributes no additional parameter meaning, such as accepted URL formats or whether IDs are scoped to a workspace.

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

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

The description gives a clear verb+resource ('List the pages of a Looker Studio report'), so it is unambiguous about what it returns. It does not, however, differentiate itself from siblings like list_reports or list_components, which also enumerate report-related entities.

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

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

There is no guidance about when to use this tool versus list_reports, list_components, or describe_component, nor any stated prerequisite (e.g. that a report_id must first be obtained). The only implied usage comes from the required parameter.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful scoping context (signed-in account only) and that the name filter is optional, but says nothing about pagination, result limits, or ordering.

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

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

One sentence, front-loaded with the verb and resource, with the filter qualifier trailing. No filler or redundancy.

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

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

For a simple zero-required-parameter list tool with annotations covering the safety profile and a fully documented schema, this is nearly complete. The only gap is any hint about result size or pagination, which is minor for a listing tool.

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

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

Schema description coverage is 100%, so the single 'query' parameter is already fully documented as a substring match on name. The description's 'optionally filtered by name' adds nothing beyond the schema, which is the baseline-3 case.

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

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

States a specific verb (List) and resource (Looker Studio reports) plus scope (signed-in account) and the optional filter. It does not distinguish itself from siblings like list_report_pages or list_datasets, but the resource is named concretely enough that an agent can identify it.

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

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

There is no when-to-use guidance, no mention of alternatives (e.g., list_report_pages for page-level data), and no prerequisites. The agent must infer from the name alone that this is the entry-point listing tool.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered by structured data. The description adds nothing beyond that — no note on whether results are paginated, cached, or scoped by permissions, which for a BigQuery metadata call would be genuine added value.

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

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

A single sentence with zero filler, front-loaded with the verb and the scoped resource. Nothing to trim and nothing essential buried.

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

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

For a trivial read-only listing tool with two fully documented parameters and annotations covering safety, the description is nearly sufficient. The only minor gap is that no output schema exists, so the return shape (table names, view flags, row counts) is unstated.

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

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

Schema description coverage is 100%: dataset_id carries a concrete example and project_id documents its config-default behavior. The description adds no parameter meaning beyond the schema, so the baseline 3 applies.

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

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

Clear verb+resource: 'List the tables and views' names both the operation and the object, and the scope 'of a BigQuery dataset' separates it from list_datasets (project-level) and describe_table (single-table detail). It stops short of explicitly naming those siblings, so it is clear but not fully disambiguating on its own.

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

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

The description gives no when-to-use guidance, no prerequisites, and no mention of alternatives such as list_datasets or describe_table. Usage is only implied by the listing verb, leaving the agent to infer the call context.

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

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 genuinely new behavioral facts: writes are refused (an error condition the agent must anticipate), the result arrives as a table, and dry_run provides a cost-estimation path before execution. It stops short of mentioning authentication requirements, row-limit truncation behavior, or quota/cost limits.

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

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

Two sentences, both front-loaded with the operative clause ('Run one SELECT…', 'Use dry_run…'), and no filler. The write-refusal safety note is short and appropriately placed second.

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

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

With no output schema, the description correctly covers the return shape ('rows as a table'), and read-only semantics are covered jointly by annotations and the write-refusal sentence. The remaining hole is max_rows (what happens past the 10000 cap, truncation vs error) and any auth/project-scoping prerequisites.

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

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

Schema coverage is 75%, above the low-coverage threshold, so the schema carries most parameter meaning. The description's dry_run sentence largely restates the schema's own 'Only validate and estimate the bytes scanned' and adds nothing about max_rows, the one undocumented parameter (a real gap for controlling result size).

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

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

States a specific verb and resource ('Run one SELECT in GoogleSQL'), the cardinality constraint ('one'), and the return shape ('return the rows as a table'). Nothing in the sibling set (list_*/describe_*/screenshot_*/build_report_link) can be confused with executing an arbitrary query, so the boundary is clear without opening schemas.

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

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

It gives a workflow hint ('Use dry_run to check a query and how many bytes it scans before running it') but never says when to reach for run_query versus siblings like list_tables or describe_table, nor any exclusions. Usage is only implied by the tool's function.

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

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

Annotations already declare it a safe read operation (readOnlyHint=true, destructiveHint=false). The description adds real value beyond that by specifying the render mode ('view mode') and the output artifact ('PNG'), which matters since no output schema exists. It omits any auth or timing context, keeping it just short of 5.

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

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

A single front-loaded sentence with no filler; the core action and its scope arrive first.

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

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

For a simple two-parameter read tool with no output schema, the description conveys the return format (PNG) and the render mode, which is the essential missing piece. Nothing critical for invoking it correctly is absent.

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

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

Schema description coverage is 100%; both page and report_id are documented in the schema, including the 1-based default and the URL-acceptance behavior. The description adds no parameter detail beyond what the schema already states, so the baseline 3 applies.

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

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

States a specific verb and resource: capture a PNG of a report page. The 'in view mode' qualifier narrows the action meaningfully. No sibling tool does anything similar (run_query, list_reports, build_report_link), so no differentiation is strictly needed.

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

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

'to check charts after editing' implies a usage context, but it is a purpose rationale rather than explicit when-to-use guidance. There is no mention of when not to use it or which alternative to pick for other verification needs.

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