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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely new behavior: this performs validation and returns a byte estimate with no execution, plus the '@name' parameter convention. It stops short of saying what happens on invalid SQL or whether the estimate is an upper bound.

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, front-loaded with the core capability, no filler. The parameter convention note 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?

An output schema exists, so return values need no explanation, and the annotations carry the safety profile. However, for a 6-parameter tool with zero schema coverage, key semantics (account/location/project_id scoping, maximum_bytes_billed behavior, error behavior on invalid SQL) are left entirely unaddressed.

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 0% — sql, account, location, project_id, and maximum_bytes_billed are all undocumented in both schema and description. The one compensating detail ('Named parameters use @name in SQL') is valuable for the parameters array but leaves five parameters unexplained, so the description does not fill the gap.

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 + resource: 'Validate a single SELECT and estimate bytes without executing it.' The 'without executing it' clause implicitly separates it from the run_query sibling, though it never names that sibling. The 'single SELECT' constraint also usefully narrows scope.

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 'without executing it' phrasing implies this is a pre-flight check before run_query, but the description never states when to use this versus run_query directly, nor any prerequisites. Usage is inferable rather than stated.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered by structured data. The description adds a useful format constraint ('dataset_id must not include the project prefix') but says nothing about behavior on a missing dataset, permission requirements for cross-project access, or how the openWorldHint manifests.

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 zero filler; the return-field summary comes first and the parameter constraint 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?

An output schema exists, so return values need not be described, and the read-only annotations cover the risk profile. However, with two undocumented parameters and no note on behavior when the dataset is absent or inaccessible, an agent still lacks enough to invoke it confidently across accounts and projects.

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 0%, so the description carries the full burden, yet it only clarifies one of three parameters: the dataset_id must omit the project prefix. The 'account' and 'project_id' parameters are left completely unexplained in both schema and description, which is a meaningful gap for a cross-project BigQuery lookup.

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 ('Get') and resource ('dataset') and names the returned fields (location, description, labels), which separates it from siblings like list_datasets and get_table. It does not explicitly contrast itself with those siblings, but the resource and return scope make the intent 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 call this versus list_datasets, get_table, or preview_table, and no prerequisites or error conditions. The only guidance-like content is the dataset_id format constraint, which is a parameter rule rather than a when-to-use signal.

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, idempotentHint, and non-destructive, so the safety profile is covered. The description adds real behavioral context the annotations don't: the polling loop signal (job_complete false → call again), the pagination contract (pass next_page_token unchanged), and type encodings (NUMERIC as decimal strings, bytes as base64).

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?

Three short sentences, front-loaded with the core action, then the polling rule, then the paging/encoding details. No wasted text and each sentence conveys an actionable constraint.

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?

An output schema exists, so return structure needn't be explained; the description still usefully notes how NUMERIC/dates/bytes are represented. Combined with polling and pagination guidance this covers most of what a 6-param job tool needs, with only page_size behavior left unexplained.

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 0%, so the description carries the parameter burden. It explains how account, location, and project_id should be populated (reuse from submission) and that page_token pages forward, but page_size (with its 1–1000 bounds) and job_id are never described, leaving real gaps.

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 pair and resource: 'Poll a query job or read one result page.' This clearly distinguishes the tool from run_query/dry_run_query siblings, which submit rather than poll jobs, and an agent can tell exactly what it does without opening the schema.

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 concrete operating rules: 'If job_complete is false, call again later' and 'Reuse project_id, location and account from submission.' That tells the agent when and how to re-invoke, though it doesn't explicitly name run_query as the prerequisite step that creates the job.

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, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds that multiple metadata facets are returned in one read, but since an output schema exists, that is largely duplicative; nothing on permissions or required access is disclosed.

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 clause with no filler; the key information (what is read) comes first and the usage trigger last. It is terse to the point of being a fragment, but nothing is wasted.

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 rich annotations and a declared output schema, the description covers the what and roughly the when. The gap is scope resolution (which project/account a dataset_id is resolved against) and sibling differentiation, both left to inference for a tool with 4 unresolved parameters.

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 0% across 4 parameters (dataset_id, table_id, account, project_id), so the description must compensate and does not — it mentions no parameter at all. Parameter names are mostly self-explanatory, which keeps this above a 1, but the null-defaulted account/project_id scoping is left entirely unexplained.

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 resource and the exact metadata it returns (nested schema, size, row count, partitioning, clustering), which is far more informative than the bare name get_table. It does not, however, explicitly distinguish itself from siblings like preview_table or get_dataset, so an agent must infer the boundary.

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?

