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

With annotations indicating a non-destructive write (readOnlyHint=false, destructiveHint=false) but not idempotent, the description adds significant transparency: it explains what is returned (created itemId and questionId from batchUpdate replies), notes the cost of appending ('costs one extra read'), and lists unsupported features (file-upload, grids, quiz grading). No contradiction with 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 a single dense paragraph with the core purpose stated first, then type catalog, then key behaviors and limitations. No redundant sentences; every clause adds information (e.g., 'can't be created via the API', 'need raw_request'). Efficient and front-loaded.

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

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

Given the tool's complexity (17 parameters, 9 question types, no output schema), the description covers return values, type-specific requirements (choice types require options), parameter behaviors (low/high, labels, rating levels), and critical limitations. It even explains the internal mechanism (batchUpdate). This is complete for an agent to use effectively.

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 has 100% coverage but the description adds meaning beyond it: it explains that 'choice types require options[]', clarifies the index behavior (omitted = append, costs an extra read), and details how type enum maps to human-readable question types. This enriches raw parameter listings.

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 'Adds a question to the form' and enumerates all supported types with clear semantics ('radio (single choice), checkbox (multiple choice)'). It distinguishes from siblings via 'a convenience wrapper over batchUpdate createItem' and explicitly mentions returning itemId and questionId, making 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?

Provides clear when-to-use context: 'index inserts at that position; omit to append'. Explicitly directs users to 'update_question' for quiz grading and 'raw_request' for grids, and states file-upload is not supported. This helps the agent choose between alternatives.

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

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

Adds meaningful behavioral assurances beyond the readOnly/idempotent/non-destructive annotations: 'Makes no network calls and never returns the token itself.' This is important safety context for an auth-status tool and goes well beyond what annotations already 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?

The description is dense but each clause earns its place: the first sentence lists the diagnostic fields, the second adds safety behavior, and the third gives a usage directive. It is front-loaded with the core purpose and contains no fluff.

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

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

For a zero-parameter read-only status tool with no output schema, the description is complete: it lists every relevant status dimension and the specific trigger for calling it. An agent has enough to decide when and why to invoke it.

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 is 4. The description compensates by enumerating exactly what information the status output will contain, which is more useful than a bare schema with no properties.

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 purpose: reporting Google connection status, token presence/source, expiry, account email, OAuth scopes, and credential locations. This clearly distinguishes it from sibling auth-flow tools like start_login, finish_login, and logout.

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 an explicit trigger: 'Call it first when other tools report the server is not connected.' It does not explicitly list when not to use it or name an alternative, but the diagnostic role relative to the login/logout siblings is clear.

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 indicate readOnlyHint=false (mutation) and destructiveHint=false, but the description goes beyond by explaining the 'openWorldHint' behavior: API-created forms are unpublished by default, and if the publish step fails, the form still exists with publish_error. It also clarifies that document_title cannot be changed later, adding valuable behavioral detail not in 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 well-structured and front-loaded with the core purpose and return values, then adds important caveats and workflow guidance. It is a bit long but every sentence provides necessary operational details, such as 'never create_form again', which earn their 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?

Given no output schema, the description adequately explains return values (formId, revisionId, responderUri, publishSettings) and error handling (publish_error). It covers complex behaviors like chaining with set_publish_settings, making it complete for the tool's complexity and mutation nature.

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 each parameter is already documented (title, publish, document_title). The description adds meaning by explaining that 'title' is the shown form title, 'publish' controls immediate publication, and 'document_title' is the Drive file name that cannot be changed later—value beyond the schema's basic descriptions.

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

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

The description clearly states 'Creates a new Google Form and returns it' with specific result fields, and it distinguishes itself from siblings by noting that questions and settings are added or updated with separate tools. It also mentions the form is unpublished by default, a key differentiator from other tools.

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 explicitly explains when to use this tool (to create a form) and when not to (e.g., 'never create_form again' if publish fails). It also references alternatives like 'add_question', 'update_form_settings', and 'set_publish_settings', providing clear usage context.

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

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

Beyond the annotations (destructive, non-idempotent), the description discloses the index-shifting side effect and recommends re-fetching indexes. This adds valuable behavioral context not present in the annotations alone.

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

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

The description is two sentences, front-loaded with the action and parameter, immediately followed by a critical usage caveat. No wasted words.

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

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

For a simple delete tool with two parameters, the description covers the core behavior and the key side effect (index shifting). It is sufficiently complete for correct invocation, even without 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 schema already provides full coverage for both parameters, including the 0-based index and form_id format. The description adds the list of deletable item types, but this is a minor enhancement 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?

The description clearly states the tool deletes an item at a specified 0-based index and enumerates item types (question, page break, text block). It uses a specific verb and resource, making it distinct from sibling tools like move_item or update_question.

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 important guidance to re-check indexes with get_form between successive deletes, addressing a common pitfall. It does not explicitly name alternatives or when not to use this tool, but the context is clear enough.

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 richly discloses behavior beyond the annotations: it saves tokens to an owner-only file, verifies via a read-only identity call, handles partial permission grants by still saving the login and reporting missingScopes, replaces previous logins with best-effort refresh token revocation, and returns previousAccountEmail. This goes well beyond the basic annotation hints.

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 dense but efficient: four sentences cover purpose, postcondition, partial-permission handling, and account-replacement behavior. Every sentence adds meaningful information, and the key purpose is front-loaded in the first sentence.

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, the description is complete: it explains what happens, what is returned, what happens on partial permission, and what happens when switching accounts. No important invocation or result information 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 has zero parameters, so the input schema already covers everything. The description adds value by explaining what the response contains and the side effects of invoking the tool, which is useful context even though no parameter documentation is 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?

The description clearly states the tool finishes the second step of Google login, saves tokens to an owner-only file, verifies the login via a read-only identity call, and returns account email and granted scopes. This distinguishes it from the sibling start_login by explicitly labeling it as the second step and describing its specific outcome.

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 context: this is the second step after browser consent, and after success every tool works immediately without restart. It also clarifies behavior under partial permission grants and account replacement, but it does not explicitly name alternatives or state when not to use it, 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 read-only, idempotent, and non-destructive. The description adds useful behavioral context beyond annotations: the return structure, item ordering, and index semantics for mutations. It does not contradict annotations and provides meaningful extra insight.

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

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

The description is two sentences with no redundant words. The first sentence lists the returned data structure, and the second delivers a crucial ordering/index note. Every sentence adds value.

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?

Though there is no output schema, the description enumerates all major components of the returned form and highlights the important ordering property. For a read tool with strong annotations, this is complete and sufficient.

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

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

The schema fully describes the only parameter (form_id) including its source from the form URL or create_form output. The description does not add further parameter detail, so baseline 3 for complete schema coverage 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 explicitly states the tool returns the full form with specific fields (info, settings, items, publishSettings, responderUri, linkedSheetId). This clearly distinguishes it from sibling tools like update_form_info or get_response, which operate on subsets or different resources.

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 includes explicit guidance: 'call this before mutating items' because the returned item order corresponds to indexes used by update_question, delete_item, and move_item. This gives a clear when-to-use and logically excludes alternatives for mutations.

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, and non-destructive behavior. The description adds meaningful detail about the returned structure (answers keyed by questionId, createTime, lastSubmittedTime, respondentEmail, and totalScore 'when available'), which discloses conditional behavior not captured by 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 primary action ('Fetches a single submission by its responseId') and then provides a compact list of return fields and a cross-tool hint. Two sentences with no filler, each sentence 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 get-by-id tool with no output schema, the description fully covers the expected return values and the necessary mapping step for interpreting questionIds. Combined with good annotations and schema, the agent has all context needed to invoke and use the tool correctly.

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

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

The input schema already provides comprehensive descriptions for both parameters (form_id and response_id), with 100% coverage. The description reinforces the response_id source ('from list_responses') but does not add substantial new meaning 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?

The description uses a specific verb ('Fetches') and identifies the resource ('a single submission'), clearly distinguishing it from sibling tool list_responses which retrieves multiple responses. It also lists the fields returned, leaving no ambiguity about the tool's function.

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 explicitly states that the responseId comes from list_responses, indicating a clear call sequence, and advises using get_form to map questionIds to question text. This gives direct guidance on when to use this tool and how it relates to sibling 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?

Beyond the readOnlyHint/openWorldHint annotations, it discloses rate-limit behavior ('lower per-minute quota than other reads'), conditional email visibility, the absence of ordering/email filtering, and that programmatic submission is impossible. No contradiction with 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?

Every sentence is information-dense and earns its place: return value shape, filter caveats, pagination, quota warning. It is front-loaded with the key listing behavior and does not waste words.

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

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

For a paginated list tool with no output schema, it fully explains return fields (including conditional fields and totalScore), filtering limits, pagination mechanism, and rate limits. Combined with complete schema annotations, the 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 covers all 4 params (100%), so baseline is 3; the description adds meaningful semantics for submitted_after (strictly after, exclusive) and page_token (from nextPageToken), plus warns that there is no ordering/email filter. It doesn't restate param names, making it a net positive.

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?

Opens with 'Lists submitted responses', a specific verb+resource that clearly distinguishes from sibling get_response (single) and get_form. It enumerates the exact returned fields (responseId, createTime, etc.), making the purpose unmistakable.

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 guidance: submitted_after is 'the API's only filter', 'there is no ordering or email filter, do that client-side', and 'Paginate with page_token from nextPageToken'. It also points to get_form for resolving questionIds and advises incremental polling due to lower quota.

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 goes well beyond the annotations by naming the revocation endpoint, specifying that the local credentials file is deleted, clarifying that env-var tokens are unaffected, and mentioning the envTokenStillSet response field. This is exactly the kind of behavioral detail an agent needs for a destructive action.

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 with the most critical action front-loaded. Every sentence adds important information, and there is no fluff or repetition of schema fields.

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

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

The description covers the action, side effects, exception case for env-var tokens, and a relevant response field. For a zero-parameter tool with no output schema, this is fully sufficient for an agent to use it correctly and predict its impact.

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 is no parameter meaning to add. The description correctly focuses on the action and side effects rather than inventing parameter details. Baseline 4 is appropriate because the schema is trivially complete.

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 precise verb and resource: it revokes the stored Google token and deletes the local credentials file. The title 'Disconnect from Google' aligns with the behavior, and the description clearly distinguishes this from other auth-related sibling tools.

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 context: use this to revoke and delete stored credentials. It also explicitly tells the user that env-var tokens are not touched and must be removed manually, which is a valuable usage caveat. It does not name alternatives, but no true alternative exists for this action.

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?

Beyond the annotations (destructiveHint=true, openWorldHint=true), the description discloses many critical behavioral traits: watches expire after 7 days, renew reactivates SUSPENDED watches, notification payload is limited to formId/watchId/eventType, topic must grant Pub/Sub Publisher role, and specific limits (1 per user+form+event, 20 per project). This is rich, transparent context that helps the agent anticipate side effects and constraints.

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 information-dense yet well-structured: it opens with the purpose, then methodically covers actions, prerequisites, expiration/renewal behavior, notification payload, and limits. Every sentence adds value without redundancy, making it long but appropriately so for the tool's complexity.

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?

Despite lacking an output schema, the description is remarkably complete for a multi-action tool. It covers all four actions, required setup, permissions, lifecycle behavior (expiry/renew), notification attributes, follow-up tool suggestions, and usage limits. The only minor omission is explicit return value structure, but 'list shows your watches' and the mention of watch_id for create implicitly cover it.

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?

Although the schema already describes each parameter (100% coverage), the description adds deeper semantics: event_type values are explained (RESPONSES = new submissions, SCHEMA = form structure changes), topic_name requires a specific IAM role, watch_id can be custom for create, and actions have different parameter requirements. This adds substantial meaning beyond the schema fields.

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

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

The description clearly states it 'Manages Cloud Pub/Sub push-notification watches on a form' and enumerates four distinct actions (create, list, delete, renew), making the tool's purpose highly specific and distinguishable from sibling tools that handle form editing or response retrieval.

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 provides explicit guidance on when to use each action, including required parameters per action, permission prerequisites, and even post-notification next steps (call list_responses or get_form based on event_type). This goes well beyond a simple usage statement and effectively guides the agent on alternative actions when notifications arrive.

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 adds critical behavioral context beyond annotations by explaining that 'to_index is the position after removal', preventing off-by-one errors. It also mentions that the operation depends on the current order, implying the need to fetch the form first. Annotations already indicate this is a mutation (readOnlyHint=false), and the description is consistent.

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

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

The description is two sentences with no wasted words. The first sentence states the operation and the key index semantics; the second provides a practical prerequisite. 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 simple reorder operation with three parameters and no output schema, the description covers the essential behavior, index semantics, and a prerequisite. It does not mention the return value, but given the low complexity and absence of an output schema, this is not a critical gap.

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

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

Schema coverage is 100%, so baseline is 3. The description adds significant meaning by clarifying that both indices are 0-based and, crucially, that to_index is interpreted after removing the item. This goes beyond the schema's 'Target 0-based position' and clarifies the parameter relationship.

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

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

The description clearly states the action: 'Moves the item at from_index to to_index', with explicit indexing semantics. This distinguishes it from sibling tools like delete_item, add_question, and update_question by indicating a reorder operation.

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 provides a clear prerequisite: 'Use get_form to see the current order first.' This tells the agent when to invoke the tool relative to other steps. It does not explicitly name alternatives or exclusions, but the context makes the intended use clear.

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 destructiveHint=true and openWorldHint=true, so the risk of arbitrary calls is flagged. The description adds useful behavioral context beyond annotations: the Bearer token is added automatically, the method defaults to GET, and the path may include a query string. It does not contradict the annotations.

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

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

The description is front-loaded with the core purpose and then provides illustrative examples. It is slightly verbose with multiple examples in one sentence, but each sentence earns its place by clarifying important usage nuances (query strings, automatic auth, method default). It strikes a reasonable balance between completeness and conciseness.

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 the tool's open-ended and destructive nature, the description covers the essential invocation details: path format, method, body, query strings, and auth. There is no output schema, but for a raw API pass-through, the response format is inherently endpoint-dependent. The description could mention error handling or raw JSON response, but it is sufficient for an agent to select and invoke it correctly in most cases.

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%, but the description adds practical meaning beyond field names: it gives a concrete path example with batchUpdate, shows how to format the body as {'requests':[...]}, and notes that the path can carry a query string. This enhances the schema's minimal descriptions, though much of the information is also already present in the schema's own examples.

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 explicitly identifies the tool as an 'escape hatch' for any Google Forms API v1 path, with a specific verb ('call') and resource ('any Google Forms API v1 path'). It distinguishes itself from typed siblings by stating it covers requests 'the typed tools don't cover', making its unique role 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?

The description clearly states when to use this tool: 'for requests the typed tools don't cover'. It provides concrete examples of such cases (batchUpdate, writeControl, etc.). It does not explicitly enumerate alternatives or say 'don't use if a typed tool exists', but the 'typed tools don't cover' phrasing strongly implies that exclusion.

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 indicate idempotentHint=true (safe to call again) and readOnlyHint=false (it's a write). The description adds valuable context: it stores the client once in a shared path, is reused by all mcp-google-* servers, and tokens stay per-server. It also warns against pasting secrets. This goes beyond annotation basics, though it does not mention any potential side effects like overwriting an old client.

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, each earning its place: the first explains what and source, the second details storage scope, the third directs to start_login. The critical warning is naturally integrated. It is not overly verbose and the essential info is front-loaded.

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

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

For a single-parameter tool with no output schema, the description covers key operational aspects: the source file, the storage path, the security precaution, and the follow-up step. The only minor gap is the absence of error conditions (e.g., if the file is invalid), but that is acceptable given the simplicity.

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 baseline is 3. The description reinforces that the path is to the JSON file and adds the explicit 'must never be pasted into the chat' security guideline. It doesn't add much beyond the schema, but the security note is valuable enough to nudge to 4.

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 specifies a clear verb ('saves') and resource ('OAuth client credentials from the JSON file') and adds detail about the source and storage location. It does not explicitly distinguish from siblings, but the uniqueness of this tool among the listed siblings is implicit given its specific task.

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 provides clear guidance on when to use the tool: after downloading the JSON file and before starting login. It also mentions the prerequisite of calling start_login after. However, it does not explicitly state when not to use it or mention alternatives, though none are obvious.

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 indicate destructive, idempotent, non-read-only behavior, but the description adds valuable context beyond that: the default mirroring of is_accepting_responses, the ability to keep a form visible but closed, and the failure mode for legacy forms. No contradictions with 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 two sentences, front-loaded with the primary action, and every sentence adds unique information (default behavior, use case, legacy limitation). No wasted words.

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

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

For a mutation tool with no output schema, the description covers the essential context: default parameter behavior, a common use case, and an edge case failure. Combined with rich annotations, the agent has enough to select and invoke the tool correctly.

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

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

The input schema already provides 100% coverage of parameter descriptions, so the baseline is 3. The description adds extra meaning by explaining that is_accepting_responses defaults to is_published, and by showing how the two boolean parameters interact. This enriches the schema without redundancy.

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 starts with a specific verb phrase 'Publishes or unpublishes the form and opens/closes response collection,' clearly identifying the resource (form) and the actions. It distinguishes itself from siblings like update_form_settings by focusing specifically on publication state and response acceptance.

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 clear usage guidance: explains the default relationship between is_published and is_accepting_responses, gives a specific use case (published form but closed), and explicitly states a when-not: fails on legacy forms and should be managed in the Forms UI instead. This effectively communicates when to use the tool and when to avoid it.

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

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

Annotations already mark it read-only, idempotent, and non-destructive; the description adds valuable context beyond that: it works without credentials, warns that Testing-mode refresh tokens expire in 7 days, mandates publishing the consent screen, and guarantees it never asks users to paste secrets into the chat. No contradiction with 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 dense sentences each carry unique, decision-relevant information: the checklist's contents, the shortened path when already configured, and the no-secrets guarantee. There is 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?

For a zero-parameter instructional tool, the description fully covers purpose, usage timing, workflow relationships, and key behavioral safeguards. The lack of an output schema is acceptable since the tool's job is to present instructions, and the annotations already cover the operational profile.

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 is empty and parameter coverage is 100%, so there is nothing for the description to add about parameter semantics. The zero-parameter case earns the baseline 4.

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 deliverable: a step-by-step checklist for connecting the server to Google, including project creation, OAuth client, consent screen, and handing the client JSON path to set_client. This clearly distinguishes it from sibling tools like auth_status or set_client.

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 when to use it (before credentials exist) and how the checklist shortens when an OAuth client is already configured, referencing set_client as the downstream consumer. It provides clear workflow context, though it does not explicitly say 'use this instead of X' for every 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?

The description adds substantial behavioral context beyond the annotations: it does not open the browser itself, uses a one-shot listener on 127.0.0.1, exchanges the code locally, never passes it through chat, and has a 10-minute attempt lifetime. These details are not present in the annotations and provide meaningful operational guidance.

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 dense but every sentence earns its place: it covers user interaction, browser constraints, security, timeout, and next step without repetition or filler. The most important user-facing instruction is front-loaded.

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

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

For a tool with no parameters and no output schema, the description is fully complete. It explains the returned authorizeUrl, how to present it, what will happen afterward, and which sibling tool to call next.

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 schema carries no burden and the description correctly avoids inventing parameter details. The baseline for a 0-parameter tool is 4; the description also reinforces that no configuration files or restart 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?

The description opens with 'First step of connecting from the chat' and names a specific resource and action: start the Google login and return an authorizeUrl. It is clearly distinguished from siblings like finish_login and auth_status by positioning itself as the initial step.

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 explicitly states when to use it: as the first step of connecting, without editing config files or restarting the client. It also gives direct instructions to show the authorizeUrl to the user, ask them to open it in the browser, and call finish_login after the success page appears.

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 indicate mutating behavior (destructiveHint=true, readOnlyHint=false) and idempotentHint=true. The description adds important behavioral details: it only touches provided fields (partial update), requires at least one field, and returns batchUpdate replies with new revisionId. It also notes the limitation that the document title cannot be changed, which is useful. However, it doesn't disclose any potential side effects or error conditions beyond what annotations imply.

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 concise, with three sentences that are all informative. It front-loads the core purpose in the first sentence, then explains the partial-update behavior, and finally notes the Drive rename limitation. No fluff or repetition of schema details.

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 the tool's moderate complexity (3 parameters, decent annotations, no output schema), the description covers the purpose, usage, and important behavioral nuances (partial updates, rename limitation, return value). It lacks an explicit mention of error handling or prerequisites (e.g., if the form must exist), but overall it is complete enough for the intended use. Slight deduction for not mentioning what happens if neither title nor description is provided, though the description implies it's 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 parameters are already well-documented. The description adds value by explaining that only provided fields are touched and that at least one field is required (though the schema implies this via required form_id, it doesn't explicitly say at least one of title/description). It also clarifies the form_id from the URL. This is a typical baseline of 3 when schema covers the 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?

The description clearly states the tool's purpose: 'Changes the form's title and/or description.' It specifies the resource (form) and the scoped fields (title/description), and distinguishes it from siblings like update_form_settings by focusing on title/description rather than settings. The mention of the Drive rename limitation further clarifies what the tool does not do.

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 provides clear context on when to use this tool: when updating title or description. It also explains when not to use it for renaming the Drive file, suggesting an alternative (Drive API) but not a sibling tool. However, it doesn't explicitly contrast with sibling tools like update_form_settings or add_question, though the specified fields make it fairly clear.

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?

Beyond annotations, it discloses partial-update semantics ('only the provided fields are touched'), explains the meaning of email_collection_type values (VERIFIED requires signed-in respondent, RESPONDER_INPUT lets respondent type email), and clarifies quiz mode only enables grading with per-question details set later. No contradiction with 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 dense sentences front-load the purpose and pack enum semantics, sibling-tool guidance, and update behavior without redundancy or filler. 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 settings-update tool with no output schema, the description covers the operation's scope, parameter meaning, partial updates, and the correct sibling tool for related grading configuration. The tool is fully usable based on the description alone.

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%, but the description adds meaningful semantics: it explains what enabling quiz mode actually enables, expands each enum value with behavioral context, and states the at-least-one-field requirement. This goes well beyond the schema's property descriptions.

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

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

The description clearly states the tool toggles quiz mode and/or email collection mode on a form, specifying exact fields and behavior. It distinguishes itself from siblings like update_form_info, update_question, and add_question by naming the specific form-level settings it manages.

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 explicit direction for when update_question should be used instead for per-question grading settings, and notes that add_question cannot set grading. It does not explicitly contrast update_form_info or set_publish_settings, but the scope is clear enough for correct selection.

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 the operation as destructive and not read-only, and the description adds valuable detail: only masked fields change, and masking a field left unset clears it. This goes beyond the annotation hints and helps the agent predict side effects without fully documenting error cases.

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 concise sentences with no filler. It front-loads the core action, then explains prerequisites and key behavioral semantics, making every sentence informative and necessary.

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 update tool with nested objects and no output schema, the description covers the essential aspects: how to locate the item, how to structure the item object, how update_mask works, and the clearing behavior. It is sufficient for an agent to invoke the tool correctly without needing the schema to fill major 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 covers all parameters (100%), so the baseline is 3. The description enriches understanding of item and update_mask interaction, especially the clearing behavior, which is not fully captured in the parameter descriptions. This added context justifies a 4.

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

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

The description clearly states it updates an existing item via a specific API method, distinguishing it from sibling tools that create, delete, or move items. The title 'Update an item' is generic, but the description adds specificity by mentioning 'question or other' and addressing by index.

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 explicitly instructs to call get_form first to see positions and shape, which is a clear usage prerequisite. It does not explicitly compare to alternatives, but the tool name and sibling context make the intended use apparent; minor omission of when-not-to-use prevents a 5.

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