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

Annotations already establish that this is a read-only, idempotent, non-destructive, open-world operation. The description adds the useful "visible to the user" scope, but it does not describe pagination behavior, auth requirements, 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.

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

The description is a single front-loaded sentence with no wasted words. It states the core resource and scope immediately.

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 annotations cover the safety profile. However, the description leaves pagination semantics and sibling-tool selection implicit, which are relevant gaps for this 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?

The schema has two parameters (page_size and page_token) with 0% description coverage, and the description says nothing about pagination or how to use these parameters. With low schema coverage, the description should compensate but does not.

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 uses a specific verb ("List") and resource ("GA4 accounts and their properties") and states the visibility scope. It is clear enough to distinguish from analytics_run_report, but it does not explicitly differentiate itself from analytics_list_properties.

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 listing purpose implies when the tool should be used, but there is no explicit guidance on when to choose it over analytics_list_properties or analytics_run_report. No exclusions or alternative conditions are provided.

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?

The annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds the account identifier format but does not mention pagination behavior, rate limits, or other operational details.

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?

The description is a single front-loaded sentence with no wasted text. It states the core action and the key constraint efficiently.

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 an output schema, the description is sufficient for the core read-only listing action. However, it omits pagination semantics for page_size and page_token, which are relevant for a list operation.

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 compensate, but it only explains the account parameter format. The page_size and page_token parameters are left undocumented in both schema and description.

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 clearly states a specific verb and resource: listing GA4 properties under an account. It is distinguishable from analytics_run_report, though it does not explicitly compare itself with analytics_list_account_summaries.

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 the required context that the tool operates on an account, including accepted account identifier forms. However, it does not say when to use this versus sibling analytics tools or when not to use 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 read-only, open-world, idempotent, and non-destructive behavior. The description adds useful runtime context beyond annotations: it states the return shape ('headers and rows'), a maximum row count of 1000 per call, and that callers should page with offset. It does not cover authentication needs or rate limits, but the added pagination and result-size behavior is meaningful.

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?

The description is front-loaded with the core action and then gives compact, scannable parameter guidance. It contains no filler and every sentence contributes useful 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?

For an eight-parameter GA4 reporting tool with an output schema and rich annotations, the description covers the required parameters, examples, limits, and pagination behavior. It is almost complete for invocation, though it leaves the optional sorting and pagination parameters to the schema.

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?

With 0% schema description coverage across eight parameters, the description supplies important semantics for property_id format, metrics examples and max count, dimensions examples and max count, and date_ranges format and max count. However, it does not explain limit, offset, descending, or order_by_metric, so it only partially compensates for the missing schema descriptions.

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 and resource: 'Run a GA4 Data API report.' This clearly identifies the operation and platform, though it does not explicitly differentiate itself from nearby analytics tools such as analytics_list_properties.

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 that the tool is for running GA4 reports, but it does not state when to use this tool versus alternatives like analytics_list_properties or youtube_analytics_query_report. There are no exclusions, prerequisites, or 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, idempotentHint, destructiveHint=false and openWorldHint, so safety and idempotency are covered. The description adds nothing beyond that - no mention of error behavior for missing/unknown ids, cross-calendar access, or recurrence handling.

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 no wasted words and the core operation front-loaded. It is efficient, though the brevity reflects under-specification rather than disciplined editing.

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, but the undocumented calendar_id parameter and the absence of any disambiguation from listing tools leave real gaps for a two-parameter lookup 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 the parameter burden, yet it never explains event_id format or the calendar_id parameter and its 'primary' default. An agent reading only the description would not know a second calendar-scoping parameter exists.

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 and resource (get one event), which is clear enough. However, it offers no differentiation from siblings like calendar_list_events or calendar_query_freebusy, and 'by id' is the only distinguishing scope detail.

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 indication of when to use this tool versus calendar_list_events or calendar_query_freebusy. The agent must infer that this is the single-item fetch, and no prerequisites or exclusions are 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 readOnly, idempotent, non-destructive, openWorld, so the safety profile is fully covered. The description adds the useful content detail that 'primary' is included, but says nothing about pagination (page_token), result caps, or ordering—notable for a list tool that defaults to 50 items.

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 waste. It is appropriately terse, though that terseness comes at the cost of the pagination information an agent needs.

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-value documentation is not required, and annotations cover the safety profile. However, an agent still lacks any indication of how to page through results or cap them, which is material for a list endpoint with a default page size.

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% for both parameters, so the description carries the full burden—yet it explains neither page_token (continuation semantics) nor max_results (default 50, upper bound). With two undocumented params, the description fails to compensate for the coverage 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: lists calendars from the user's calendar list, and explicitly notes 'primary' is included. Clearly distinct from siblings like calendar_list_events and calendar_get_event, though it never names or contrasts them directly.

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. The agent must infer that this is the discovery step to obtain calendar IDs before calling calendar_list_events or calendar_query_freebusy.

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 establish read-only, idempotent, non-destructive behavior. The description usefully adds that timestamps use RFC 3339 with an offset and that single_events expands recurring events and orders by start time, though it omits pagination 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?

Three short sentences, front-loaded with the core purpose, then time formatting and one important behavioral flag. There is no wasted 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?

The description covers the core listing operation, timestamp format, and single_events behavior, and an output schema exists for return values. However, with seven parameters and no schema descriptions, it should document more parameter meanings, especially query, page_token, calendar_id, and max_results.

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 explain parameters. It clarifies time_min/time_max formatting and single_events semantics, but leaves query, page_token, calendar_id, and max_results undocumented.

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 calendar events within a time range. It is clear enough to distinguish from calendar_get_event and calendar_list_calendars, though it does not explicitly name sibling 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?

The phrase 'List events in a time range' implies the main use case, but the description gives no explicit guidance on when to use this instead of calendar_get_event, calendar_query_freebusy, or other calendar tools.

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, openWorldHint, and destructiveHint=false, so the safety profile is fully covered structurally. The description adds the default-to-primary behavior and the RFC 3339 time format, but says nothing about response shape, per-calendar error handling for inaccessible calendars, or 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?

