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

Annotations already cover the safety profile (readOnlyHint, openWorldHint), and the description adds value beyond them: it enumerates the entity types returned (spaces, group chats, DMs) and gives the concrete id formats. It does not mention any auth prerequisite (the sibling sign_in suggests one) 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 sentences, no filler, with the scope and returned shape front-loaded before the id-format detail. 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?

No output schema exists, so the description doing the work of describing the { id, name } return shape is important and it delivers. The only gap is the unstated dependency on being signed in, which matters for a first-call, id-producing 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?

Zero parameters, so there is nothing for the description to disambiguate and the baseline applies. The id-format note is arguably more relevant to downstream calls than to this tool's own inputs.

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 every space, group chat and direct message') and discloses the exact scope (Google Chat sidebar), which cleanly separates it from read_messages, read_thread and search. It also pins down the return shape as { id, name }.

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?

'Ids ... are what the other tools take' tells the agent this is the entry point for the id-driven siblings, which is real usage context. It stops short of an explicit rule such as 'use this when you don't already have an id; use search to find a space by name', so there is no stated exclusion against 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 readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds real value beyond that: field-by-field return shape, ordering, the 'You' author convention, and a latency warning tied to limit size. That is a solid contribution on top of annotations, though it does not discuss pagination mechanics 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?

Four sentences, each carrying distinct information: scope and ordering, return fields, thread pointers, and the limit/latency trade-off. Scope is front-loaded and no sentence is redundant with 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?

There is no output schema, and the description compensates by enumerating the returned fields and their formats, including the replies summary string. For a two-parameter read tool, nothing an agent needs in order to call it or interpret the result 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 coverage is 100% and both parameters are documented inline, so baseline 3 applies. The description adds context the schema lacks — that a larger limit pages further back and takes longer — but gives no guidance on the default of 50 vs. the 500 maximum.

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 top-level messages of a space or DM) plus scope qualifiers (most recent, oldest first, top-level only). It explicitly separates itself from read_thread for threaded replies, so an agent can choose 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?

Names the alternative explicitly — '"3 replies..."; read those with read_thread' — and gives the cost trade-off for raising the limit ('scroll back through history and take longer'). The top-level-only scope plus the named sibling covers both when-to-use and when to go elsewhere.

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 and openWorldHint, so the safety profile is covered. The description adds real value beyond that by describing the result shape: ordering starts with the thread-opening message, and each message carries space, thread, id, author (with 'You' substituted for the caller), time, and text. It does not mention pagination or message-count limits.

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

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

Two sentences, front-loaded with the core action, then the return fields. Nothing is redundant, though the field list is dense and slightly run-on.

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 documents the returned fields and the 'You' author convention. Combined with the fully covered two-parameter schema and permissive read-only annotations, this is largely complete for a small read tool.

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

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

Schema description coverage is 100%, so both 'space' and 'thread' are already documented, including that thread comes from read_messages or search. The description adds no parameter detail, so the baseline 3 applies.

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

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

The description gives a specific verb and resource ('Read every message in one thread'), making the scope unambiguous. It does not explicitly distinguish itself from the sibling read_messages, which an agent could confuse with a per-thread read.

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 statement of when to choose this tool over read_messages or search, nor any prerequisites. Usage is only implied by the phrase 'in one thread,' leaving the agent to infer the selection 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 cover read-only and open-world semantics, and the description adds real value beyond them: a ~20-result cap with Chat's ordering, the exact result fields, the "You" author convention, local timestamp format, and [] on no match. The result cap is hedged ("~20") and pagination/truncation behavior isn't stated, keeping it short of a 5.

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

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

Five short sentences, front-loaded with what it does and what it returns, then the follow-up routing and the empty-result case. No filler or 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?

With no output schema, the description takes on the return-value burden and does so fully — result count, ordering, per-message fields, and the empty-array case. Combined with the read_thread handoff, an agent has everything needed to invoke and interpret 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 coverage is 100% and the single query parameter is already described as words typed into the Chat search box, which the description merely echoes. The description adds no syntax detail (quotes, operators, result narrowing) beyond the schema, so baseline 3 applies.

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

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

