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

The description describes an add/mutate operation that 'Writes the registry and runs Google consent in the browser', yet the annotations declare readOnlyHint=true. Adding an account and writing the registry modifies state, so the description directly contradicts the readOnlyHint annotation. Otherwise the disclosure of side effects and restart behavior would be strong, but the contradiction forces a 1.

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 action and the two usage modes, then adds side effects and prerequisites. Dense but every sentence carries information; no wasted filler, though the parenthetical about restart timing is a bit packed.

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 scope/side-effect-heavy account tool with no output schema, it discloses the mutation (registry write), the browser consent step, restart timing, and env prerequisites. What is missing is coherence with the annotations rather than raw content, and return-value detail is not strictly required.

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 all six parameters (including the alias-vs-account synonym and optional bundles/admin). The description reiterates the key inputs ('alias + email', 'bundles/allBundles/admin') but adds no syntax or semantics beyond 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+resource ('Add a new Google account') and distinguishes the two invocation modes (direct args vs interactive form), which separates it from siblings like account_list, account_reauth, and account_write_config. An agent can identify the tool's role 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?

Clearly explains the two paths: pass alias+email to skip the form, or pass nothing for elicitation-capable clients. It also names a prerequisite (GOOGLE_CLIENT_ID/SECRET, run the `setup` prompt). It stops short of explicitly naming alternative tools (e.g. account_reauth) for related tasks, so not a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds genuinely new behavior context, spelling out the token-health state machine (ok / expired_refreshable / needs_reauth / missing / decrypt_error) and the granted-vs-configured scope comparison that the caller will observe.

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

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

Two sentences, no filler, and the payload/what-you-get content is front-loaded before the single usage sentence. The inline enum list is compact rather than sprawling.

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 input parameters and no output schema, the description must carry the return-value burden, and it does: it names every field and interprets the health enum values. Nothing an agent needs to correctly call and interpret this tool 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?

There are zero parameters, so the baseline of 4 applies — there is nothing for the description to disambiguate. The description instead adds value by defining the output fields, which it is not strictly required to do.

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 ('List the configured Google accounts') and enumerates the returned fields, so the resource scope is unambiguous. It never names or contrasts itself with the account_add / account_reauth / account_write_config siblings, which is the only thing keeping it from a 5.

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

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

'Use this to see which account aliases are available and healthy' supplies a clear selection context for the tool. It stops short of an explicit exclusion ('to modify an account use account_write_config') so the routing guidance is implicit 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?

Annotations already supply the safety profile (readOnly, idempotent, non-destructive, open-world), so the description's added value is genuinely non-obvious behavioral context: this launches Google consent in a browser, meaning an interactive, user-present flow that cannot be silently automated. It also states the effect (refreshing tokens / granting scopes). It does not say whether old credentials are replaced or what happens if consent is abandoned, and there is mild tension with readOnlyHint=true given scope grants change account state.

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, each earning its place: purpose/conditions first, the key operational trait (browser consent) second, the call directive last. Zero filler.

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

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

Covers purpose, triggers, mechanism and the parameter to pass, which is sufficient for a single-param auth tool with no output schema. Minor gaps: no statement of post-success guarantees (token verified? account state after scope grant) or failure 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 100% and the schema already explains that 'account' is the same as 'alias', so the baseline is 3. 'Pass the account alias' adds a small routing hint on which parameter to use, but the description never addresses the duplicate alias/account pair or why neither is required.

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 ('Re-authenticate an existing Google account') with the two motivating conditions spelled out (dead refresh token, scopes after a profile change). 'Existing' implicitly separates it from the sibling account_add, so an agent can route between them 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?

Gives clear triggering conditions: the refresh token is dead, or scopes must be granted after a profile change. It does not explicitly say when to prefer account_add/account_write_config, but 'existing account' makes the boundary inferable. No exclusions or prerequisites (e.g. browser availability) are stated.

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

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