One sentence, front-loaded with the action and resource, no filler. It is arguably over-compressed for four undocumented parameters, 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?

An output schema exists, so return values need not be explained. However, with 0% schema coverage on four parameters, the description leaves time_zone entirely undefined and does not clarify multi-calendar behavior, which is a real gap for an agent building the call.

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 compensate and only partly does: it pins down the RFC 3339 format for time_min/time_max and the primary default for calendar_ids. The time_zone parameter is never mentioned and calendar_ids' array semantics (multiple calendars in one call) are only implied.

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 ('Return busy intervals'), the resource (calendars), and the scoping inputs (two RFC 3339 times, default primary). An agent can tell this is a free/busy read rather than an event listing, though no sibling is named 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?

No guidance on when to call this versus calendar_list_events or calendar_get_event, which are the obvious adjacent tools. The only contextual hint is the '(default: primary)' parenthetical, which is scope, not usage 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?

The annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds useful behavior the annotations do not: the text is truncated at a max_chars cap, the ceiling is 100000, and a truncated flag reports whether the cap applied.

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. The core action is front-loaded, and the truncation caveat follows without wasted words.

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 do not need to be explained, and the truncation semantics cover the main ambiguity. Only document_id's expected format is left implicit, which is minor for an obvious identifier.

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 must carry the load. It explains the max_chars cap and ceiling, though the 20000 default is already in the schema. It says nothing about document_id, which is the only required parameter.

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: read a Google Doc as plain text, plus a structure summary. That is more concrete than the name alone. It does not, however, say how it differs from nearby tools such as drive_read_file_text or drive_get_file, which also read file content.

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 guidance on when to choose this tool over drive_read_file_text or drive_get_file. It states no prerequisites or exclusions, so the agent must use the name and sibling list to infer usage.

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, idempotent, open-world and non-destructive, so the safety bar is covered. The description adds real behavior beyond that: results arrive newest first, the filter uses Drive Activity syntax, and consolidate=true groups related actions. It omits pagination behavior for page_token/max_results, which keeps it from 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?

Three short blocks, front-loaded with purpose and scope, then filter syntax, then the consolidate flag. The inline example is long but earns its place by demonstrating the syntax an agent cannot infer from a bare string parameter.

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. However, for a paged query endpoint the absence of any statement about pagination, ordering across pages, or result limits leaves a meaningful operational gap for an agent that must call it repeatedly.

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. It does well for filter (syntax plus a concrete example), item_id, folder_id and consolidate, but page_token and max_results (default 25) get no guidance at all, leaving a pagination gap in a query tool.

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 ('Query Drive activity') plus the exact three scoping modes keyed to parameter names (item_id, folder_id, neither). An agent can distinguish this from drive_search_files or drive_get_file immediately, since this returns activity history rather than file content.

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 tells the agent which parameter selects which scope, which is the primary selection decision for this tool. It does not name alternative sibling tools or state when-not to use activity history versus a file listing, so it falls short of a 5.

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 fully covered structurally. The description's only added behavioral nuance is that the target may be a folder as well as a file; it says nothing about permissions, shared-drive visibility, or error conditions for a missing ID.

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 scope constraint ('one file or folder') arrives immediately and every word carries weight.

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 fields need not be described, and rich annotations cover the safety profile. Still, for a lookup tool the description leaves gaps around ID sourcing and permission/error behavior that would help an agent invoke it confidently.

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% for the single file_id parameter, so the schema adds no meaning of its own. The description partially compensates by indicating that the ID may reference a folder as well as a file, which is real information not in the schema, but it gives no format or sourcing guidance for the ID.

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 uses a specific verb (get) and resource (metadata for one file or folder), scoping it to a single known item. That implicitly separates it from drive_search_files (discovery) and drive_read_file_text (content), though neither sibling is named 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?

There is no explicit when-to-use guidance, no prerequisites, and no named alternative such as drive_read_file_text for file contents. The agent must infer from the verb that this is for lookups by a known file_id rather than searching or reading content.

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 carry the safety profile (readOnly, idempotent, non-destructive), so the description earns credit for adding genuinely new behavior: Sheets come back as first-sheet CSV, Slides get flattened to text, output is truncated at max_chars, and binary files are rejected. Truncation signaling (whether the output marks a cut-off) is not stated.

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, zero filler, with the supported formats and the cap stated up front. Every clause conveys information an agent needs.

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 two-parameter read tool with an output schema and full annotations, this is close to complete: types, conversion format, cap, and refusal of binaries are all covered. Only the file_id provenance and truncation behavior are 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 0%, so the description must carry the load. It does explain max_chars as a cap on output length, but not its default, units, or truncation semantics, and file_id is left entirely to inference (presumably a Drive file ID from drive_search_files). Partial compensation only.

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 (read) and resource (text of a file) and enumerates the supported file types, so the agent knows exactly what comes back. It does not explicitly differentiate itself from nearby siblings like docs_get_document or sheets_read_range, which is the only thing keeping this from 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?

Usage is implied (call it when you want the text content of a file), but there is no explicit when-to-use/when-not guidance and no mention of when to prefer docs_get_document, sheets_read_range, or slides_get_presentation instead. The 'binary files are refused' line hints at a boundary but is a limitation, not 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 readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description usefully adds that trashed files are excluded by default and that raw `query` is unvalidated Drive syntax while structured filters are safer, but it says nothing about ordering, result caps, or pagination 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 compact sentences, front-loaded with the core action, and each clause adds information about filtering or exclusion defaults. No filler, though the parenthesis example slightly interrupts the flow of the filter guidance.

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. However, for an 8-parameter search tool with zero schema descriptions, the omission of pagination (page_token/max_results) and ordering (order_by) guidance is a real gap an agent would hit on multi-page result sets.

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 the load; it explains intent for query, name_contains, mime_type, folder_id, and the trashed default. It leaves order_by, page_token, and max_results entirely unexplained in both schema and description, and gives no format detail for mime_type or folder ID values.

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 ("Search the user's Drive"), which clearly separates it from retrieval siblings like drive_get_file and drive_read_file_text. It does not explicitly name those siblings or state the boundary, so it falls just 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?