States a specific verb and resource ("Search messages") plus scope ("in all of the user's spaces and DMs"), and anchors it to a familiar behavior ("like the Search chat box"). This clearly separates it from list_spaces, read_messages, and read_thread.

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 concrete next-step alternative: "Use read_thread for a result's full thread," which routes the agent correctly after a search hit. It doesn't explicitly state when to prefer list_spaces or read_messages instead of searching, so the exclusion guidance is partial rather than 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?

Goes beyond the annotations by disclosing the two consequences that matter for a write: immediacy and visibility to other people. That is real value on top of readOnlyHint=false and openWorldHint=true. It omits anything about repeated sends creating duplicates (idempotentHint=false already covers that) and does not mention the sending identity's auth requirements beyond 'as the user'.

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

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

Two sentences, no padding. The capability statement comes first and the risk/confirmation guidance second, which is the correct order for a write tool the agent may call mid-conversation.

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 three-parameter mutation with full schema coverage, rich annotations, and no output schema, this covers what an agent needs: what it does, that it is irreversible in the social sense, and that confirmation is required. Missing only minor detail such as whether the response returns the created 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 100%, so space, text, and thread are all documented at the field level, including that thread should be omitted for a top-level message. The description reinforces the space-versus-thread choice but adds no format, length, or mention semantics beyond the schema. Baseline 3 applies when the schema carries the parameter burden.

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 (send a message) plus the two mutually exclusive modes: new top-level message in a space/DM, or a reply in a thread. All siblings are read/lookup tools, so the write tool is unambiguously distinguishable from list_spaces, read_messages, read_thread, and search.

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 precondition and operating context: it posts immediately, others will see it, and the agent should confirm text and conversation with the user first. It does not explicitly say when to prefer this over a sibling, but no sibling sends messages, so no disambiguation is needed. The confirm-first instruction is the key usage guidance and it is stated plainly.

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 declare readOnly=false, destructive=false, openWorld=true and idempotent=true, so safety is covered. The description adds genuinely new behavior: the call blocks for up to 5 minutes, requires human interaction in a visible browser, and returns only after Google Chat has loaded — all things an agent cannot infer from 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?

Three short sentences with zero filler. The mechanism comes first, the trigger condition second, and the blocking/return behavior last — a sensible front-loaded order.

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

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

For a zero-parameter tool with no output schema and safety covered by annotations, this is nearly sufficient. The one gap is failure semantics: it does not say what happens if the 5 minutes elapse without a successful sign-in.

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 no parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter semantics are missing.

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 mechanism: opens a visible Chrome window where the user signs in to their Google account, ending in Google Chat loading. It is clearly distinguishable in practice, but never names sign_out as the inverse operation, leaving that differentiation to the sibling list.

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, non-obvious trigger: call it when another tool reports the user is not signed in. This is exactly the reactive condition an agent needs, and it implicitly excludes calling it when authentication is already established.

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 mark this as destructive and idempotent, and the description adds meaningful context about exactly what is deleted: the local Chrome profile session. It also discloses the practical consequence that nothing on the computer can act as the user until sign_in is called again, and clarifies that the Google-side session is not necessarily ended.

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 three sentences, front-loads the core action and scope, and every sentence adds useful information. There is no repetition or 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?

For a zero-parameter, annotation-covered sign-out tool, the description gives enough context to act correctly. It explains the local scope, the restoration path through sign_in, and the separate remote-session caveat without needing an output 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?

The tool has zero parameters, so there are no parameter semantics for the description to explain. The baseline for a zero-parameter tool is 4, and the description does not need to compensate for missing schema 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 uses a specific verb and resource: deleting the Google session stored on this computer in the server's Chrome profile. It also distinguishes the local sign-out from ending the session on Google's side, so the agent can tell what this tool does and does not cover.

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 clearly frames the tool as local sign-out and names sign_in as the way to restore the ability to act as the user. It also directs the user to Google Account security settings for remote session termination, which is an explicit alternative for a related but different need.

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