The description states that write:true 'write[s] detected file-based configs in place', i.e. it mutates files on disk, while the annotations declare readOnlyHint=true and destructiveHint=false. An agent trusting the annotations would assume this tool has no side effects, which is false for the documented write path. This is a direct contradiction (though the description's own safety notes — 'backs up first, never clobbers a malformed file', 'Secrets are never inlined' — are genuinely informative and align with idempotentHint/destructiveHint=false).

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

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

Three tight sentences, front-loaded with the purpose ('Register this server with your MCP client') before mode details and safety guarantees. Every clause earns its place: the default behavior, the opt-in write path, and the backup/non-clobber promise.

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

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

With no output schema, the description correctly tells the agent what the default return is ('the exact snippet/command to add') and covers the risky write path's guarantees. It omits what happens for undetected/unsupported clients or on write failure, but for a zero-required-parameter helper on a fully documented schema this is nearly 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 100%, so the schema already documents name (default mcp-google-multi), write (default false = snippet only) and the client enum with 'default = all detected'. The description repeats the write-mode semantics without adding format, precedence, or resolution details beyond the schema. Baseline 3 is correct when the schema carries the load.

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: 'Register this server with your MCP client ... returns the exact snippet/command to add.' It is immediately distinguishable from siblings like account_add/account_reauth, which concern accounts rather than client-side config generation. The two operating modes (emit snippet vs. write in place) are named up front.

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 prescribes when to use each mode: default returns the snippet, 'Pass write:true to write detected file-based configs in place.' Concrete client targets (Claude Code / Claude Desktop / Cursor) are given. However, it never routes the agent away from adjacent tools (e.g., account_add) or states prerequisites, so it stops short of the explicit when/when-not/alternatives bar.

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 it read-only, idempotent, and non-destructive. The description adds that it reveals hidden tools and must be called before invoking them, which is useful behavioral context, but it omits return format, pagination, or auth details.

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

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

Front-loads purpose and usage in the first sentence, then lists available operations. The enumeration is long but informative for a discovery tool; the '+1 more' phrasing is slightly messy but not severely wasteful.

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 discovery tool with no output schema, it explains that it returns a catalog of hidden tools and how to invoke them. It does not cover the query parameter behavior or relationship to sibling discovery tools, but core invocation is addressed.

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

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

Schema description coverage is 100% and the single query parameter is already documented in the schema as 'Filter keyword'. The description does not mention the query filter or add meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb 'Discover' and resource 'calendar', and clarifies it lists the catalog and reveals hidden tools. It does not explicitly differentiate from sibling discovery tools like discover_all or google_api_search, though the calendar scope is clear.

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

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

Explicitly says 'call first, then call the tool by name', giving clear ordering context. It does not mention when not to use it or name an alternative such as discover_all, so it is not a full 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description usefully adds that this is a discovery/meta step that 'reveals hidden tools' and must be invoked first. However, enumerating 'create, update, delete' as ops alongside a readOnly annotation creates real potential for the agent to mistake this for a mutating call, and the return structure of the catalog is never characterized.

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 core instruction is front-loaded in the first clause, and the workflow ordering follows immediately. The long semicolon-delimited ops enumeration is dense and its value is questionable, but the description is not padded with filler.

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

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

With no output schema, the description carries the burden of explaining what discovery returns, and 'lists the catalog and reveals its hidden tools' plus the ops enumeration gives the agent a usable roadmap. It still does not describe the shape of the catalog response or how a 'hidden tool' is addressed by name, leaving a modest gap for a meta-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% ('query: Filter keyword'), so the schema already documents the single optional parameter. The description never mentions that query filters the catalog listing, so it adds no semantic value beyond the structured field; baseline 3 applies.

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

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

The description states a specific action ('lists the catalog and reveals its hidden tools') on a specific resource (contacts), and distinguishes itself from siblings like discover_all and gmail_discover by scoping to the contacts domain. The trailing 'Ops' enumeration is confusing because it lists downstream operations (create/update/delete) rather than what this call does, muddying the otherwise clear purpose.

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?

Explicit sequencing guidance is given: 'call first, then call the tool by name.' That tells the agent exactly when this tool belongs in the workflow and what follows it. It does not name a competing sibling (e.g., discover_all) or state when not to use it, keeping it short of a 5.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and open-world behavior. The description adds useful output context ('returns copy-pasteable fixes for anything wrong') and the report scope, though it repeats the read-only hint and omits auth prerequisites 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?

Two tightly written sentences: the report contents are front-loaded in a colon list, followed by safety/output note and the call-to-action. No filler or 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?

With no input parameters and no output schema, the description must carry the return-value burden, and it does: it lists the report sections and says it returns copy-pasteable fixes. Annotations cover safety and idempotency, so an agent has enough to call it correctly.

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

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

The tool has zero input parameters, so parameter semantics are not applicable; the baseline for 0 params is 4. The description does not need to explain any parameters.

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 diagnostic resource (server health report) and enumerates the covered areas (runtime, config, keys, token status, scope grants, API enablement). It does not explicitly name or differentiate from sibling tools, but the diagnostic purpose is clear against the discover/account-management siblings.

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

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

Explicitly says 'Call this to diagnose auth/config failures', giving a clear trigger context. It does not list exclusions or alternative tools for related but different diagnostics, so it falls short of full when/when-not guidance.

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

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

Annotations already declare readOnlyHint/idempotentHint true and destructiveHint false, so the safety profile is covered. The description adds real behavioral context beyond that: this bulk-reveals the curated toolset rather than a single service, and it should be paired with discover_reset, implying a persistent discovery state. It does not explain whether already-discovered tools are duplicated, but the gap is minor given 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?

Two tight sentences; the action and bulk scope are front-loaded, followed by usage conditions. No filler or restated title.

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

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

With no parameters, no output schema, and annotations covering the safety profile, the description carries everything an agent needs: what is revealed, when to prefer it, and the companion reset tool. Nothing material is missing.

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

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

The tool takes zero parameters, so parameter semantics are trivially satisfied and the baseline is 4. Nothing in the description is needed to clarify 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 ('Reveal') and resource ('ALL curated Google tools'), with the scope ('at once, instead of per-service discovery') that separates it from the gmail_discover/drive_discover family. An agent can distinguish it from every sibling 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?

Explicitly prescribes when to use it ('when starting substantial Google work'), names the alternative it replaces (per-service discovery) and the downstream preference over google_api_call, and pairs it with discover_reset. When-to-use, alternative, and follow-up are all present.

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 only cover the read-only/idempotent safety profile; the description adds the non-obvious behavior that collapsing does not unload tools permanently — they remain callable by name. That is real context beyond structured fields, though it omits what the call returns or whether it is a no-op when already at default.

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 action front-loaded and no filler; the payoff (all tools still callable) follows immediately. Minor: neither sentence is wasteful.

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 parameters, no output schema, and annotations already carrying the safety profile, the description supplies enough for correct invocation. A note on idempotent/no-op behavior or confirmation output would close the remaining gap.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies.

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

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

States a concrete verb and effect: collapse the tool surface back to the configured default. It is clearly the inverse of the *_discover / discover_all siblings, though it never names one explicitly to sharpen the contrast.

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

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

"Reclaiming context budget after heavy Google work" gives a clear triggering condition for when to call it, and the second sentence sets expectations afterward. It stops short of stating when not to use it or naming an alternative tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering safety. The description adds that the tool 'reveals its hidden tools' and must be called first, which is key behavioral context. Auth and rate limits are not covered, but with annotations that is acceptable.

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 purpose and sequence in two compact clauses. The trailing 'Ops:' list is long but informative and earns space by enumerating available hidden tools; there is no filler.

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

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

For a discovery tool with one optional parameter and no output schema, the description provides the essential call-first workflow and reveals that a catalog and hidden tools are returned. Nothing critical for invocation is missing, though it could clarify what 'Ops' refers to.

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 sole optional parameter 'query' is documented as 'Filter keyword'. The description does not mention the query parameter or add syntax/format details, so it adds no value beyond the schema. 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 ('Discover docs') and describes output: 'lists the catalog and reveals its hidden tools'. The docs domain distinguishes it from sibling discover tools like drive_discover, though no sibling is named explicitly in the text.

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?

Provides explicit sequencing: 'call first, then call the tool by name.' This tells the agent when to use it (first) and what to do next. No when-not or alternative discovery tools are mentioned.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds genuinely useful context beyond that: this is a meta-discovery step that must precede invoking any drive tool, and it signals the breadth of the hidden catalog. It omits return shape/pagination details, but with annotations doing that work a 4 is warranted.

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?

Purpose and call-order are front-loaded, which is good, but the long op enumeration ('search, read, list, upload... delete, trash +26 more; 35 generated ops...') is filler that describes the discovered catalog rather than this tool and risks confusing the agent about scope.

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, but the description conceptually explains the return (a catalog of drive tools and op areas) and the required call order, which is the key information an agent needs. The misleading op list is the main residual gap.

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

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

Schema description coverage is 100% for the single 'query' filter parameter, so the schema already documents it fully. The description never mentions filtering by keyword, adding no meaning beyond the schema; per the coverage rule, baseline 3 is correct.

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 clause states a specific verb and resource ('lists the catalog and reveals its hidden tools') and the 'drive' scope distinguishes it from gmail_discover, calendar_discover, and the other domain discover tools. The trailing enumeration of downstream ops (upload, delete, trash) muddies what this tool itself does, keeping it short of a clean 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?

'call first, then call the tool by name' gives an explicit usage order and makes clear this is the entry point for the drive domain. It does not, however, mention sibling entry points like discover_all or google_api_call as alternatives, so the routing guidance is incomplete.

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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is already covered. The description adds valuable behavioral context: it reveals hidden tools, requires being called first, and lists the operation names that become available, which is more than the annotations provide.

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

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

The core purpose is front-loaded and clear, but the trailing operation list is long and ends with a confusing fragment ('+12 more; 58 generated ops: users'). It could be trimmed without losing essential meaning, though the operation names do provide useful context.

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 discovery tool with no output schema, the description is nearly complete: it explains the first-call requirement, the catalog reveal, and the tools it exposes. It does not explain the return format of the catalog or how the query parameter affects results, leaving minor 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?

The single parameter 'query' is fully described in the schema as 'Filter keyword'. The description does not add any meaning about how the query filters the catalog, so the schema carries the full semantic burden. This matches the baseline of 3 when schema coverage is 100%.

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

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

The description names the specific verb and resource ('Discover gmail') and states exactly what it does: lists the catalog and reveals hidden tools. It distinguishes itself from other service discovery tools by naming Gmail, and the instruction to call it first before invoking tools by name makes the purpose 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?

It gives clear sequencing guidance: 'call first, then call the tool by name.' This tells the agent when to use it relative to the hidden tools it reveals. However, it does not compare against sibling discovery tools like discover_all or explain when to use a service-specific discover instead.

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

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

Annotations declare destructive/openWorld/idempotent hints, so the safety profile is largely covered; the description still adds meaningful context the annotations don't — the tool is 'subject to the same write-control policy as named tools', returns 'JSON only', and advises a `fields` param on reads to limit payload. It stops short of permissions/error/rate-limit detail, so not 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?

Four tight sentences, all load-bearing: capability, discovery routing, policy note, read optimization, and output-type boundary. Front-loaded with the core purpose and no filler.

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

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

For a 6-parameter, open-world mutation tool with no output schema, the description covers the key gaps: return format is JSON-only, the binary case is redirected, and the write-control policy is stated. It could say more about how methodId maps to path/query/body, but nothing essential is missing.

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

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

Schema description coverage is 100%, so the parameters (api alias, methodId, pathParams, queryParams, body, account) are already documented in-schema. The description only adds the optional `fields` partial-response tip, which is helpful but marginal; 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 (invoke) and resource (any Google Workspace REST method) plus the selection mechanism (Discovery method id), and explicitly frames itself as the escape hatch for operations without a dedicated tool. An agent can distinguish it from the *_discover and google_api_search siblings without opening any 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?

Explicitly routes the agent: 'Find methods with google_api_search first' for discovery, and 'for binary/file content (media downloads, drive.files.export) use drive_download / drive_export instead'. Both the when-to-use and the when-not-to-use alternative are named.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds real value beyond that by describing what is returned (method ids and parameters) and the workflow it feeds into, plus the full alias vocabulary. It does not mention result caps or pagination, so it is not fully transparent.

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?

Purpose and behavior are front-loaded in the first sentence, with the alias list trailing as reference data. The ~30-item alias list is long but functional since no enum is defined in the schema; it is justifiable 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?

No output schema exists, so the description carries the return-value burden and does describe the shape ('method ids + parameters'). Combined with full annotation coverage and documented parameters, an agent has enough to invoke correctly, though result-count and ranking behavior are 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% (api and query documented, maxResults not). The description compensates by enumerating the accepted API aliases for the `api` filter, which the schema does not provide, and reinforces the query intent with 'method ids + parameters' output framing. It adds genuine meaning over the schema.

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

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

Names the specific verb and resource ('Search the Google API Discovery index for any Workspace REST method') and immediately scopes it to methods with no dedicated tool. This distinguishes it from both the per-service *_discover siblings and google_api_call, which it explicitly hands off to.

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 discovery-to-invocation workflow ('Returns method ids + parameters to invoke via google_api_call') and that it covers methods lacking a dedicated tool, which implicitly tells the agent when a dedicated sibling is preferable. It stops short of naming a specific alternative tool or stating exclusions explicitly.

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

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

Annotations already declare readOnlyHint/idempotentHint true and destructiveHint false, so safety is covered. The description adds genuine behavioral context beyond them: that it enumerates a catalog plus hidden tools, and that it is the prerequisite entry point for named tool calls.

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 before the op enumeration, and every clause carries information. The long semicolon-delimited ops list is useful but slightly dense.

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 discovery tool with no output schema, the description adequately explains what it returns (catalog + hidden tools) and the follow-up workflow. It could note polling/refresh behavior or relationship to discover_reset, but nothing critical 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?

Only one parameter (query) with 100% schema description coverage, so the schema already documents it as a 'filter keyword.' The description adds no further semantics about its matching or format, which is the expected baseline when the schema fully covers the parameter.

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

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

States a specific verb and scoped resource: 'Discover meet: lists the catalog and reveals its hidden tools.' The 'meet' scoping distinguishes it from gmail_discover/drive_discover siblings by resource, though it never contrasts with discover_all or discover_reset.

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 sequencing guidance ('call first, then call the tool by name'), telling the agent this must precede invocation of the enumerated ops. It stops short of explaining when to prefer it over discover_all or other parallel discover tools.

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

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

Annotations already establish readOnly, idempotent, and non-destructive behavior. The description adds meaningful behavioral context by stating that it reveals hidden tools and by enumerating the available operations, which helps the agent understand the effect and scope of the call beyond the safety annotations.

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

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

The description is front-loaded with the core action and sequencing instruction, then supplies the operation list compactly. The list is long, but every item is useful for understanding what the tool reveals, and there is no redundant prose.

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

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

For a discovery tool with no output schema, the description gives an adequate sense of what is returned: a catalog and hidden tools, including the named operations. Combined with annotations covering safety, this is nearly complete, though it could clarify how to invoke the revealed operations by name.

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 input schema has 100% description coverage, and the single parameter is documented there as a 'Filter keyword.' The description does not add any additional meaning about the query parameter, so the baseline of 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?

The description states a specific verb and resource ('Discover searchconsole'), explains that it lists a catalog and reveals hidden tools, and identifies itself as the required first call. It clearly differentiates itself from sibling discovery tools such as gmail_discover and drive_discover by naming the searchconsole 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?

It gives explicit sequencing guidance: 'call first, then call the tool by name.' This tells the agent when to use it relative to the hidden tools it reveals. It does not compare itself to discover_all or explain when not to use it, so it falls just short of full alternative coverage.

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

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

Annotations already declare readOnly and idempotent, so the safety bar is low. The description adds genuinely useful behavior beyond that: this tool reveals hidden tools and must be called before the real operation, which is non-obvious discovery semantics.

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 lead sentence is front-loaded and earns its place, but the semicolon-delimited op enumeration trails off with '+19 more; 7 generated ops: spreadsheets', which is cryptic and partially incomplete noise rather than actionable 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 single-param, read-only discovery tool with no output schema, the description covers what it returns (a catalog), how to use it (call first), and what it unlocks. The truncated op list is the only rough edge.

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?

One optional parameter with 100% schema description coverage ('Filter keyword'), so the schema already carries the semantics. The description adds nothing about how the query filter works, so baseline 3 is correct.

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 ('Discover sheets: lists the catalog and reveals its hidden tools') and its scope is clear versus sibling discovery tools by naming the domain. It doesn't explicitly differentiate itself from discover_all, which is the nearest 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?

'call first, then call the tool by name' gives explicit sequencing guidance for how this tool fits into a workflow. It stops short of stating when NOT to use it or how it differs from discover_all/discover_reset.

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

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

Annotations already establish readOnlyHint, idempotentHint, and non-destructive behavior. The description adds meaningful behavioral context by stating that the tool reveals hidden tools and must be invoked before calling those tools by name, though it does not cover return format, pagination, or auth details.

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

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

The description is front-loaded with the core purpose and usage rule. The operation list is dense but useful for discovery; however, the inclusion of '+2 more' and generated ops adds minor clutter without fully earning 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 simple read-only discovery tool with one optional filter parameter and no output schema, the description is largely complete: it explains what the tool does and when to call it. It could better clarify how the 'query' filter relates to the catalog, but the schema already covers that 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 description coverage is 100%, and the sole parameter 'query' is already documented as 'Filter keyword'. The description adds no additional meaning about the parameter, 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?

The description names a specific verb and resource, 'Discover tasks', and explains the outcome: 'lists the catalog and reveals its hidden tools'. It also distinguishes the tool from the hidden tools it exposes by instructing the agent to 'call first, then call the tool by 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?

The description gives clear sequencing guidance: 'call first, then call the tool by name'. It does not explicitly mention when not to use this tool or name alternatives such as discover_all, so it falls short of full when/when-not guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds that it reveals hidden tools (useful), but says nothing about return shape, pagination, or how the revealed tools are surfaced. Modest added value over the annotations.

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

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

Two compact sentences, front-loaded with the purpose and the sequencing instruction. The trailing 'Ops:' fragment is slightly garbled (claims 15 ops but lists four), though it stays brief.

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 single-parameter discovery tool with no output schema and annotations covering safety, the description is adequate: it names the resource and explains the call-first workflow. The incomplete/ambiguous ops enumeration is a minor gap.

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

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

Only one optional 'query' parameter, and the schema already documents it as a 'Filter keyword' at 100% coverage. The description adds nothing about filter syntax, matching behavior, or empty-query semantics, 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?

Clear verb+resource: it lists a catalog and reveals hidden tools for the 'workspaceevents' service. The 'call first, then call the tool by name' line plus the ops list distinguishes it from direct action tools, though it does not distinguish it from its many *_discover siblings beyond the resource 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?

Gives one useful instruction ('call first'), implying a discovery-before-invocation workflow. But it offers no guidance on when to use this vs. discover_all or the other service-specific discover tools, and no exclusions.

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