"query is optional raw Drive search syntax... name_contains, mime_type and folder_id are safe structured filters" implicitly steers the agent toward structured filters over raw query strings. There is no explicit when-not guidance, no mention of fetching a known file ID via a sibling, and no pagination guidance across pages.

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 fully covered without the description. The description contributes only the enumeration of returned fields, which is mild added value; no mention of auth scope, error behavior, or what happens with an unknown form_id.

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 listing exactly the returned fields with zero filler. Nothing to trim.

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 one-parameter read with an output schema and complete annotations, the description covers what the tool returns and needs no return-value explanation. The only real omission is provenance/format for form_id.

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?

There is one parameter, form_id, with 0% schema description coverage and the description never mentions it. No hint about format (form ID vs URL vs slug) or where the agent obtains one, so the description fails to compensate for the schema 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?

States a specific verb (get) and resource (a form) plus the exact fields surfaced: title, description, publish state, question summary. It clearly reads as metadata retrieval rather than response retrieval, though it doesn't name the sibling tools (forms_get_response, forms_list_responses) that an agent might 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 or when-not-to-use guidance. Nothing tells the agent to pick this over forms_get_response or forms_list_responses, so the choice has to be inferred from the field list alone.

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?

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds only the retrieval scope ('one form response by id') and does not disclose authentication needs, rate limits, missing-response behavior, or return structure, which is acceptable but thin given the annotations.

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?

The single sentence is front-loaded and wastes no words. It is efficient, though its brevity contributes to the under-specification noted elsewhere rather than being purely a strength.

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 annotations cover safety traits. However, with 0% schema description coverage on two required parameters, the description should do more to clarify the identifiers and basic retrieval behavior for an agent to invoke it confidently.

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 schema does not explain form_id or response_id. The description says 'by id' but does not clarify that two separate identifiers are required or how they relate, leaving the parameter semantics largely undocumented.

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 specific verb and resource: retrieving a single form response by id. This clearly distinguishes it from the sibling forms_list_responses, though it does not explicitly name that sibling or contrast the two beyond the singular 'one'.

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 implies usage only through 'by id' and does not state when to choose this over forms_list_responses or what prerequisites, permissions, or error cases apply. No explicit when-to-use or when-not-to-use guidance is provided.

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, idempotent, non-destructive, and openWorld, so the description need not restate safety. It adds nothing beyond those hints — no mention of pagination behavior, result ordering, or the fact that responses are scoped per form and may be large.

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 the core action front-loaded and the one parameter note appended. Nothing is wasteful, though the extreme brevity is under-specification rather than efficient communication.

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 shape needn't be described, and annotations cover safety. However, for a paginated list endpoint with a page_token parameter, omitting any pagination/continuation guidance and leaving form_id/page_size undocumented leaves a real gap for correct invocation.

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 compensate; it only documents submitted_after as an RFC 3339 timestamp. The required form_id, page_size (default 25), and especially page_token are left wholly unexplained, so an agent cannot tell how to paginate from the description.

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 the specific verb and resource ('List form responses') and is clearly distinguishable from forms_get_response, which fetches a single response. It does not explicitly name that sibling, but the list-vs-get distinction 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?

No guidance on when to use this versus forms_get_response, or when a caller should switch to fetching individual responses. No mention of preconditions such as needing the form to exist or having access to 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?

The annotations already declare readOnly, idempotent, non-destructive, and open-world, so the safety profile is covered. The description adds genuinely non-obvious behavior: the body is size-capped and attachment contents are not downloaded, which directly prevents an agent from assuming it has full message or attachment data.

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 what is returned and followed by the single most important limitation. Nothing is repeated from the schema or annotations and 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 an output schema present and annotations covering safety, the description only needs to fill behavioral gaps, which it largely does via the body cap and attachment caveat. Minor gaps remain: no mention of what happens for HTML-only messages or on an invalid message_id.

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 the parameter burden. 'Plain-text body (size-capped)' hints that max_body_chars truncates the body, but the parameter is never named, no units or truncation-indicator behavior is described, and message_id is left entirely to the schema.

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 uses a specific verb and resource ('Get one message') and enumerates exactly what is returned: headers, plain-text body, and attachment metadata. The scope word 'one' implicitly separates it from gmail_get_thread and gmail_search_messages, but no sibling is named 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?

Usage is only implied: the tool is for fetching a single message, presumably when you already have a message_id. There is no statement of when to prefer this over gmail_get_thread (full conversation) or gmail_search_messages (unknown id), and no prerequisites or exclusions are given.

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), so the bar is lower, yet the description still discloses genuinely non-obvious behavior: bodies are capped per message AND by a shared thread-wide budget, after which later bodies come back empty and flagged truncated. That is exactly the kind of silent-degradation detail an agent needs. It stops short of describing attachment handling or pagination/auth requirements.

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, zero filler: the first states what is returned, the second front-loads the truncation caveat. Nothing is repeated 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-value documentation is not required, and the description covers the one behavioral trap (body budget exhaustion). Minor gaps remain around whether non-body metadata such as attachments or labels is included, but nothing essential to a correct call is missing.

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 the load and it does for max_body_chars: it explains the per-message cap and the shared thread-wide total, which is more than the schema's bare integer type and default. thread_id is left entirely undefined, though its meaning is largely self-evident.

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 — 'Get every message in a thread' — plus the payload shape (headers and plain-text bodies). An agent can distinguish it from gmail_get_message by the word 'thread', but the description never names that sibling, so differentiation is inferred rather than stated.

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-to-use statement, and no alternative tool is named. Usage is only implied by the scope word 'thread' (versus per-message retrieval) and by the truncation note, which hints at the cost tradeoff of large threads.

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, idempotent, openWorld and non-destructive, so safety is covered. The description adds only modestly beyond that — the fact that both system and user labels are returned and that IDs are included — without covering volume, pagination, 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 front-loaded sentence with zero filler; every clause (system vs user labels, IDs) carries 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?

