Server Quality Checklist

Tool Scores

• update_form_infoA
  4/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• delete_itemA
  4.2/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• raw_requestA
  4.3/5.0
  Behavior4/5

  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.

  Conciseness4/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• move_itemA
  4.4/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• get_formA
  4.5/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• get_responseA
  4.5/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• update_questionA
  4.5/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• create_formA
  4.8/5.0
  Behavior5/5

  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.

  Conciseness4/5

  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.

  Completeness5/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• update_form_settingsA
  4.8/5.0
  Behavior5/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters5/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• list_responsesA
  4.9/5.0
  Behavior5/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• set_publish_settingsA
  4.9/5.0
  Behavior5/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• add_questionA
  5/5.0
  Behavior5/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters5/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• manage_watchesA
  5/5.0
  Behavior5/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters5/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.