'...before writing SQL' gives a clear implied moment to use the tool. But no alternative is named and no exclusion is stated (e.g., when to use preview_table for sample rows instead), so the routing guidance is only implied.

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 readOnly, openWorld=false, idempotent, non-destructive; the description adds genuinely new behavioral facts: no network calls to Google, no browser launch, and specifically that ADC is not probed. That is exactly the kind of detail an agent needs to know this is a safe, purely local inspection. It stops short of saying what the check actually inspects or reports.

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 negative scope front-loaded and no filler. Every clause carries information an agent cannot get from the schema or annotations.

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?

An output schema exists, so return values need no explanation, and annotations carry the safety profile. However, for a diagnostic tool the description never says what is being examined or how to interpret a pass/fail result, and the undocumented `account` parameter leaves a real 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 `account` parameter has 0% schema description coverage and the description never mentions it — no indication whether it selects which stored credential's configuration to inspect or what happens when it is omitted (the schema shows default null). With zero coverage, the description was the only place this could have been clarified.

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?

"Check local configuration" states a verb and a resource, but the resource is vague — it never says this is BigQuery configuration (only the annotation title does), nor what aspect of configuration is verified. The negative scope ("without contacting Google or opening a browser") is helpful but describes what the tool avoids rather than what it produces, and no sibling tool is referenced for contrast.

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 run this check — before a query, when auth fails, as a preflight — and no comparison to any of the nine sibling tools. The only guidance is an exclusion: "ADC is not probed," which tells an agent not to rely on it for auth diagnostics but does not say what to do instead.

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, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds two real behavioral facts beyond that: results are returned one page at a time (pagination is required to enumerate everything) and omitting project_id falls back to the configured default project.

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 no filler, front-loading the verb and resource before the scoping clause. Nothing could be removed without losing information.

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?

An output schema exists, so return values need no explanation, and annotations cover the safety profile. The remaining gaps are the undocumented account parameter and page_token continuation semantics, which are minor but real for a paginated list 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 0% across 4 parameters, so the description has to carry the burden. It clarifies project_id's null/default behavior and implies page_size/page_token through "one page," but leaves the account parameter and the page_size bounds/limit completely unexplained.

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 ("List one page of datasets") plus the scope (project_id or the default project), which is enough to separate it from list_tables and list_projects. It stops short of naming a sibling or contrasting with get_dataset, so it is clear but not fully differentiated.

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 implies when to use it (enumerating datasets, with a default-project fallback) but gives no explicit when-not guidance and never points to get_dataset for single-dataset details or list_tables for drill-down. Usage must be inferred from the verb and the sibling 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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description's value is in the extra disclosures: the call returns a single page rather than the full set, and first use has an interactive auth side effect that writes a local token. That side-effect warning is genuinely beyond what the annotations say and matters for non-interactive callers. It doesn't cover error modes or what happens if the sign-in is declined.

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, zero filler, with the core action front-loaded before the auth caveat.

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?