For a zero-parameter read tool with an output schema, the description covers what the tool returns at a high level, so return-value detail is rightly left to the schema. It stops short of noting anything about result size or ordering, 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?

With zero parameters there is nothing to disambiguate, which is the baseline-4 case. The description's note that results carry IDs is the only parameter-adjacent information an agent needs, since no inputs exist.

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 Gmail labels') plus scope ('system and user labels') and what is returned ('their ids'). No sibling tool competes for label retrieval, so explicit differentiation isn't needed, though it isn't provided either.

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 only implied: an agent infers this is the way to discover label IDs before searching or labeling messages. There is no explicit when-to-use clause, prerequisites, or mention of alternatives (of which there are none in the sibling set).

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, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: results are id-only with a fixed header set, header/snippet inclusion is controlled by include_headers, and bodies are out of scope. It omits pagination behavior implied by page_token, which keeps it below 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 short sentences with no filler; the search-syntax hint and the sibling pointer are front-loaded and each sentence carries distinct 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?

Output schema exists, so return values need not be explained, and the core search/read behavior is clear. However, with five undocumented parameters, the missing note on pagination and excluding or including spam/trash leaves an agent likely to misuse max_results and page_token.

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 only partly does: it illustrates the query syntax and explains include_headers. page_token, max_results, and include_spam_trash are never mentioned, leaving half the surface undocumented.

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 ('Search Gmail') plus the exact query dialect and an example. It also distinguishes itself from gmail_get_message by noting that only ids and headers come back and that bodies require the other tool.

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 to gmail_get_message when message bodies are needed, which is the main fork in this workflow. It doesn't address gmail_get_thread or say when a broad listing versus a targeted query is preferred, so it stops short of exhaustive when/when-not 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, idempotentHint, destructiveHint=false, and openWorldHint, covering the safety profile. The description adds no behavioral context of its own — no mention of required People API scopes, what empty results look like, or that 'people/me' resolves to the authenticated user rather than a stored contact.

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 the addressing format immediately following the purpose. Nothing is wasted and nothing essential is 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 one-parameter, fully annotated read tool with an output schema, the description covers purpose, identifier format, and the 'me' alias. The remaining gap is routing guidance against the other people_* tools, which matters given six siblings in that family.

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 whole burden for the single parameter — and it does: it gives the literal format ('people/c123') and the sentinel value 'people/me' that also serves as the default. It just doesn't explain what happens when the name is malformed or unauthorized.

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 ('Get one contact') plus the addressing scheme ('by resource name'), which cleanly separates it from list/search siblings like people_search_contacts and people_list_connections. It never names those siblings explicitly, 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?

The description tells the agent how to call it but not when to prefer it over people_search_contacts, people_list_connections, or people_search_other_contacts. There are no exclusions, prerequisites, or decision conditions — selection must be inferred from the names alone.

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 fully covered. The description adds no behavioral context of its own—nothing about pagination, result ordering defaults (sort_order defaults to LAST_MODIFIED_DESCENDING), or how saved contacts differ from other contacts.

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. It is efficiently written, though its brevity contributes to the gaps scored elsewhere.

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 described, but for a paginated list tool with three undocumented parameters and several closely related sibling tools, the description is too thin to guide correct selection or invocation.

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 neither the schema nor the description explains page_token, sort_order, or max_results semantics. The description lists no parameters at all, leaving all three effectively undocumented.

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?

