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

With no annotations, the description carries the full burden. It usefully discloses the return value ('Returns the copy's URL') and that native Docs copy semantics apply, but says nothing about permissions needed, whether sharing/comments carry over, or where the copy is placed (e.g. same folder). Modest but real disclosure.

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, front-loaded with the action and ending with the return value. Every clause earns its place with no redundancy.

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

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

For a 3-param mutation with no annotations and no output schema, the description covers purpose and return value, which is the main gap-closing information. It still omits permission requirements and title optionality, leaving the agent to infer behavior.

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 67%: `doc` and `account` are well documented in the schema, but `title` has no description. The phrase 'with a new title' partly compensates by indicating the title param names the copy, though it does not clarify whether title is optional or defaults to 'Copy of X'.

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 ('Make a copy of a Google Doc') and clarifies it maps to Docs' native 'Make a copy', which distinguishes it from docs_create and docs_rename. It does not explicitly name those siblings, but the copy action is unambiguous.

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

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

There is no guidance on when to copy versus create from scratch (docs_create) or from a template (docs_templates), nor any prerequisites such as access rights on the source doc. Usage 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?

With no annotations, the description carries the full behavioral burden. It discloses the two creation paths and the copy-then-fill workflow, but says nothing about permissions/scopes required, whether the new doc is opened or returned, or what identifier comes back, which matters for a mutation tool.

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 with an em-dash and colon that front-loads the core action and then branches into modes. It is information-rich without filler, though the run-on structure takes a moment to parse.

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 5-parameter create tool with no output schema and no annotations, the description covers the creation modes, template sourcing, and the follow-up fill step. It leaves only the return value and permission context unspecified, which is a modest gap.

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

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

Schema description coverage is already 80%, so the schema documents text, markdown, account, and template. The description reinforces that text/markdown apply to blank documents only and clarifies the template parameter accepts a gallery name or a URL/id, but adds little the schema does not already state.

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 ('Create a new Google Doc with a title') and immediately enumerates the two creation modes: blank with optional markdown/text body, or copied from a template. It names the relevant siblings (docs_templates, docs_fill) so an agent can distinguish this from docs_copy or docs_fill without opening a schema.

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

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

Clearly routes the agent: use a gallery template name (pointing to docs_templates for the gallery), or any document URL/id to copy, and use docs_fill to populate a template afterwards. It gives strong positive guidance but stops short of explicit when-not-to-use conditions (e.g., when docs_copy is preferable).

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?

With no annotations, the description carries the full burden and does disclose real behavior: steps execute in order within a single tab, and the result reports each step plus whether Drive reflects the change — useful evidence that effects are verified rather than assumed. It omits auth/prerequisite context (whether the doc must be open in a browser) and how a failed lookup behaves, which is a notable gap for a live-editor mutation tool.

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 sentences, front-loaded with the mechanism and the routing rule; the capability list in sentence one is long but mostly load-bearing. Some of the enumerated actions duplicate the nested schema's own 'One action. Selection: … Changes: …' summary, which is mild redundancy rather than padding.

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 complex, 60-step-capable scripting tool with no output schema and no annotations, the description covers identity of the resource, execution semantics, routing, and the shape of the result, which is what an agent needs before calling. Remaining unknowns — failure handling on unmatched find/section, and whether steps are atomic or partially persisted — are left unaddressed.

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

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

Schema coverage is 67% and the description adds meaning beyond it by organizing the action model (selection vs. change steps) and flagging non-obvious mechanics such as Tab moving between table cells when the schema only lists Tab as a key. It stops short of explaining ordering/interaction rules between steps, which the schema hints at but never fully defines.

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 (edit) plus the distinctive mechanism: a sequence of human-like steps driven in the real editor, with an explicit inventory of the step types (find/caret/select/extend/section/insert/text/delete/key/menu/format/undo). It also names the siblings it is not (docs_write/docs_format), so an agent can route without opening schemas.

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

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

Gives an explicit selection rule: use it for anything docs_write/docs_format do not cover, then enumerates the concrete gaps (table rows and columns, page breaks, table of contents, headers), which is effectively the when-not rule inverted. The alternative tools are named rather than implied.

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

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

No annotations are provided, so the description carries the full disclosure burden. It does convey the key side effect of writing a file to disk, which is the most important behavioral fact here, but it says nothing about overwrite protection, authentication requirements, or failure behavior.

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

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

A single front-loaded sentence with zero filler; the verb and resource lead and the format list is the only elaboration. 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?

For a five-parameter tool with no output schema, the description covers the core action but omits what is returned (path? confirmation?), overwrite/error semantics, and account-selection context. It is minimally adequate given the fairly rich schema, 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 80%, so most parameters (doc, path, account, overwrite) are already documented in the schema. The description only echoes the format enum values, adding no syntax, default, or format-specific nuance beyond what is structured.

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 (Download), a specific resource (a Google Doc), and the destination (local file) plus the full set of output formats. This cleanly separates it from siblings like docs_read (content into context) and docs_open (open in browser), so an agent can route correctly without opening the schema.

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

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

The phrase 'to a local file' implies the use case (materializing a document on disk), but there is no explicit when-to-use/when-not guidance and no naming of alternatives such as docs_read or docs_open. Usage is inferable rather than stated.

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

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

With no annotations, the description carries the full behavioral burden and does a reasonable job: it discloses that replace hits every occurrence while preserving formatting, that sections overwrite everything under a heading in the template's own styles, and that results are reported per item. It stops short of stating permission/auth requirements, reversibility, or what happens when a heading is absent.

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 dense sentences, front-loaded with the purpose and then the per-parameter semantics, with no filler. The arrow notation is efficient, though 'Reports each item' is mildly vague about the response shape.

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 5-parameter mutation tool with no annotations and no output schema, the description covers the core write semantics but leaves gaps: no permission requirements, no behavior when a placeholder or heading is not found, no indication whether missing headings are created, and no sibling differentiation in a cluster heavy with docs_replace/docs_edit/docs_type tools.

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 already 100% with useful per-parameter examples, so the baseline is 3; the description earns above baseline by explaining the runtime semantics the schema cannot convey (all-occurrence substitution with formatting retained, markdown body rendered in template styles, per-item reporting).

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 first sentence states a specific verb and resource ('Fill in a template document'), and the two subsequent clauses cleanly delineate the two filling modes. It never names the overlapping siblings (docs_replace, docs_edit, docs_type, docs_templates), so an agent must infer the boundary between 'template fill' and 'regular text replacement' from the framing alone.

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 template-filling framing implies the use case, and the replace/sections split implies which mode applies to which kind of content. There is no explicit when-to-use statement, no when-not, and no routing to alternatives such as docs_replace or docs_edit for non-template edits.

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?

No annotations provided, so the description carries more weight. It notes 'Verified against the saved document' (adds some behavioral context) and implies mutation. However, it does not disclose permissions, reversibility, or what happens on failure. With no annotations, behavioral disclosure is partial.

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 long but well-structured sentence with no waste. Front-loaded with the action and target, then enumerates options. Slightly dense but efficient.

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?

Given 8 parameters, nested objects, no output schema, and no annotations, the description is adequate but leaves gaps: it does not explain return values (e.g., success/failure), account parameter usage (covered by schema), or side effects. Verification note helps but not 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 coverage is 88%, so the schema already documents most parameters. The description adds a little by listing the formatting categories but does not provide syntax or format details beyond what is in the schema. Baseline 3 is appropriate.

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 (format) and resource (existing text in a Google Doc), enumerates the target selection modes (exact text, section, whole document) and the formatting actions. Distinguishes from siblings like docs_write/docs_edit; not a tautology.

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 usage on existing text, but does not explicitly say when to use this tool vs docs_edit, docs_write, or docs_replace. The selection modes give some context, but no when-not 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?

No annotations are provided, so the description carries the burden. 'List' implies a safe read operation and it discloses the returned fields, which adds real value in the absence of an output schema, but it says nothing about permissions, account-scoping behavior, or pagination/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?

Two tight sentences with zero filler; the mode split is front-loaded and the return fields are stated compactly. Appropriately sized for a three-parameter read tool.

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

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

With no output schema, the description usefully enumerates return fields (titles, ids, owners, modified dates), and account/query semantics live in a fully-covered schema. An agent has enough to invoke it correctly, though permission and result-count behavior remain unstated.

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

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

Schema description coverage is 100%, so the schema already documents limit, query, and account including the multi-account use case. The description restates the query behavior but adds no syntax or format detail beyond the schema, matching the baseline.

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 (Google Docs) and disentangles two modes: recent documents vs. Drive search when a query is given. It does not explicitly name sibling tools (docs_read, docs_open), but the list-vs-read distinction is inferable.

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 query parameter's behavior implies when each mode runs ('Omit for recently opened documents'), giving usable context. However, no explicit when-to-use guidance relative to siblings like docs_read or docs_open 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?

With no annotations, the description carries the full burden, and it does disclose two real traits: the operation is non-destructive ('Doesn't change the document') and it has a visible UI side effect (foreground Chrome tab). It says nothing about permission requirements, account constraints, or what happens if the browser is unavailable.

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

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

Two short sentences, zero filler, with the core action and its safety property front-loaded. Nothing needs trimming.

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 2-parameter, 1-required tool with full schema coverage and no output schema, the description covers the action, the delivery mechanism, and non-mutation adequately. Remaining gaps are minor (browser/auth preconditions).

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

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

Schema description coverage is 100%, so both 'doc' and 'account' are fully documented in the schema itself, making 3 the baseline. The description adds no additional parameter meaning such as URL-vs-id acceptance or the account-index convention.

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 (Open) and resource (Google Doc) plus the delivery channel (foreground Chrome tab), which cleanly separates it from siblings like docs_read or docs_list. It stops short of naming an alternative explicitly, so it is clear but not sibling-routing.

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?

'For the user to look at' implies the use case (human viewing) versus programmatic retrieval via docs_read, but the description never states when to prefer this over docs_read/docs_export or what conditions must hold. Usage is inferable rather than explicit.

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?

With no annotations, the description carries the full burden and does disclose real behavior: documents are paged via offset/maxChars, and the 'structure' mode returns an outline of headings, list items, tables, cells and placeholders. It stops short of noting auth requirements, rate limits, or failure behavior.

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

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

Two dense sentences with the core action and default format front-loaded, then the 'structure' mode explained, then paging. Efficient, though the nested format list makes the first sentence long.

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?

No output schema exists, so the description must convey return shape; it does so for each format including the outline contents. Missing only error/auth/pagination-limit context for a 5-param read tool with no annotations.

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

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

Schema description coverage is 100%, so every parameter (doc, format, offset, account, maxChars) is already documented. The description only restates formats and paging, adding no syntax or edge-case detail beyond the schema — 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+resource ('Read a Google Doc') and enumerates the exact output modes, so the agent knows precisely what comes back. It does not name or contrast any sibling (e.g. docs_export, docs_status, docs_open), so 5 is not warranted.

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

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

Usage is implied rather than stated: 'structure ... for planning edits' hints at a read-then-edit workflow, and format selection is contextual. There is no explicit when-to-use vs alternatives or when-not guidance against siblings like docs_export or docs_status.

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?

No annotations are provided, so the description carries the full behavioral burden. It only discloses that the title is changed; it omits whether write permissions are required, whether the change is immediate, or whether anything else in the document is affected.

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. The parenthetical adds precision without bloat.

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 rename mutation with no output schema, the description covers the core action but leaves meaningful gaps around permissions and behavior that annotations would normally cover. It is minimally adequate but not rich.

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 67%: 'doc' and 'account' are well described, but 'title' is not. The description's phrase 'change its title' partially compensates by implying the title parameter is the new name, but adds no format or account semantics beyond what the schema provides.

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 ('Rename') and resource ('Google Doc'), and the parenthetical clarifies the exact change ('title as shown in Drive'). This distinct verb clearly separates it from sibling editing tools like docs_edit, docs_write, and docs_format.

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 guidance, prerequisites, or alternatives are given. The verb implies usage, but an agent gets no help distinguishing this from docs_edit or docs_fill when intent is ambiguous.

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?

With no annotations, the description carries the full behavioral burden. It does disclose two useful traits beyond structured data: formatting around matches is preserved, and the return value is a count of replacements. However, it omits the mutation's irreversibility, any permission/account caveats, and behavior on zero matches.

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

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

Two tight sentences with the operation and its key caveat front-loaded; nothing is wasted and the return value is stated last where it belongs.

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 mutation tool with no annotations and no output schema, the description covers purpose, a formatting behavior, and the return value, but leaves the safety/permission profile unstated. Adequate but with clear gaps for a write 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 83%, so the schema already documents doc, regex, account, replace, and matchCase meaningfully. The description adds no parameter-level meaning beyond the schema, which is acceptable at this coverage level.

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 and scope ('find and replace across a whole Google Doc'), and the parenthetical clarifies the mechanism ('Docs' own Find and replace'). It doesn't explicitly differentiate itself from close siblings like docs_edit or docs_write, but the whole-document replace scope is clear enough to distinguish it.

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

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

Usage is only implied by the tool's name and purpose; there is no explicit when-to-use, when-not, or named alternative (e.g. docs_edit for targeted edits). An agent can infer the intent but gets no 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?

With no annotations, the description carries the full behavioral burden. It implies a non-mutating connectivity check and names the failure mode it diagnoses, but never states that it has no side effects or what the returned bridge state contains, which matters since there is no output schema.

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

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

Two sentences, zero waste, with the diagnostic purpose front-loaded and the invocation guidance second. Every sentence earns its place.

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

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

For a zero-parameter diagnostic with no output schema, the description covers what the tool does and when to call it. It stops short of describing what a successful vs. failed bridge state looks like, a minor but real gap.

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

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

The tool takes zero parameters, so the baseline of 4 applies; there is nothing for the description to clarify beyond the fact that no inputs are 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 and resource — verify the Chrome extension connection and report bridge state — which no sibling tool does. The name docs_status is immediately differentiated from the docs_read/docs_write/docs_edit family.

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 an explicit trigger condition: call it first when another docs_* tool fails with a connection error. This routes the agent to the correct diagnostic step without inference.

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?

No annotations are provided, so the description carries the full burden. It does disclose the shape of the result ('names and styles') and, via the account parameter context, that multi-account selection matters, but it says nothing about whether the gallery is static, whether results are paginated, or any auth requirements for the listing itself.

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 compact sentence that front-loads the verb and resource and ends with the consumer relationship. Every clause earns its place with no redundant restatement of the tool 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?

For a zero-required-parameter read-only listing with no output schema, the description covers what the tool returns and why you would call it. It stops short of explaining how a returned template name is then passed to docs_create, which would have closed the loop fully.

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

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

Schema description coverage is 100%, so the single account parameter is fully documented in the schema itself. The description adds no additional meaning about account handling, so the baseline of 3 applies.

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

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

States a specific verb (List) and a specific resource (Google Docs' template gallery), and enumerates the returned content (names and styles). It is clearly distinguishable from the nearest sibling docs_list, which lists the user's own documents rather than a static gallery.

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 'for docs_create's template' establishes the context in which this tool is used, routing the agent to it when it needs a template value. There is no explicit when-not guidance or statement of alternatives, but the intended call sequence is clear from the description 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?

With no annotations, the description carries the full burden and does so richly: it discloses async behavior (short text returns before completion, long text keeps typing in the background even after the call ends in Chrome), the returned job id for docs_typing and an ETA, and how formatting is applied via Docs shortcuts versus paste. These are exactly the runtime traits an agent cannot get from the schema or 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?

Front-loaded with the core purpose and dense with useful detail, with no wasted sentences. The middle sentence is long and run-on, which slightly hurts readability, but every clause carries behavioral 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 15-parameter async tool with no output schema, the description covers the critical missing pieces: the return value (job id + ETA) and background-execution semantics. It stops short of covering failure modes (e.g., anchor-not-found) or permission/account edge cases, but those are largely handled by 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?

Schema coverage is 93%, so the baseline is 3, but the description adds real meaning: it maps profile to concrete speed (natural ~55 wpm), quantifies it ("55 wpm types ~275 characters a minute"), and explains that typos are corrected with Backspace and that pauses occur between sentences and paragraphs. This goes beyond the per-parameter schema text without fully restating it.

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 ("Type into a Google Doc") and immediately differentiates itself from the sibling docs_write by describing keystroke-by-keystroke human simulation rather than bulk insertion. It even names docs_write to anchor the shared positioning modes, so an agent can distinguish the two without opening either schema.

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

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

Gives clear context for when this is appropriate (human-paced, natural rhythm, "like a person") and routes the agent to docs_typing for job tracking, but never states an explicit when-not rule or a crisp choice criterion versus docs_write beyond "same positions." The guidance is clear but leaves the deliberate selection decision partially to inference.

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?

With no annotations, the description carries the full behavioral burden and does supply useful context: pause/resume is stateful ('resumes where it stopped'), and status surfaces progress, ETA, and verification. However, it never flags that 'cancel' is irreversible/destructive, and it omits the blocking semantics of the 'wait' action entirely (only the schema mentions it).

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, front-loaded with the check/control framing and the action inventory, then the stateful-resume rule and the default-job rule. Every clause earns its place; the only blemish is that the action list is incomplete, omitting 'wait' which the enum contains.

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 job-control tool with no annotations and no output schema, the description covers the action set, the resume guarantee, and the default target reasonably well. It is still short of complete: the destructive nature of cancel and the blocking/timeout behavior of wait are not stated, and with no annotations those behavioral facts must come from the description.

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 100%, so the schema already documents both parameters and the enum, establishing a baseline of 3. The description adds genuine meaning beyond the schema by explaining the omitted-job default ('acts on the most recent one') and by expanding what 'status' returns (progress, ETA, verification), which the schema's one-word enum values do not convey.

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 pair ('Check or control docs_type jobs') and enumerates the five lifecycle actions it supports, so an agent knows this is the control plane for jobs created by docs_type rather than the generator itself. It stops short of explicitly contrasting itself with docs_type or docs_status, but the 'docs_type jobs' scoping does most of the differentiation work.

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 one concrete usage rule: 'Without job, acts on the most recent one,' which tells the agent the job parameter is optional and what the default targets. It never states when to prefer this over docs_type or docs_status, nor when each action is appropriate, leaving the agent to infer the check-vs-control split from the verb list.

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

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

With no annotations, the description carries the full burden and does disclose destructive behavior: replace_document overwrites the body, replace_text with empty content deletes text, replace_section wipes the section. It also notes the return value ('says whether Drive has the change'). It omits auth/permission requirements and any reversibility or conflict guidance for a mutation tool.

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-loaded with the core verb and resource before the dense mode catalogue. Every clause adds information, though the parenthetical-heavy mode enumeration reads as a wall of text and could be tightened with parallel phrasing.

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?

No output schema exists, and the description does state the return shape minimally ('says whether Drive has the change'). For a 9-parameter mutation tool, mode semantics, markdown support, and overwrite/deletion behavior are covered; only permissions and failure modes are absent.

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

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

Schema coverage is 89%, so the baseline is 3, and the description adds genuine value the schema lacks: the mode enum values are undocumented in the schema but are defined here, including mode-relative meaning for `anchor` and the deletion behavior of replace_text. Markdown features (images, pagebreak, task lists) are also spelled out, which the schema only gestures at via the `markdown` field.

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 ('Write markdown (or plain text) into a Google Doc, typed in the document's own styles') with an exhaustive mode list, so an agent immediately knows this is a content-writing tool. It does not, however, distinguish itself from the many overlapping siblings (docs_edit, docs_replace, docs_type, docs_fill), leaving the agent to infer boundaries.

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 per-mode conditions: replace_document 'overwrites the body', replace_text 'with empty text deletes it', replace_section anchors on 'heading text' and replaces everything up to the next same-or-higher heading. That is real conditional guidance for choosing a mode, but there is no statement about when to prefer this tool over the sibling edit/replace/type 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?

No annotations are provided, so the description carries the full behavioral burden and falls short. It does not say where the copy is placed, whether sharing/permissions carry over, what identifier is returned, or whether the source deck is unaffected. For a mutation tool with zero annotation coverage this is a meaningful gap.

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 compact sentence with the action and the key qualifier front-loaded. Nothing is wasted, though the brevity is partly under-specification rather than discipline.

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

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

With no annotations and no output schema, the description should compensate but does not. It omits the return value (presumably a new presentation id), the copy's destination, and any cross-account implications of the 'account' parameter.

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 67%: 'deck' and 'account' are documented in the schema, while 'title' has no description. The phrase 'with a new title' does clarify that title names the resulting copy rather than the source, adding modest value, but it gives no format or length guidance.

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 ('Make a copy of a presentation') and adds the scope qualifier 'with a new title'. It is immediately clear what the tool does, though it never differentiates itself from siblings like slides_create or docs_copy.

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 versus slides_create (a fresh deck) or slides_rename (retitling an existing deck). No prerequisites, no mention of the account parameter's relevance to cross-account copying.

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?

With no annotations, the description carries the full burden and does disclose some non-obvious behavior: the template deck is copied rather than mutated, and entries run in order against evolving numbering. However, it omits mutation/permission implications, account/auth caveats, and any failure behavior for a write-capable tool.

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 every clause carries information. The second sentence is dense with nested conditions ('give it a layout to change that') but stays on topic.

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 4-parameter creation tool with a nested 11-property slide object, no annotations, and no output schema, the description covers the main creation and fill paths but omits what the call returns (e.g. the new deck's id/URL) and any limit or permission context, leaving chaining and error handling underspecified.

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

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

Schema coverage is 75% and the schema already documents the nested slide entry fields in depth, so baseline is 3. The description adds real meaning beyond the schema: that the template accepts 'any deck URL or id' and is copied, and that on a blank deck the first entry targets the existing title slide while later entries are appended.

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 ('Create a Google Slides presentation') and clarifies the two optional paths (template copy, inline slide fill). It distinguishes itself from slides_write implicitly through the fill semantics and from slides_copy by noting the source deck 'is copied', but it never names an alternative 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?

The description explains how the slides entries behave once you call it, but never says when to use slides_create versus slides_copy (copying an existing deck) or slides_write (filling an existing deck). An agent must infer tool selection from the name 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?

No annotations, so the description carries the full burden, and it does substantial work: steps run in order in one editor tab, changes are verified against the saved deck. It does not state auth/account requirements or failure behavior beyond 'verified', and the account parameter's purpose is only in the schema, so it falls 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?

Front-loaded with the core purpose and sibling scope in the first clause; the rest is a tight enumerated list of operations. It is long but every clause maps to a step action, with little 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?

For a complex 3-parameter tool with nested step objects, no output schema and no annotations, the description orients the agent but does not explain the step ordering/verification semantics in depth (e.g., what 'verified against the saved deck' means on failure, the 80-step limit, account switching). Adequate minimum viable context, with clear gaps.

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 67% and the description names the key step families (go to slide, select shape by number or role, select text, type over, format, keys, menu commands, undo). It does not add syntax beyond the schema (e.g., what 'contains/occurrence' means or the step cap of 80), so it complements but does not fully 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?

States a specific verb (edit) and resource (presentation) plus the mechanism (human steps), and explicitly scopes itself against the sibling: 'for what slides_write does not cover'. An agent can distinguish it from slides_write and slides_type without opening a schema.

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

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

Names the alternative (slides_write) and the boundary condition (what slides_write does not cover), and lists the concrete operation families it handles (typing over text, formatting, menu commands, undo). The step vocabulary in the schema mirrors that usage list.

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

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

With no annotations, the description carries the full behavioral burden; it does disclose the dual mode (whole-deck file vs single-slide image) and that output lands on the local filesystem. It is silent on overwrite semantics for existing files, required auth/account, and failure behavior, which are meaningful gaps for a disk-writing tool.

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

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

A single front-loaded sentence that leads with the primary action and then the conditional image case — no filler, no repetition of the 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?

For a six-parameter mutation tool with no annotations and no output schema, the two operating modes and format mapping are covered, but the overwrite flag is undocumented anywhere and there is no hint of return behavior or side effects on existing files.

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 67%, so the schema documents deck, path, slide and account reasonably well. The description adds genuine value by mapping human format names ('txt') onto the enum and by tying slide to the image formats, but it says nothing about overwrite or the account 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 concrete verb (save) plus resource (presentation) and enumerates the exact output formats, which cleanly separates it from the docs/presentation read-write siblings. It never explicitly names a sibling (e.g. docs_export), so differentiation relies on the reader inferring 'presentation' vs 'document'.

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 clause '(pass slide)' implicitly tells the agent when to supply the slide parameter, i.e. only for png/jpeg/svg. Beyond that there is no when-to-use framing, no mention of prerequisites (an account, an existing deck) and no alternative tool named for other operations.

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?

No annotations are provided, so the description carries the full burden. It discloses the mode switch driven by query presence, but says nothing about the read-only/listing nature, pagination, ordering, or what limit does, leaving notable behavioral gaps for a tool with zero annotation coverage.

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

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

A single sentence with the primary function front-loaded and the conditional behavior trailing, no filler. 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?

For a 3-parameter tool with no annotations and no output schema, the description covers how to choose the query mode but omits limit semantics, account scoping, and any sense of the result set. Adequate but with clear gaps.

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 67%: query and account are self-documented in the schema with rich text, while limit has no description anywhere and the tool description never mentions it. The description reinforces query's effect but adds no new parameter semantics, so the baseline 3 holds.

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 ('Google Slides presentations') and describes two modes of operation, so an agent knows roughly what it gets. It does not name any sibling (e.g., slides_open vs docs_list) to sharpen the boundary, which keeps it 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?

It gives the selection condition explicitly: omit query for recently opened, supply query for a Drive search. That is clear usage context for the main branching decision, though it offers no when-not or alternative-tool 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?

With no annotations, the description carries the full burden. It usefully discloses the side effect that a new foreground tab is created (focus-stealing), but says nothing about auth requirements, error behavior, or what happens if the deck is not found.

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; the verb, resource, side effect, and optional qualifier are all packed in without 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?

No output schema exists, so the description should indicate what is returned (e.g., URL or tab reference) and note the account-selection behavior; it does neither. Adequate for the core action but leaves real gaps for a 3-parameter tool.

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

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

Schema coverage is 67%: deck and account are documented, but slide has no description beyond a minimum of 1. The description only mentions 'optionally at a slide', adding little beyond the schema and leaving indexing semantics (1-based) unexplained.

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

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

States a specific verb (open) and resource (presentation) plus the concrete effect: a new foreground Chrome tab. It is clearly distinguishable from siblings like slides_read or slides_list, though it does not explicitly name an alternative.

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 'for the user to see' implies the use case is user-facing visual display, but the description never says when to prefer this over slides_read or slides_export. No exclusions, prerequisites, or sibling routing 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?

With no annotations, the description carries the full burden and does disclose return behavior well: layout, numbered shapes with roles and positions, markdown text with bullet nesting, tables, images, speaker notes. It leaves unstated that the operation is read-only (only implied by 'Read') and says nothing about truncation or how offset/maxChars affect 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?

Front-loads the purpose in the first clause, then enumerates modes compactly with no filler sentences. Dense, but every clause conveys distinct information about output shape.

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 read tool with no annotations and no output schema, the description adequately covers what comes back for the default 'outline' mode and sketches 'text' and 'json'. The remaining gap is paging/truncation semantics tied to offset and maxChars, which an agent calling with large decks would need.

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 50% (deck, slides, account are documented in-schema; format, offset, maxChars are not). The description fully compensates for 'format' by describing all three enum modes, but offset and maxChars remain completely undocumented in either location, leaving real gaps in call semantics.

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

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

States a specific verb and resource ('Read a Google Slides presentation as saved in Drive') and is clearly distinguishable from siblings like slides_write, slides_edit and docs_read. The three named output modes further pin down exactly what the tool produces.

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?

Explains the three format choices and what each yields, noting 'outline' is the default, and cross-references slides_write/slides_edit by explaining the shape numbers they consume. However, it never states when to prefer this over docs_read/slides_open or any exclusions, so guidance is clear but not complete.

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?

No annotations are provided, so the description carries the full behavioral burden and provides essentially none. It does not mention required permissions, whether the old title is recoverable, side effects, or the multi-account auth implications introduced by the account parameter.

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 no wasted words, but it is undersized for a three-parameter mutation tool. Brevity here reflects under-specification rather than disciplined concision.

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

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

With no annotations, no output schema, and a mutation operation, the description should say more about permissions, the result of the call, and the account-selection behavior. As written, an agent can guess the action but lacks enough context to call it confidently in multi-account scenarios.

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 description adds nothing to the schema, which already documents deck and account reasonably well while leaving title undescribed. With 67% schema coverage, the description should compensate for the remaining gap but makes no attempt to explain title's expected format or any constraints.

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 ('Rename') and resource ('presentation'), making the operation unambiguous. The resource type differentiates it from the docs_* siblings without needing to name them 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 by the verb: you rename a presentation when its title needs changing. There are no explicit when-to-use/when-not conditions, no prerequisites, and no mention of alternatives like slides_copy for duplicating under a new 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?

With no annotations, the description carries the full burden. It discloses operational scope (all slides, shapes and tables) and the occurrence=Nth-match behavior, but omits whether the deck is permanently mutated, permission/auth requirements, and what the operation returns; "Verified against the saved deck" is suggestive but vague.

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 compact sentences with the core purpose front-loaded and no redundant filler. The trailing "Verified against the saved deck" is slightly vague but minor.

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 mutation tool with 8 params, nested objects, no annotations and no output schema, the description covers scope and input modes adequately but leaves auth/permission behavior and side effects (does it save the deck?) underspecified.

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 63% and find/replace/regex have no schema descriptions. The description compensates by explaining the two input modes (find+replace vs replacements map) and clarifying that occurrence targets only the Nth match, adding real meaning beyond the raw field 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?

States a specific verb (find and replace) and resource (Slides), and scopes it precisely to 'every slide (shapes and tables)'. The phrase "Slides' own" implies it uses the native Slides mechanism, which helps distinguish it, though it does not explicitly name docs_replace as an alternative.

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 clear context: use find + replace for simple cases, or replacements: {find: replace, …} to fill a template's placeholders in one call. This conveys when each form applies, but offers no explicit when-not-to-use or named alternative.

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?

With no annotations, the description carries the full burden and does so: it discloses that replace mode is destructive ('clears the shape first'), that long text is chunked into ~90-second segments each verified against the saved deck, and that the call blocks until typing completes. It also notes typos are simulated and then fixed with Backspace, so the agent knows the intermediate state is intentional.

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 sentence is front-loaded with the core purpose and the destructive 'replace clears first' caveat appears early. It is a single dense run-on that packs mode, formatting, chunking, and return behavior together, which costs some scannability but wastes no content.

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 12-parameter tool with no output schema and no annotations, the description covers timing, verification, blocking behavior, and destructive semantics well. Remaining gaps are failure handling (what happens if verification fails mid-chunk) and whether anything is returned, though the latter matters less for a typing action.

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 92%, so the schema already documents wpm, seed, typos, pauses, profile, account, markdown, and shape. The description adds only marginal semantic value beyond that — the markdown implementation detail (bullets/numbers become real lists; bold and italic toggled via Cmd+B/I) is genuinely new, but other parameters are not elaborated on.

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 opens with a specific verb and resource ('Type text into a slide') and immediately qualifies the distinctive mechanism: keystroke-by-keystroke human-paced input rather than a bulk write. It enumerates the targets (title, subtitle, body, numbered shape, speaker notes), which makes it distinguishable from the sibling write/edit tools without opening their schemas.

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

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

Mode semantics are spelled out ('replace (default) clears the shape first; append adds paragraphs after its text'), but the description never states when an agent should pick this tool over slides_write, slides_replace, or slides_edit. The human-typing framing implies a demo/recording use case, but that inference is left to the reader.

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?

No annotations are provided, so the description carries the full burden. It does add real traits: slides inherit the deck's layouts/theme, output is "Verified against the saved deck," and delete/duplicate semantics are noted. But it omits destructive warnings for `delete`, permission/auth implications, the 60-slide cap, and any return-value 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?

Front-loaded with the purpose, then the entry model, then markdown behavior, then the verification note. Dense but no wasted sentences for a tool this complex; the parenthetical at the end is the only mildly disposable line.

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 complex write tool with no annotations and no output schema, the description is reasonably complete on input behavior but silent on what a successful write returns (e.g. resulting slide numbers/ids) and on limits like maxItems 60. An agent knows how to call it but not what to expect back.

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 67% and the per-parameter descriptions are already rich (body markdown grammar, layout names, shapes-by-number, after/insert semantics). The description largely restates this, adding the mode switch (`slide` present vs absent) but little syntax beyond what the schema documents.

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

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

States a specific verb pair and resource: "Add slides or change existing ones, in the deck's own layouts and theme." The add-vs-modify distinction keyed on presence of `slide` is spelled out. It does not, however, differentiate itself from siblings like slides_edit or slides_replace, which share the same domain.

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?

Strong intra-tool guidance: no `slide` adds a new slide, `slide: N` modifies one, and change operations (skip, move, duplicate, delete) are enumerated. However there is no cross-tool guidance telling the agent when to choose slides_write over slides_edit, slides_replace, or slides_type, which is the harder selection decision.

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