The output schema means return values needn't be explained, and the auth caveat covers the biggest surprise. But with three parameters at 0% schema coverage, leaving `account` (multi-account selection) and the page_token continuation flow entirely undescribed leaves the agent guessing on a tool it will likely call first.

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 0%, so the description must carry parameter meaning, and it largely doesn't. "One page" vaguely gestures at page_size/page_token but never explains page_size's 1–1000 bounds or how to continue via page_token, and the `account` parameter is never mentioned at all.

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 ("List one page of accessible projects") and the sibling names (list_datasets, list_tables) make the resource level unambiguous. It doesn't say these are BigQuery projects or that projects are the top-level container for datasets — the annotation title carries that — but an agent can still distinguish it from siblings.

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 explicit when-to-use or when-not guidance relative to siblings, but it does disclose a real prerequisite: first use may trigger an interactive Google sign-in and persist a local token. That is useful context an agent needs before calling, though it is a prerequisite rather than routing guidance.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the useful pagination trait ('one page'), but says nothing about auth, rate 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?

A single efficient sentence with the resource and pagination scope front-loaded. No wasted words, though it underspecifies rather than overexplains.

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?

An output schema exists, so return values need no explanation. But with 5 parameters at 0% schema coverage, the description should do more to demystify account/project_id and pagination behavior for a BigQuery 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 0%, so the description must carry param meaning. It hints at dataset_id and pagination (page_size/page_token) via 'one page... within a dataset,' but leaves account and project_id unexplained, and clarifies nothing about page_size limits or token semantics.

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 (tables and views) scoped to a dataset, with pagination indicated. It can be distinguished from siblings like get_table/preview_table, though it doesn't explicitly name alternatives.

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 prerequisites, and no routing to alternatives such as preview_table or get_table. The only hint is 'one page,' which implies pagination without explaining it.

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, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds one genuinely new trait, "Row order is unspecified", but says nothing about pagination continuation via page_token, truncation, or the page_size ceiling (1000) enforced by 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?

Two short sentences with zero waste; the core operation is front-loaded ahead of the caveat about row order.

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?

An output schema exists, so return values need not be explained, and the read-only nature is covered by annotations. However, for a 6-parameter tool with no schema descriptions, the description leaves too much of the parameter surface unexplained to be fully complete.

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?

Six parameters with 0% schema description coverage, so the description carries the full burden and largely fails: project_id, account, dataset_id and table_id are undocumented, and page_token's continuation semantics are only implied by "bounded page". The one useful hint is that reads are paged, which maps loosely to page_size/page_token.

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?

A specific verb and resource (read a bounded page from a physical table) plus an explicit contrast with the query-based siblings ("without a SQL query job"). An agent can distinguish this from run_query/dry_run_query without opening a schema.

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?

"Without a SQL query job" implies when this is preferred over run_query, but the guidance is only hinted at. There is no explicit when-not or named alternative such as get_table or run_query.

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?

Adds substantial context beyond annotations: the job can incur Google charges, it never exceeds the configured byte ceiling (fails rather than overruns), returns a job reference immediately (async), and resubmission creates new work rather than polling. The annotations only say non-read-only, open-world, non-idempotent, non-destructive; the description gives the cost and ceiling semantics an agent needs.

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?

Four short sentences, front-loaded with the risk (charges) and the key constraint (byte ceiling), followed by the return shape and routing guidance. 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?

An output schema exists, so return values needn't be detailed, yet it still states a job reference comes back immediately. Cost, ceiling, polling, and cross-project semantics are covered; only the account/location parameter meanings are left implicit.

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 0%, so the description carries the burden. It clarifies two parameters well — project_id as the billing/job project that need not match the data's projects, and the byte ceiling behavior tied to maximum_bytes_billed. But sql, account, location, and parameters get no explanation, leaving meaningful gaps.

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 — submit a SELECT job — and its two-phase nature (dry-run first). It differentiates from siblings by name, both the internal dry-run step versus dry_run_query and the polling handoff to get_query_results.

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?

Explicitly routes the agent: use get_query_results to poll and paginate, and 'do not resubmit to poll'. Also implies the dry-run-first workflow that distinguishes it from a plain submit. When/when-not coverage is unusually complete.

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