Names a specific verb and resource ('List... saved contacts'), so the agent knows it enumerates the user's connections. It does not distinguish itself from close siblings such as people_search_contacts or people_list_other_contacts, so an agent cannot tell from the description which to pick.

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 rather than people_search_contacts, people_list_other_contacts, or people_get_person, and no prerequisites or pagination guidance. Usage is only implied by the name.

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, idempotent, openWorld and non-destructive, so safety is covered. The description adds useful domain context about what 'Other contacts' actually are, but says nothing about pagination behavior or result ordering, which matter for a list call.

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 definition trailing as justification. No wasted words, though the colon construction is slightly compressed.

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 shape need not be explained, but for a paginated list tool the description omits everything about paging and limits. Given 0% schema coverage on both parameters, this leaves an agent without enough to call it correctly beyond the defaults.

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% for two parameters (page_token, max_results), and the description mentions neither pagination nor a result limit. The description does not compensate for the schema gap 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 Other contacts') and explains what the resource is: addresses Gmail saved automatically from conversations. That distinguishes it from generic contact listing, though it does not explicitly contrast with people_search_other_contacts or people_list_connections.

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 guidance on when to use this versus people_search_other_contacts or people_list_connections. An agent must infer that this is an unfiltered enumeration of auto-saved addresses, but the description never says so.

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, openWorldHint and destructiveHint=false, so safety is covered. The description adds the valuable 'prefix match' behavior, which the schema does not convey, but says nothing about empty queries, result ordering, or how max_results affects the response.

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 tight sentence with the core scope and match semantics front-loaded, no filler. It is arguably a bit too terse given the undocumented max_results parameter, but structurally clean.

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. Still missing for a search tool: what max_results limits, whether empty results return an empty list, and whether results are ranked by relevance or prefix strength.

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 compensate. It usefully clarifies that the query matches name, email, phone, or organization and that matching is prefix-based, but leaves max_results (including its default of 10) unexplained, so half the parameters remain undefined.

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 ('Search the user's contacts') and names the searchable fields plus the match semantics (prefix match). It implicitly separates itself from people_search_other_contacts by scoping to 'the user's contacts', but does not name that 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?

No guidance on when to use this versus people_list_connections, people_get_person, or people_search_other_contacts, and no note on exclusions or prerequisites. Usage is only implied by the verb 'Search'.

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, idempotent, non-destructive, openWorld, so the safety profile is covered. The description adds useful context that results come from an auto-populated Gmail-derived pool, but says nothing about result ordering, truncation, or what happens when max_results is exceeded.

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 dense sentence that front-loads the action and the resource and uses the parenthetical efficiently for disambiguation. 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?

An output schema exists, so return-value explanation is not required. For a two-parameter read-only search, the description covers the essential who/what; only max_results semantics and sibling routing are missing.

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 compensate. It does clarify that the query string may match name, email, or phone, which is real added meaning; however, max_results is left completely unexplained (no default or cap mentioned).

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 (Search) and a precisely scoped resource ('Other contacts'), and parenthetically defines that scope as auto-saved Gmail correspondents, which distinguishes it from people_search_contacts and people_list_other_contacts. It stops short of naming those siblings 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?

The parenthetical implies when this tool applies (you want correspondents auto-saved from Gmail rather than explicit contacts), but there is no explicit 'use X instead' routing to people_search_contacts or people_list_other_contacts, and no exclusion criteria.

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/openWorldHint/idempotentHint and non-destructive behavior, but the description adds the non-obvious part: this starts an interactive, external-facing session whose completion the agent must poll for. It omits session expiry and whether repeated calls spawn duplicate sessions, which are the remaining behavioral unknowns.

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 action and immediately followed by the required next step. No filler or restatement of the name.

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?

Output schema covers return values and the description covers the human-in-the-loop flow, so an agent can drive the tool end to end. The only gap is the unspecified max_item_count and any session lifetime constraint.

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% and the single parameter max_item_count is never mentioned in the description, so nothing explains what the limit means or what happens if it is omitted. With no parameters the baseline would be 4, but here the one undocumented parameter is left entirely to inference.

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 ('Start a Google Photos Picker session') plus the outcome ('so the user can choose existing photos'). It also names the paired sibling photos_get_picker_session, so an agent can place this tool in a workflow without ambiguity.

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 operational sequence: hand picker_uri to the user, then poll photos_get_picker_session until media_items_set is true. It stops short of saying when a picker is preferable to the album/media-listing siblings, so it is clear context rather than full when/when-not 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 cover safety (readOnly, idempotent, non-destructive), so credit goes to what it adds: the semantics of media_items_set flipping true only after the user finishes picking, plus a rate-governing instruction to honor poll_interval. That is real behavioral context an agent could not get from the structured fields, though failure/expiry states remain undisclosed.

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 action and followed by the completion signal and polling constraint. No filler, though the line-broken phrasing reads slightly like fragments rather than prose.

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 polling contract is covered. What is missing is the linkage to the sibling tool that creates the session, leaving the agent to infer where session_id and poll_interval originate.

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% for the single session_id parameter, so the description would ideally say where that ID comes from. It does not, and instead references poll_interval, which is not present in this tool's schema and must be carried over from the create call — mildly confusing but not harmful.

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+resource ('Check a Picker session') and adds the completion signal (media_items_set) that defines what a check yields. It is distinguishable from photos_list_picked_media_items, but it never names photos_create_picker_session, which is the tool that produces the session_id being checked.

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?

Implies a polling workflow by instructing to respect poll_interval between checks, which tells the agent this is a repeated-call tool rather than a one-shot lookup. However, there is no explicit guidance on when to stop polling, what to do on failure, or why one would choose this over the sibling list/create tools.

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 read-only, idempotent, non-destructive, and open-world behavior. The description adds a crucial API restriction (only albums created by this app are visible since 2025-03-31), which is valuable context beyond annotations. Pagination behavior is not described, but that is a minor gap given annotations.

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, front-loaded with the main action and then the critical restriction. Every sentence earns its place with no waste.

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 tool is simple, has an output schema (so return values need not be explained), and annotations cover the safety profile. The description covers purpose and scope well. The only gap is pagination behavior, but the parameter names are self-explanatory.

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% and the description does not mention either parameter (page_size, page_token). For a tool with two pagination parameters, the description should explain their meaning or usage, but it adds no information beyond the schema names.

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 and resource: 'List albums created by this app.' It also clarifies scope by excluding albums from the Photos app or other apps, which distinguishes it from a general album list. No explicit sibling differentiation is needed here, but the scope is clear.

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 tells the agent when the tool applies (albums created by this app) and implicitly when not to use it (albums from other apps are not visible). There is no alternative tool listed for album listing, so this is sufficient 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 readOnly, idempotent, non-destructive, open-world, so the safety profile is covered. The description adds genuinely non-obvious behavior: baseUrl values expire after about 60 minutes, which tells the agent results are time-limited and must be consumed promptly. It stops short of describing pagination behavior or result 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?

Two tight sentences, no filler, with the core listing scope front-loaded and the expiry caveat placed where it is read before acting. Nothing is redundant with the title or schema.

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-value explanation is not required, and the expiration note is a real asset. However, with zero schema prose and no pagination semantics for page_size/page_token, an agent cannot reliably page through a large result set — a meaningful gap for a 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%, so all three parameters rest on the description. album_id is partially explained ('one app-created album'), but page_size (default 25) and page_token receive no explanation at all — no max page size, no pagination loop guidance — leaving the primary iteration mechanism opaque.

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 media items') plus a meaningful scope restriction ('uploaded by this app'), which distinguishes it from the sibling that lists picked media. It does not explicitly name photos_list_picked_media_items or photos_list_app_albums, 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?

'optionally only those in one app-created album' implies when to pass album_id, giving some conditional guidance. But there is no statement of when to prefer this over photos_list_picked_media_items, nor any guidance on iterating pages with page_token.

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 readOnly, idempotent, and openWorld, so the bar is lower. The description nonetheless adds real behavioral context: the returned baseUrl requires the same OAuth token and expires after roughly 60 minutes, which is a non-obvious operational constraint.

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, front-loaded with the core action, and no wasted words. The second sentence is slightly cryptic but earns its place by carrying the auth and expiry warning.

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-value shape needn't be explained. Still, with 3 entirely undocumented parameters, no pagination guidance, and no explicit prerequisite to create a picker session, the definition leaves gaps an agent would need to close.

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% across 3 parameters. The description alludes to a session (implying session_id) but says nothing about page_size or page_token semantics, defaults, or pagination behavior, so the agent must infer pagination from the schema alone.

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 the items the user picked in a Picker session.' That distinguishes it reasonably from photos_list_app_media_items and photos_list_app_albums by scope, though it never explicitly contrasts with those 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?

Usage is implied by the 'Picker session' framing and the 60-minute expiry note, which hints at a time-bound workflow. However, it never explicitly says to call photos_create_picker_session first or when to prefer this over the app-media listing siblings.

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, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds genuinely new context with Google's hard quota of 2,000 inspections per property per day, which is decision-relevant for an agent planning calls. It stops short of saying what happens on quota exhaustion or how errors surface.

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 earning their place: the core action and scope comes first, the operational limit second. No redundancy or restating of the title.

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 annotations cover safety. However, for an inspection tool the property-identifier format and the role of language_code are exactly what an agent gets wrong, and neither is addressed.

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 should carry the parameter burden. 'One URL inside a property' partially explains the url/site_url relationship, but the third parameter (language_code, default en-US) is never mentioned, and nothing clarifies whether site_url must be a URL-prefix or sc-domain property format.

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 ('inspect') and resource ('Google's index status for one URL inside a property'), which clearly separates it from the analytics-oriented sibling searchconsole_query_search_analytics. It does not name any sibling explicitly, so the differentiation is implied rather than spelled out.

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 never says when to use this tool versus searchconsole_query_search_analytics or searchconsole_list_sites, nor does it state prerequisites such as needing a verified property. The only usage-adjacent information is the implicit 'inside a property' scoping and the quota limit, which is a constraint rather than 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 readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description contributes the fact that permission level is returned, which is real context beyond the annotations. It says nothing about whether results are paginated, ordered, or exhaustive for large accounts.

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 front-loaded sentence with no filler, covering scope and what the result carries. It is arguably a touch thin rather than padded — the risk here is under-specification, not verbosity.

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 with zero parameters there is little else to specify. The only missing piece an agent might want is whether listing is paginated or returns the full set of properties.

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 there is no parameter semantics to explain and the baseline is 4. The 'with permission level' phrase usefully pre-signals a field in the response rather than leaving the agent guessing.

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 Search Console properties the user can access.' It adds a useful detail ('with permission level') that tells the agent what comes back. It doesn't explicitly name how it relates to the two sibling searchconsole tools (query_search_analytics, inspect_url), but the resource is distinct enough that confusion is unlikely.

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 only implied — an agent can infer this is the discovery call to run before inspecting URLs or querying analytics, but the description never says so or names an alternative. No prerequisites or exclusions are stated, which for a zero-param discovery call is a modest gap.

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. The description adds real operational context beyond that: the hard 1000-row cap per call and that paging is done via start_row, plus that dates are Pacific-time and inclusive. It does not mention quota/rate limits or permission prerequisites on the property, which keeps 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?

The purpose sentence is front-loaded, then the remaining lines are a dense per-field cheat sheet with no filler. Every line carries information an agent would otherwise have to guess from an undocumented schema.

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 an output schema present, the description doesn't need to explain return values, and it covers the tricky inputs well. Gaps remain around search_type (which changes the entire dataset: web/image/video/news) and any auth or property-access prerequisite, so it is strong but not 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?

Schema description coverage is 0%, so the description must carry the load, and it does for site_url formats, date format/timezone/inclusivity, allowed dimensions, and the filters object with a concrete example. However row_limit (default 100, implied max 1000) and especially search_type (default 'web') are never explained, leaving two behavior-changing parameters undocumented in both places.

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 (query) and resource (search analytics metrics: clicks, impressions, CTR, position) scoped to a property. It is clearly distinguishable from searchconsole_list_sites and searchconsole_inspect_url by the metric/report framing, though it never names those siblings 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?

Usage is implied by the metric/date-range framing, but there is no explicit guidance on when to use this versus searchconsole_inspect_url or searchconsole_list_sites, nor any prerequisites such as needing the property to be verified. An agent must infer the choice from tool names alone.

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 only the returned field list, which the output schema likely already documents, and says nothing about permissions or 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?

A single tight sentence with the resource and return contents front-loaded; nothing is wasted, though it is arguably too terse to carry usage guidance.

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 to document the return shape and annotations cover the safety profile, so the description mainly needs to name the operation and scope, which it does. Missing only the alternative for reading cell data.

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 spreadsheet_id has 0% schema description coverage, and the description never explains its format or where to obtain it. However, with only one self-evident identifier parameter, the practical cost of the gap is small, 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 ('Get') and resource ('spreadsheet metadata') and enumerates exactly what is returned (title, locale, time zone, tabs). It is clearly distinguishable from sheets_read_range, though it does not name that 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?

No explicit when-to-use or when-not-to-use guidance, and no mention of the sibling sheets_read_range for cell values. Usage is only implied by the metadata-only scope of the description.

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?

Despite annotations already declaring readOnly/idempotent/non-destructive, the description adds substantive behavior beyond them: bounding happens before the request is sent, at most max_rows rows (default 200, ceiling 2000), 52 columns, cell text capped at 1000 characters. It also names the truncation signals returned, which an agent needs to detect partial results.

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 tight sentences: operation and identifier first, then accepted range forms, then limits, then truncation reporting. No filler, and the most decision-relevant constraints are front-loaded.

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-value explanation is unnecessary, and the description still names the truncation fields that matter. The one real gap is silent handling of value_render_option, which affects what cell values are actually returned.

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 compensate. It does well for a1_range (format example, sheet title, named range) and max_rows (default and ceiling), but says nothing about value_render_option's meaning or valid values, and spreadsheet_id is left unelaborated.

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 ('Read cell values from an A1 range') plus a concrete example range, so an agent immediately understands the operation. It does not explicitly distinguish itself from the sibling sheets_get_spreadsheet (metadata vs. cell values), leaving that separation to inference.

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 clarifies accepted input forms ('A1 ranges, a sheet title, or a named range'), which is really input guidance rather than when-to-use guidance. There is no statement of when to prefer this over sheets_get_spreadsheet or when to avoid it, so usage is only implied by the purpose.

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?

The annotations already establish that this is a read-only, idempotent, non-destructive operation, so the description does not need to restate safety. It adds valuable behavioral detail by disclosing truncation limits: at most 100 slides and 2000 characters per slide.

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?

The description is two short sentences with the purpose front-loaded and the important return limits immediately after. Every sentence adds useful information without repetition.

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 the description need not document return structure, and the annotations cover the safety profile. The main remaining gap is that the sole required parameter, presentation_id, is not described at all.

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 compensate for the undocumented presentation_id parameter. It does not explain the ID format, where to obtain it, or any constraints beyond implying it identifies a presentation.

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 specific verb and resource: "Summarize a presentation" with title, slide object ids, and text. It is clearly distinct from the thumbnail sibling, though it does not 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 explicit guidance on when to use this tool versus alternatives such as slides_get_thumbnail or docs_get_document. The use case is somewhat implied by "Summarize a presentation," but no conditions or exclusions are 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, idempotentHint, openWorldHint, and destructiveHint=false. The description adds critical non-schema behavior: the URL is unauthenticated for about 30 minutes but acts as the signed-in user, and it must not be shared. That security and expiry context is exactly the kind of extra behavioral information the description should provide.

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 operation and followed by the important security caveat. Every sentence carries useful information with 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?

An output schema exists, and the description covers safety and URL lifetime well. However, input parameter semantics are entirely undocumented despite 0% schema coverage, leaving an agent without guidance on the size parameter or the relationship between presentation_id and page_object_id.

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%, with three parameters including a size parameter that defaults to MEDIUM. The description mentions 'one slide' but does not explain presentation_id, page_object_id, or acceptable size values, so it barely compensates for the missing schema descriptions.

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: 'Get a PNG thumbnail URL for one slide.' This clearly identifies the operation and distinguishes it from the broader slides_get_presentation sibling. It does not explicitly name a sibling or contrast alternatives, which keeps it from 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?

The use case is implied by 'for one slide,' but the description gives no explicit guidance on when to use this instead of slides_get_presentation or other slide-related tools. No exclusions or alternatives are named.

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 externally. The description adds nothing beyond that: no mention of error behavior for unknown ids, whether a missing tasklist falls back to @default, or what the response contains. Even with output schema present, the near-zero contribution from the text keeps this low.

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?

It is a single front-loaded sentence with zero waste, but for a tool with 0% schema coverage it is undersized rather than appropriately sized. Conciseness is fine; specification is not.

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 tool is a simple read with an output schema and rich annotations, so much of the burden is offloaded. However, the undocumented tasklist_id parameter and its @default fallback leave a genuine gap an agent must guess at.

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 the burden, yet it only hints at task_id via 'by id'. The second parameter, tasklist_id, with its '@default' value, is completely unexplained and an agent cannot infer its role or format.

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 and resource ('Get one task by id'), which lets an agent distinguish a single-item fetch from the sibling list tool tasks_list_tasks. It does not name the sibling or state the contrast explicitly, so it falls 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?

There is no guidance on when to use this tool versus tasks_list_tasks or how to obtain a task_id. Usage is only implied by the name and the word 'one'.

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, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context beyond that, such as pagination behavior, result limits, or what happens with large accounts.

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?

The description is a single front-loaded sentence with no wasted words. It is concise and readable, though its brevity reflects under-specification rather than efficient completeness.

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 tool is simple and has an output schema plus rich annotations, but the two input parameters are entirely undocumented in both schema and description. For paginated list operations, the agent is missing enough context to call the tool correctly.

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?

Both parameters, page_token and max_results, have 0% schema description coverage. The description mentions neither parameter and gives no meaning, format, or default behavior for them, leaving the agent without needed invocation details.

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 and resource: 'List the user's Google Tasks lists.' It is distinguishable from siblings like tasks_list_tasks because it names tasklists rather than tasks, though it does not explicitly call out that distinction.

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 on when to use this tool versus alternatives, no mention of prerequisites such as authentication, and no indication of when not to use it. The listing purpose is only implied by the verb.

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 this as a read-only, idempotent, non-destructive operation, so the description does not need to repeat safety details. It usefully explains the show_completed behavior and the '@default' convention, but omits pagination behavior and what max_results controls.

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?

The description is short, front-loaded with the main action, and avoids repetition. The second sentence earns its place by clarifying a non-obvious parameter behavior.

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 formatting need not be described. Still, for a list operation with four parameters and no schema descriptions, the definition should cover pagination and result-limit behavior 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?

Schema description coverage is 0%, so the description carries the full burden for four parameters. It adds meaning for tasklist_id and show_completed, but leaves page_token and max_results completely undocumented in both schema and description.

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 and resource: 'List tasks in a task list.' It is distinguishable from tasks_get_task and tasks_list_tasklists by name, but it does not explicitly contrast itself with those 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?

It gives a concrete usage hint for the tasklist_id '@default' value and explains when show_completed=true matters. However, it does not say when to use this tool instead of siblings like tasks_get_task or tasks_list_tasklists.

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, openWorldHint, and destructiveHint=false. The description adds useful behavioral context: dates are inclusive, channel defaults to 'channel==MINE', and results contain column names and rows capped at 1000. It does not cover quotas or error behavior, but the annotation coverage lowers that burden.

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?

The description is compact and front-loaded, with useful examples and no filler. Each sentence adds concrete invocation or result-shape 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?

For an eight-parameter query tool with no schema descriptions, the description covers most parameters and the return shape, while annotations cover safety behavior and an output schema exists. The main gap is explicit documentation of max_results and broader quota/error context.

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 the parameter semantics. It gives examples for metrics and dimensions, explains date format and inclusivity, documents filter syntax, states the channel default, and mentions sort usage for top videos. It does not clearly document the max_results parameter beyond the 1000-row output cap.

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 clearly states a specific verb and resource: querying a YouTube Analytics report for the user's channel. It distinguishes itself from generic analytics siblings by naming YouTube Analytics, though it does not explicitly contrast with alternatives such as analytics_run_report.

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 guidance is mostly embedded in examples such as 'top videos need sort "-views"' and the filter syntax. However, there is no explicit explanation of when to use this tool versus alternatives, or when not to use 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 cover read-only, idempotency, open-world, and safety, so the bar is lower; the description still adds two genuinely new traits — a 1-unit quota cost and the 50-video batch cap. It says nothing about partial failures (invalid/private/deleted IDs) or what statistics are actually returned.

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, zero filler, with the batching constraint and quota cost both front-loaded before any invocation decision is made.

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 an output schema present, return values needn't be described, and quota cost plus batch size cover the main call-time risks. A note on what happens with unknown/private IDs would close the remaining 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 coverage is 0%, so the description must carry the load, and it does convey the key semantics: the single parameter is a list of video IDs, capped at 50. It stops short of item format details (bare ID vs. URL) or behavior when the array is empty.

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 concrete verb+resource ('Get details and statistics for ... videos') with a clear scoping constraint ('up to 50', 'by ID'). It implicitly distinguishes itself from youtube_search (ID lookup vs. query), but never names that sibling or any other, so an agent must infer the split.

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 only implied: 'by ID' signals you need IDs already in hand (presumably from youtube_search), and 'up to 50' hints at batching. There is no explicit when-to-use/when-not or named alternative, so the agent must reconstruct the workflow itself.

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, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuinely new behavioral context beyond them: the operation costs 1 quota unit, which matters for a quota-constrained YouTube API. It does not discuss pagination or result limits, but the zero-parameter shape makes those largely moot.

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, and the substantive scope constraint is front-loaded before the cost note. 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 an output schema present and rich annotations, the definition needs only to say what is listed and any cost caveat, both of which it does. A note on whether results include channel IDs or whether unauthenticated calls fail would close the remaining gap, but nothing essential is missing.

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 and the schema is trivially complete, so there is nothing for the description to compensate for. Baseline 4 applies; no parameter claims are made or needed.

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 (YouTube channels) plus the scope qualifier 'owned by the signed-in user', which separates it from public-facing siblings like youtube_search and from youtube_list_my_playlists. It never names a sibling explicitly, so the differentiation is inferred rather than stated.

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 phrase 'owned by the signed-in user' implies the when-to-use context (fetching your own channel identity rather than searching public content), but there is no explicit guidance on when not to use it or which sibling to pick instead. An agent must infer the boundary from the scope phrase alone.

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 read-only, idempotent, non-destructive, and open-world behavior. The description adds useful operational context by stating the quota cost per page, though it does not elaborate on pagination 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 short sentences with no wasted language. Purpose is front-loaded and the quota note is appended efficiently.

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 rich annotations and an output schema, the description covers purpose and quota cost. However, the input schema has no parameter descriptions, and the description does not compensate for page_token or max_results semantics.

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%, and the description does not explain the two optional parameters, page_token and max_results. The phrase 'per page' hints at pagination but does not clarify how to use the token or result limit.

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'), resource ('playlists'), and scope ('owned by the signed-in user'), which clearly separates it from siblings like youtube_list_playlist_items and youtube_list_my_channels. The purpose 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?

The description says what is listed but gives no when-to-use, when-not, or alternative-tool guidance. An agent must infer that youtube_list_playlist_items or youtube_search should be used for other needs.

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 establish that this is read-only, idempotent, non-destructive, and open-world. The description adds useful behavioral context by disclosing quota cost per page, but it does not explain pagination behavior or other operational constraints beyond that.

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?

The description is two short sentences with zero waste and the core purpose is front-loaded. Both sentences contribute useful 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 not be described, and annotations cover safety. However, with 0% schema description coverage on three parameters, the description is too thin to fully guide correct invocation, especially around pagination and result limits.

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 compensate for three undocumented parameters. It hints at playlist and page semantics, but does not explain playlist_id format, page_token usage, or max_results meaning/defaults.

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 and resource: 'List videos in a playlist.' This clearly identifies the operation and distinguishes it from playlist-listing or video-search siblings, though it does not 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?

It only implies usage by saying the tool lists playlist videos. There is no explicit guidance on when to use this versus youtube_list_my_playlists, youtube_get_videos, or youtube_search, and no exclusions or prerequisites are mentioned.

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 real context the annotations cannot carry: 100 quota units per call (1% of the default daily quota), a 25-result ceiling per call, and a hard 20-call limit per server process. The annotations already cover readOnly/openWorld/idempotent, so this extra cost and throttling information is genuine added value. It does not explain pagination behavior despite exposing page_token.

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?

Front-loads what the tool does, then immediately the cost warning, then the constraints. Every sentence carries information; the only minor friction is the quota arithmetic in parentheses, which is worth keeping.

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 quota/call-cap behavior is well covered. However, for a paginated search tool the description says nothing about how page_token relates to the 25-result cap or what order accepts, which an agent needs to page correctly.

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 compensate and it only partially does: it explains the for_mine/kind='video' coupling and implies max_results is capped at 25. Four parameters — order, page_token, and the accepted values of kind — get no semantics at all, leaving the agent with bare untyped defaults.

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 ("Search YouTube") and names the sort of operation it is not by pointing at the list tools. An agent can distinguish it from youtube_list_my_playlists or youtube_get_videos without inspecting the schema. It falls short of a 5 only because it doesn't spell out what the search covers (videos vs channels vs playlists) beyond the for_mine note.

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?

"Prefer the list tools when possible" is an explicit alternative plus a selection condition, and the quota warning gives an economic reason to follow it. The exclusions are somewhat soft ("when possible" leaves the agent to judge), so it is not a full 5.

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