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

Annotations already indicate a non-read-only, non-idempotent, non-destructive operation. The description adds valuable context that the invitee must accept the invitation before gaining access, clarifying the tool does not immediately grant admin rights. It doesn't mention permissions or error conditions but sufficiently builds on the annotation baseline.

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. The first gives the method and resource, the second explains the invitation behavior, and the third references a related tool. Every sentence serves a purpose with no redundancy.

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

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

With no output schema, the description could have explained response structure, but the input schema covers the pendingInvitation field as output-only. The description adequately covers the creation flow and next steps, though it doesn't mention what the response will look like or potential errors.

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%, with detailed parameter descriptions in the input schema. The tool description itself does not add parameter-level meaning beyond what the schema provides, so it meets the baseline but does not exceed it.

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

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

The description clearly states the tool's purpose: 'POST v1/{+parent}/admins' invites a user to become an account administrator. It distinguishes from sibling tools by specifying 'for the specified account' and mentions the invitation acceptance flow. This is a specific verb+resource match.

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 for use (creating an account admin invitation) and points to an alternative via 'See AcceptInvitation to programmatically accept an invitation.' However, it does not explicitly contrast with location admin creation (gmb_accounts_locations_admins_create) or mention when not to use this tool, so it lacks full exclusion 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 indicate destructiveHint=true, readOnlyHint=false, and idempotentHint=true, so the safety profile is covered. The description adds minimal behavioral context beyond the operation itself, but it does not contradict annotations and confirms the destructive nature. It lacks details on permissions, irreversibility, or response behavior, but the bar is lower given 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 one concise sentence, front-loaded with the HTTP method and resource. It contains no filler and is efficiently structured for quick scanning.

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 operation with one required parameter, the description, combined with the schema and annotations, is nearly complete. It clearly identifies the operation and resource. It could mention the response or error behavior, but given the lack of an output schema and typical delete semantics, it is adequate.

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

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

Schema description coverage is 100%, so the schema already explains all parameters. The description does not add any parameter-specific meaning beyond what is in the schema, so a baseline score of 3 is appropriate.

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

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

The description clearly states verb+resource: 'Removes the specified admin from the specified account.' It distinguishes from sibling tools by specifying 'account' rather than location, and from create/patch/list operations by the verb 'removes'.

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

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of account-level vs location-level admins, nor any exclusion such as 'for location admins, use gmb_accounts_locations_admins_delete instead.' The usage context is only implied by the name and description.

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 no behavioral traits beyond what annotations already declare. Annotations indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered, but the description merely restates the schema's parent parameter description and HTTP method without providing additional context like pagination or authorization requirements.

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 sentence that directly and clearly states the action, with no filler or redundant information. It is front-loaded and perfectly sized for the tool's simplicity.

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 straightforward list operation with comprehensive annotations and full schema coverage, the description is complete enough. It could optionally mention pagination or response format, but these are not critical for the tool's basic understanding, and the openWorldHint and readOnly annotations already imply a read-only list operation.

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

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

Schema description coverage is 100%, so all parameters are already documented in the schema. The description does not add any parameter-level meaning beyond what the schema provides, warranting the baseline score of 3.

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?

Description uses specific verb 'Lists' and resource 'admins for the specified account', clearly distinguishing from sibling tools like gmb_accounts_locations_admins_list which target location admins. The HTTP method and path provide additional clarity.

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

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

No guidance is provided on when to use this tool versus alternatives. It simply states the action without mentioning exclusions, prerequisites, or comparison to sibling list tools such as gmb_accounts_locations_admins_list.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the description doesn't need to restate those. It adds the HTTP method 'PATCH' and the 'Account Admin' scope, which is consistent with annotations. However, it doesn't disclose additional behavioral traits such as allowed update fields or permissions.

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 sentence, front-loaded with 'PATCH v1/{+name}', and contains no filler. It is efficient and to the point, though slightly terse and lacking structure. It earns a 4 for being concise without wasting 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?

Given the rich schema (7 params, 100% coverage) and annotations, the description is minimally sufficient for an experienced user. However, it misses optional guidance like the only editable field being 'role' (present in the schema but not description) and does not mention sibling tools for location admins. It is adequate but not complete.

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

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

Schema description coverage is 100%, with detailed descriptions for name, body, fields, updateMask, etc. The description adds no parameter-level information beyond the path placeholder '{+name}', which is already documented in the schema. Baseline 3 is appropriate.

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

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

The description states 'Updates the Admin' with a clear verb and resource, and scopes it to 'Account Admin'. It distinguishes an update from create/delete siblings, though it doesn't explicitly name alternatives. The phrase 'for the specified Account Admin' is slightly awkward but understandable.

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

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

There is no guidance on when to use this tool versus siblings like gmb_accounts_locations_admins_patch or the create/delete variants. The only implied distinction is the 'Account Admin' scope, but no explicit when-to-use, exclusions, or alternatives are provided.

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

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

Annotations already indicate this is a mutation (readOnlyHint=false, idempotentHint=false), so the description doesn't need to restate that. It adds useful behavioral restrictions (which account types are not creatable, ownership limitations) that are not in the annotations. However, it does not disclose side effects, auth requirements, or error behavior, so it falls short of rich behavioral transparency.

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 appropriately sized: one main sentence followed by four bullet-point constraints. It is front-loaded with the purpose, and every sentence carries unique information (constraints). No redundant 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 complexity (nested body object, 5 parameters) but rich schema, the description provides essential context about what the tool does and key restrictions. It does not explain the response (no output schema), but for a create operation the response is typically the created object, and the schema covers the request shape. The description is complete enough for an agent to select and invoke 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?

Schema description coverage is 100%, so the baseline is 3. The description adds minimal value by paraphrasing 'specific name and type' (accountName and type) and 'given parent' (primaryOwner), but the schema already provides detailed descriptions for every parameter. No new semantic meaning is introduced beyond what the schema already offers.

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 the HTTP verb and resource ('POST v1/accounts') and clearly states 'Creates an account with the specified name and type under the given parent.' It distinguishes this tool from siblings like admin creation (gmb_accounts_accounts_admins_create) or patching (gmb_accounts_accounts_patch) by focusing solely on account creation and including specific constraints.

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 for when to use this tool (creating accounts) and explicitly lists exclusions (Personal/Organization accounts cannot be created, and various ownership restrictions). It does not explicitly name alternative tools, but the exclusions help disambiguate. This is above implied usage because it provides concrete boundaries on applicability.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds behavioral context by disclosing the NOT_FOUND error for nonexistent accounts or insufficient access rights. This goes beyond the annotations and clarifies the error semantics.

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

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

The description is a single, front-loaded sentence that directly conveys the operation and a key error condition. Every word earns its place; no unnecessary filler.

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

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

For a simple GET operation, the description is adequate. It names the resource, the operation, and an error case. No output schema is present, but the return value ('the specified account') is implied. It could explicitly state that the response contains the account, but the current wording is 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?

Schema description coverage is 100%, so the parameters are fully documented in the schema. The description does not add additional meaning beyond what the schema provides; the 'name' parameter is briefly referenced in the path template but not elaborated.

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 'Gets the specified account' with a specific verb and resource, clearly indicating a fetch operation for a single account. It differentiates from list/create/patch siblings by focusing on fetching one account by name.

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

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

Usage is implied: use to fetch a specific account by name. No explicit alternatives or exclusions are stated. The description does not mention when to prefer other tools like accounts_list, but the singular 'specified account' suggests the intended use case.

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 provide readOnlyHint=false and destructiveHint=false. The description adds no further behavioral context, such as side effects or permissions. With annotations present, the description is adequate but not enriched.

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 exceptionally concise, using two short sentences to convey the action and HTTP method. There is zero wasted text, perfectly sized for the simple purpose.

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 tool has 6 parameters including a nested body, no output schema, and the description provides no information about expected response or side effects. For a mutation tool, this is incomplete: it lacks guidance on what the request body should contain or what the result looks like, shifting the burden to the agent.

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%, with each parameter having a clear description. The tool description adds no parameter information, so it neither helps nor hurts beyond the schema. Baseline 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 clearly states the action 'Accepts the specified invitation' with a specific verb and resource. It distinguishes from sibling tools like decline and list by clearly indicating 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?

The description implies usage when one wants to accept an invitation, but does not explicitly state when to use it vs alternatives or any exclusions. It lacks clear context for selection among siblings.

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 (readOnlyHint=false, destructiveHint=false), the description adds no behavioral context. It does not mention side effects, reversibility, authorization needs, or what happens to the invitation after declining. The description merely restates the action implied by the tool name.

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, front-loaded sentence that efficiently conveys the HTTP method and action. No unnecessary words or repetition of structured 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?

With 6 parameters, a nested body object, and no output schema, the description is too minimal. It does not explain the request body, response format, or additional context needed to invoke the tool correctly. The agent would have to rely solely on the schema and tool name.

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

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

Schema description coverage is 100%, with each parameter having a description (e.g., 'name' pattern and 'body' reference). The description itself adds no parameter-level detail beyond what the schema already provides, so baseline 3 is appropriate.

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

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

The description clearly states the action 'Declines the specified invitation' with a specific verb ('declines') and resource ('invitation'). It distinguishes from sibling tools like accept and list by using the 'decline' action.

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 implies usage: use this when you want to decline an invitation. However, it provides no explicit guidance on when to use this versus the sibling 'accept' tool, nor any context about prerequisites or consequences.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description doesn't need to restate safety. It adds the behavioral detail that only pending invitations are returned, which is useful. No contradiction.

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

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

One sentence, direct, front-loaded with the HTTP method and resource. No redundancy.

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

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

For a simple read-only list operation, the description together with rich annotations and schema provides adequate context. It lacks pagination details, but no pagination parameters exist in the schema. The absence of an output schema is mitigated by the clear return type (invitations list).

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 includes descriptions for all 6 parameters (100% coverage), so the description adds no parameter-specific semantics. It does not mention the filter parameter's purpose, but the schema already covers it.

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

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

The description clearly states the tool's function with a specific verb ('Lists') and resource ('pending invitations') for a specified account, distinguishing it from sibling tools like invitation accept/decline.

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 context ('for the specified account') but does not explicitly state when to use this tool over alternatives or any exclusions. It implies usage for retrieving pending invitations.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the safety profile is clear. The description adds useful behavioral context by clarifying that 'all accounts' includes owned and management-rights accounts, going beyond the annotation details.

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

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

The description is two succinct sentences, front-loaded with the HTTP verb and resource name. Every word contributes meaning; there is no fluff or redundancy.

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

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

Given the full schema coverage, clear annotations, and the simple nature of a list operation, the description is complete enough for an agent to select and invoke the tool correctly. It does not need to detail return values since no output schema exists and the purpose is straightforward.

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

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

Schema description coverage is 100%, so the schema already thoroughly documents all parameters (fields, filter, pageSize, pageToken, parentAccount, etc.). The description adds no additional parameter-level semantics, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool lists all accounts for the authenticated user, specifying that it includes both owned accounts and those with management rights. This uses a specific verb ('Lists') and resource ('accounts'), and distinguishes it from sibling tools like get (single account) or admins_list.

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

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

The description provides clear context: it lists all accounts for the authenticated user, implying when this should be used. However, it does not explicitly mention alternatives or when not to use it, such as pointing to accounts_get for a specific account.

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 a meaningful behavioral constraint beyond the annotations: personal accounts cannot be updated. It does not contradict the annotations (readOnly=false, idempotent=true, destructive=false) and provides additional context about the tool's applicability.

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 highly concise: it states the method, the action, and a critical constraint in three short sentences without any fluff. Information is front-loaded and every sentence serves a purpose.

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 rich schema and annotations, the description is sufficient for tool selection and basic invocation. It does not explicitly mention the updateMask requirement or validateOnly parameter, but these are clearly documented in the schema, so the description's brevity does not create 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 all parameters are fully described in the schema. The description itself does not add parameter-specific guidance, but the schema already documents all parameters, including updateMask's constraint that only accountName is editable.

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 updates a specified business account, with a specific verb and resource. The exclusion of personal accounts helps distinguish it from account creation or other account operations. This is a specific and unambiguous purpose.

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

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

The description explicitly provides a when-not guideline: 'Personal accounts cannot be updated using this method.' This tells the agent when not to use the tool, which is sufficient usage guidance even without naming an alternative tool.

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

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

The description discloses that the operation creates an invitation rather than immediate access, which is not captured by the annotations. This is valuable behavioral context beyond the read/write/destructive 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 compact and front-loaded with the HTTP method and resource. Each sentence contributes essential information: the action, the location scope, and the acceptance requirement.

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 create/invite tool with thorough schema coverage, the description sufficiently explains the invitation flow and points to a related tool. It does not need to describe return values since no output schema is expected.

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?

All parameters are fully documented in the schema, so the description does not need to add parameter details. The baseline of 3 applies because the description provides no additional parameter meaning beyond 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's verb ('Invites') and resource ('administrator for the specified location'), distinguishing it from account-level admin creation. The POST path and reference to AcceptInvitation reinforce its specific role.

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 specifies that this tool is for location admins and mentions the requirement that the invitee must accept. It references AcceptInvitation as a related follow-up, but does not explicitly contrast with account admin creation or other 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?

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=true. The description adds the fact that it removes an admin from a location, which is consistent. It does not enrich behavioral understanding beyond the annotations (e.g., no mention of permissions, reversibility, or side effects).

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 sentence, front-loaded with the HTTP method and action. Every word contributes to understanding, with no redundant or filler content.

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

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

For a simple delete operation with good annotations, the description is adequate. It does not mention return values or error conditions, but given the lack of output schema and the simplicity of the operation, it is reasonably complete. Slightly more detail on behavior (e.g., idempotency) could improve it, but annotations fill that gap.

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

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

Schema description coverage is 100%, so the schema fully documents parameters. The description adds no extra meaning beyond what the schema provides, as it does not elaborate on parameter formats or relationships. Baseline of 3 is appropriate.

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

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

The description clearly states the action ('Removes'), the resource ('admin'), and the scope ('from the specified location'). It distinguishes itself from sibling tools like gmb_accounts_locations_admins_create and gmb_accounts_locations_admins_patch by specifying the delete 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 implies usage (when you need to remove an admin from a location) but provides no explicit when-to-use or alternatives. It does not mention exclusions or relationships to other admin operations, so it falls short of clear 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?

Annotations already state readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds only the HTTP method and endpoint pattern, without details on pagination or response structure. No contradictions exist.

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 concise sentence that front-loads the action, with no unnecessary words 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 low complexity, rich annotations, and full schema coverage, the description adequately covers the tool's purpose. It lacks only optional notes on pagination or filtering, but these are not essential for a simple list operation.

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

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

All five parameters have descriptions in the schema, achieving 100% coverage, so the description need not elaborate. The parent parameter's description already explains the location name format, and the description adds no additional parameter 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 states 'Lists all of the admins for the specified location' with a clear verb and resource, and the endpoint pattern explicitly targets location admins, distinguishing it from the sibling account-level admins list.

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

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

The description does not explicitly state when to use this tool over alternatives, such as excluding account-level admin listing. Usage is implied by the 'location' scope, but no explicit alternatives or when-not guidance is provided.

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

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

Annotations already indicate this is a mutating, non-destructive, idempotent operation. The description adds the constraint that only the AdminRole can be updated, which is a useful behavioral detail beyond the annotations. However, it does not disclose auth requirements, side effects, or response behavior, so it only partially covers the behavioral envelope.

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 sentence, easy to parse, and free of fluff. It includes the raw HTTP path prefix 'PATCH v1/{+name}', which is not actionable for an agent, but the overall structure is concise and front-loaded with the core purpose.

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 tool has 7 parameters, a nested body, and no output schema, yet the description is very brief. However, the schema provides comprehensive parameter details and annotations cover safety behaviors, so the description is passable but leaves usage context and response expectations unaddressed.

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

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

Schema coverage is 100% with detailed descriptions for all 7 parameters, so the baseline is 3. The description only reiterates that the AdminRole is updatable, which is already stated in the schema's role and updateMask fields, adding no new parameter-level meaning.

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 identifies the tool as an update operation for location admins, specifying the resource (Admin) and the scope (specified location). It distinguishes from create/delete/list siblings through the 'Updates' verb and 'location' qualifier, though it doesn't explicitly mention the account admin equivalent.

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

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

There is no guidance on when to use this tool versus alternatives such as gmb_accounts_locations_admins_create or gmb_accounts_accounts_admins_patch. The description only states what the tool does, with no context, prerequisites, or exclusions.

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 a non-read-only, non-destructive, non-idempotent operation. The description adds valuable behavioral context by specifying owner/manager role requirements and that the transfer is between accounts the same user administers. It does not describe side effects like removal from source, but the annotations and 'Moves' imply this.

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 filler. It front-loads the HTTP method and endpoint, then states the action and conditions in a clear, compact way.

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 transfer action with no output schema, the description covers the core purpose and prerequisites. It lacks explicit return-value details, but the operation is straightforward and the annotations/schema adequately support the agent.

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

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

Schema description coverage is 100%, so the schema already fully documents each parameter. The description adds role context relevant to destinationAccount, but does not provide additional syntax or format details beyond what the schema contains.

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 identifies the action ('Moves a location') and the specific resource (locations transfer between accounts). It explicitly states the source and destination account relationship, which distinguishes it from other location management operations like create, patch, or delete.

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 concrete preconditions: the user must be an owner of the source account and at least a manager of the destination account. This gives clear guidance on when the tool can be used, though it doesn't explicitly mention alternatives or exclusions.

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 valuable behavioral context beyond the annotations by disclosing the duplicate-detection rule: if parent, URI, and place_action_type match a previous request, the request is considered duplicate. It also notes that the created link is returned. This is useful and does not contradict any annotation.

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: two sentences that front-load the action and resource, then add a key behavioral note. There is no waste, and the HTTP method/path prefix is not redundant enough to detract.

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 create operation with a comprehensive schema and annotations, the description covers purpose, return value, and a significant behavioral detail (duplicate handling). It does not describe the exact return shape, but 'returns it' is adequate given no output schema. The schema fills in required fields, so the description is reasonably complete.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters, including their descriptions and required status. The description only references three fields (parent, uri, place_action_type) in the duplicate-detection context, which is more behavioral than parameter-level semantics, so it adds little beyond the baseline.

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

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

The description clearly states the specific action ('Creates a place action link') and the target resource ('associated with the specified location'), distinguishing it from sibling CRUD operations like delete/get/list/patch. It also mentions the return value, 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?

The usage context is implied (use when you need to create a place action link), but the description does not explicitly contrast this with alternatives such as patch or delete, nor does it provide when-not-to-use guidance. There are no exclusions or alternative tool references, so it lacks the richer guidance of a score 4.

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, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds the HTTP method and the specific resource pattern, but does not disclose additional behavioral details such as error handling, permanence of deletion, or side effects. Given annotation coverage, the additional value is modest.

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, concise sentence that front-loads the HTTP method and action ('DELETE'), immediately stating what the tool does. There is no redundant information or filler, making it maximally efficient.

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

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

For a simple delete operation with a well-covered schema and annotations indicating destructive and idempotent behavior, the description provides enough context to understand the tool's purpose. It is slightly less complete because it doesn't mention any post-deletion effects or authorization requirements, but the annotations compensate, so it's adequate.

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 provides descriptions for all 5 parameters (100% coverage), including the meaning of 'name' as the resource name to remove. The description's mention of 'v1/{+name}' confirms the template but adds little semantic value beyond the schema, so the baseline of 3 is appropriate.

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

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

The description clearly states the verb 'Deletes' and the resource 'place action link from the specified location', making it unmistakable what this tool does. It also includes the HTTP DELETE method and path template, which distinguishes it from sibling tools like create, get, list, and patch for the same resource.

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 usage context is implied by the word 'Deletes' and the resource name pattern, but the description does not explicitly state when to use this tool over alternatives or mention any exclusions. There is no explicit guidance on prerequisites or scenarios where this should not be used, so it falls short of clear usage direction.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds no additional behavioral context such as authentication needs, rate limits, or response shape, providing no value beyond what annotations already convey.

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 sentence with no filler, repeating the endpoint template and a succinct action statement. It is front-loaded with the HTTP method and resource, achieving maximum 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?

The tool is a simple read operation with annotations covering safety and schema covering parameters. However, the description lacks any domain context about what a place action link is, leaving the purpose somewhat abstract for agents unfamiliar with the concept.

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 does not supplement any parameter information; it does not explain the name pattern or the fields parameter beyond what the schema provides.

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

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

The description clearly states the tool's action ('Gets') and resource ('place action link'), making it unambiguous. It distinguishes itself from sibling tools like create/delete/patch by indicating a fetch 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 implies usage: use this tool when you need to fetch a specific place action link by name. However, it does not explicitly state when not to use it or mention alternatives (e.g., the list tool for enumerating links), so it relies on inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds only the HTTP method 'GET' and endpoint, not extra behavioral details like pagination or filtering behavior. This is adequate but adds little beyond 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 a single, front-loaded sentence. It states the HTTP verb and resource first, then the operation. There is no wasted words or redundant qualification.

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

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

For a simple read-only list operation with full schema coverage and robust annotations, the description is essentially complete. It does not mention pagination or filtering explicitly, but those are documented in the schema. The lack of an output schema is offset by the verb 'Lists' implying a list response.

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?

All 8 parameters have descriptive schemas (100% coverage), so the schema does the heavy lifting. The description mentions 'the specified location' which maps to the required 'parent' parameter, but adds no additional parameter meaning beyond what the schema already provides.

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

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

The description clearly states the action ('Lists'), the resource ('place action links'), and the scope ('for the specified location'). This distinguishes it from sibling tools like get/delete/patch on the same resource, and from the create action.

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 that this tool lists all place action links for a given location, as opposed to retrieving a single link (get) or mutating them. However, it does not explicitly name alternatives or state when-not-to-use, so it stops short of a 5.

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

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

Annotations already indicate this is a non-read-only, idempotent, non-destructive operation. The description adds only that the updated link is returned, but fails to disclose potential failures like the ALREADY_EXISTS error when a link with the same uri and place_action_type already exists, or that marking a link as preferred can unset another link's preference.

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 and front-loaded: 'PATCH v1/{+name}. Updates the specified place action link and returns it.' The only minor redundancy is repeating the 'PATCH' from the tool name, but overall it is brief and to the point.

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 mutation with 7 parameters, a nested body, and no output schema, the description is insufficient. It does not mention that updateMask is required, that only certain fields are editable, or the ALREADY_EXISTS error condition. The schema carries the detail, but the description leaves high-level semantics unclear.

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 adds no parameter information, but the schema thoroughly documents each field, including the required updateMask and its semantics. The description itself does not compensate further, but it does not need to given the schema's completeness.

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 'Updates the specified place action link and returns it', identifying both the verb (updates) and the resource (place action link). This distinguishes it from sibling tools like create, delete, get, and list, though it does not explicitly call out those alternatives.

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 no guidance on when to use this tool versus the create/delete/list siblings, nor does it mention the required updateMask parameter or that only specific fields (uri, place_action_type, is_preferred) are editable. The intended use is only implied by the word 'updates'.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that the list is scoped to a location or country, but it does not disclose pagination behavior or response structure. This is acceptable but adds limited context beyond 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 sentence that front-loads the HTTP verb and resource, with no filler or redundant information. It is concise and clean.

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 tool has a fully documented schema and strong read-only annotations, so the description covers the core purpose effectively. However, it omits mention of pagination/filtering options, which are important for larger result sets, and since there is no output schema it does not describe the response shape in detail.

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?

All 8 parameters have detailed descriptions in the schema (100% coverage), so the description adds no new parameter-level meaning. The mention of location/country mirrors the existing filter parameter documentation.

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 verb and resource: it returns the list of available place action types for a location or country. This distinguishes it from sibling tools like gmb_actions_locations_placeactionlinks_list, which handle place action links rather than metadata.

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 implies the tool is used to fetch place action type metadata but does not explicitly state when to use it over alternatives or mention any exclusions. Context is provided but not explicit usage 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 this as a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds the context that the location is 'owned by the logged in user,' which is useful. However, it does not disclose other behavioral traits such as validation behavior, response format, or side effects beyond the schema's validateOnly parameter. Given the annotations cover the core safety profile, a score of 3 is appropriate.

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 short sentences, front-loaded with the HTTP method and path, and immediately states the purpose. There is no filler or redundancy. It earns its place by providing the endpoint and the ownership detail without unnecessary elaboration.

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 the rich schema and annotations, the description is very short and fails to provide context beyond the basic action. There is no output schema, so the description should at least mention what is returned (the created Location), which it does not. It also lacks guidance on validation behavior (though validateOnly is in the schema) and any error scenarios. For a complex tool with 8 parameters and nested objects, the description is insufficiently complete.

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

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

Schema description coverage is 100%, with detailed descriptions for every parameter including 'parent', 'body', and 'validateOnly'. The tool description itself adds no parameter-level semantics, so it does not exceed the baseline of 3 for high schema coverage. The extensive schema carries the weight here.

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 clear action: 'Creates a new Location' with a specific verb and resource. It also explicitly notes ownership by the logged-in user, distinguishing it from other create tools for admins, action links, or media. The resource is unambiguous in both the tool name and description.

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 implies usage (create a location) but provides no explicit guidance on when to choose this tool over alternatives or any exclusions. It does not mention prerequisites, required permissions, or scenarios where another tool might be more appropriate. This is implied usage, matching a score of 3.

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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. However, the description adds no extra behavioral context such as pagination, filtering behavior, or wildcard account handling. The 'GET' method and 'Lists the locations' are nearly redundant with the tool name and schema, offering minimal additional transparency.

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 extremely concise, using only two short sentences with no wasted words. It front-loads the HTTP method and endpoint, then states the purpose. While slightly redundant with the tool name, it remains efficient and readable.

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 tool has 10 parameters and no output schema, yet the description only states the basic list action. It does not mention pagination, filters, sorting, or the response structure, leaving the agent to rely entirely on the schema. For a moderately complex list API, this is insufficiently complete.

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

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

Schema description coverage is 100% (all 10 parameters have descriptions). The description adds no parameter-specific meaning beyond 'specified account,' which already exists in the parent parameter description. The schema carries the full burden, so a baseline 3 is appropriate.

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

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

The description clearly states the action (Lists) and the specific resource (locations for the specified account). It distinctly identifies the tool's purpose among many sibling list tools (e.g., localposts, media, reviews) by using the resource name 'locations'.

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

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

No usage guidance is provided. The description does not mention when to use this list operation versus other location-related tools (e.g., get, patch), nor does it describe preconditions or alternatives. It is a restatement of the function without contextual direction.

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 the operation as read-only, idempotent, and non-destructive, which covers the safety profile. The description adds useful context that the returned attributes are those 'would be available' for a given category and country, but it does not disclose behavior like pagination or how parent/showAll modes affect results. This aligns with the calibrated baseline for annotation-rich descriptions.

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 short clauses, front-loaded with the HTTP method and endpoint, and directly states the function. Every word earns its place, with no redundancy or filler.

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

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

The description adequately covers the core use case (category + country) but omits mention of alternative lookup modes like parent or showAll, which are significant features documented in the schema. Since the schema is comprehensive and annotations are strong, the description is mostly complete but could be enriched by noting these alternative modes.

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 all 11 parameters are already documented in the input schema. The description does not add parameter-specific meaning beyond what the schema provides. Per the rubric, a baseline of 3 is appropriate when the schema carries the full burden.

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

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

The description clearly states the tool returns a list of attributes for a location given a primary category and country, using a specific verb ('Returns') and resource ('v1/attributes'). It effectively distinguishes from sibling tools like gmb_info_locations_getattributes by emphasizing categorical/country-based availability rather than location-specific 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?

No explicit guidance is provided on when to use this tool versus alternatives, nor any prerequisites or exclusions. The description merely states what it does, leaving the agent to infer usage from the name and schema. Given similar sibling tools exist, explicit differentiation would be valuable.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds only input constraints (language, GConcept IDs) and does not disclose additional behaviors like pagination or response format. Given the annotations, this is adequate.

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 concise sentence, front-loaded with the HTTP method and endpoint, and every word adds value. No wasted content.

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

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

Despite good annotations and full schema coverage, the description does not clarify which of the 8 parameters are required (schema descriptions mark some as 'Required' but the required array is empty). It also does not mention alternative tools or when to use this over list. This leaves ambiguity for an agent invoking a batchGet with many parameters.

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 merely restates 'language and GConcept ids' which are already fully documented in the schema for languageCode and names. No additional parameter semantics are provided.

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 returns a list of business categories for given language and GConcept IDs, with a specific verb ('Returns') and resource. It does not explicitly distinguish from the sibling gmb_info_categories_list, but the batchGet-with-IDs scope is evident.

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 implies usage when language and GConcept IDs are available, but it does not explicitly mention alternatives (e.g., gmb_info_categories_list) or state when not to use this tool. This is implied rather than explicit guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering safety. The description adds valuable behavioral nuance beyond annotations: search matches category name but not ID, and only matches the front of the name. This detail is crucial for correct invocation and is not present in the structured 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 composed of four short, front-loaded sentences with zero redundancy. It starts with the HTTP endpoint, then states the purpose, and then gives two concise examples of search behavior. Every sentence earns its place, making it highly efficient.

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

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

For a listing tool with rich annotations and a fully described schema, the description adequately sets expectations. It covers the core purpose and the key search nuance. Although no output schema exists, 'Returns a list of business categories' is sufficient for an agent to understand the return type. Pagination and parameter requirements are already captured in the schema.

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

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

Schema description coverage is 100% for all 10 parameters, so baseline is 3. The description adds meaningful semantics about the filter/search behavior (prefix matching on displayName), which goes beyond the schema's generic filter description. This extra context directly improves understanding of the filter parameter.

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

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

The description clearly states the tool returns a list of business categories via GET v1/categories, and further specifies search matching behavior. This differentiates it from other GMB info tools, such as batchget or attributes list, by focusing on the listing and searchable nature of categories.

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 implies usage for searching/filtering categories by name prefix, but does not explicitly state when to use this instead of alternatives like gmb_info_categories_batchget. No exclusions or alternative tools are mentioned, leaving usage context partially implicit.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the error condition (`NOT_FOUND` for non-existent chains) and the HTTP method (`GET`), which are useful behavioral details beyond what annotations provide. This is meaningful but not overly rich, hence a 4.

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 one sentence plus a concise error note. It is front-loaded with the action and resource, and every word earns its place. No unnecessary filler.

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

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

For a simple get operation with no output schema, the description covers the primary behavior and error condition. While it doesn't describe the returned chain structure, the annotations (read-only, idempotent, open-world) and the sibling set (e.g., search vs. get) make the context sufficient. A 4 reflects that it is complete for typical use but not exhaustive.

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%, with all parameters (name, fields, quotaUser, etc.) already described in the input schema. The tool description adds no additional parameter-level semantics. Per the baseline for high schema coverage, this is a 3.

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 ('Gets') and the resource ('the specified chain'). It also specifies the error behavior (`NOT_FOUND`), which helps distinguish it from sibling tools like `gmb_info_chains_search`. The verb+resource combination is specific and 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?

The description makes it clear that this tool is for retrieving a single chain by its resource name. It does not explicitly discuss when to use this instead of `search`, but the context is straightforward: use it when you have a specific chain name. It lacks explicit exclusions or alternative guidance, so it earns a 4 rather than a 5.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, establishing the safety profile. The description adds the behavioral detail that searches are based on chain name, which is a slight addition beyond annotations. However, it does not explain fuzzy/partial matching or pagination behavior, which are left to the schema.

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

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

The description is a single, front-loaded sentence that conveys the essential operation without verbose wording. It is concise and to the point, with no filler or redundancy.

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

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

The description does not mention what the response contains (e.g., a list of matching chains), nor does it indicate that chainName is required. The schema's chainName property notes 'Required,' but the top-level schema shows zero required parameters, creating ambiguity. With no output schema and minimal description, an agent may not understand the expected result format or mandatory inputs.

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 fully documented in the schema. The description adds no extra parameter information beyond restating the chainName criterion. Baseline 3 is appropriate given the schema's comprehensive coverage.

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 operation: 'Searches the chain based on chain name.' This specifies the verb ('searches') and the resource ('chain'). It is distinct from sibling tools like gmb_info_chains_get, though not explicitly contrasting them; the search vs. get distinction is implied.

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

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of exclusions, prerequisites, or alternative tools (e.g., gmb_info_chains_get) to consider. The only implied usage is searching by chain name, but no context about ideal scenarios or limitations.

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 contradicts the annotations. It describes a 'search' operation, which implies read-only behavior, yet readOnlyHint is false (not read-only). No additional behavioral context is provided beyond this contradiction, such as whether the operation has side effects or requires special permissions.

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 sentence that front-loads the endpoint and gives a concise purpose. It is efficient and easy to parse, but it lacks additional structural elements such as examples or caveats that would make it more informative.

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?

Although the schema is rich and covers parameters well, the description is minimal given the tool's complexity (nested Location object, multiple queried params, no output schema). It does not explain what constitutes a 'match' or the trade-off between query and location inputs. The contradiction with annotations further undermines completeness.

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 has 100% parameter description coverage, so the baseline is 3. The description does not add any meaning beyond the schema; it references 'the specified request' without elaborating on query versus location parameters, pageSize limits, or the absence of pagination (which the schema already documents).

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

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

The description clearly states the tool's purpose: it searches for locations matching a request, and the endpoint is included (POST v1/googleLocations:search). It is specific about the action (search) and resource (googleLocations), but does not explicitly distinguish it from sibling search/list tools such as gmb_info_locations_list or gmb_info_chains_search.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention context, exclusions, or scenarios where a different search tool might be more appropriate. The only hint is the endpoint and generic 'search all possible locations', leaving the agent to infer usage.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, providing the safety profile. The description adds valuable context about the data source (Google or user-generated content) and the potential difference from the merchant's version, which goes beyond the annotations without contradicting them.

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, consisting of two short sentences that include the HTTP method and endpoint example for clarity. Every sentence adds meaningful information without redundancy or 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?

With no output schema, the description explains the return value (attributes as live on Google). It conveys the key distinction from the merchant's version, which is crucial for correct use. While it doesn't discuss response structure or pagination, these are not essential for a simple read-only tool.

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

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

The schema descriptions cover 100% of parameters, including name, fields, and standard query parameters. The description does not add any parameter-specific semantics, so the baseline of 3 is appropriate; it does not compensate or add beyond 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 retrieves live consumer-facing attributes for a location, with the specific verb 'Retrieves' and resource 'attributes for a location'. It distinguishes itself from the merchant's version (e.g., getattributes) by noting the consumer-facing view may differ from the merchant's version.

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 that this tool is for the live Google Maps/Search view, implying when it should be used. However, it does not explicitly name alternative tools or state when not to use it, lacking an explicit exclusion or alternative reference.

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 and idempotent behavior. The description adds useful context that some locations cannot be deleted via API and provides a fallback, but does not detail consequences like irreversibility or response behavior. 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 two concise sentences that efficiently state the action and the fallback. No filler or redundant content.

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

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

The tool has no output schema, but the description covers the core behavior and a key failure mode. Standard query parameters are documented in the schema. The description is sufficient for a delete operation, though it could mention the permanent nature explicitly (already implied by annotations).

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

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

Schema coverage is 100%, with all parameters described. The description does not add additional semantics beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description states 'Deletes a location' with a specific verb and resource, clearly identifying the tool's function. It also distinguishes from sibling delete tools by specifying 'location' rather than other resource types.

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 fallback: if the location cannot be deleted via the API and is marked in LocationState, use the Google Business Profile website. This gives contextual guidance on when not to use the API, though it doesn't explicitly compare with alternative delete tools.

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

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

Annotations already declare readOnly, idempotent, and non-destructive hints. The description adds valuable context about data source and freshness ('as last set by the merchant', 'may not reflect updates from Google or user-generated content'), which is beyond the annotations and sets accurate expectations for the response.

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 sentence preceded by the HTTP method, which is somewhat redundant but not padding. The caveat about Google updates is essential and earns its place. There is zero waste and information 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 simple GET-by-name operation with a rich schema and detailed annotations, the description is adequate. It clearly states what is returned and provides a key limitation. Without an output schema, it could mention the response format, but the low complexity makes the description sufficiently complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-specific semantics; it only echoes the 'name' path parameter already described in the schema as 'The name of the location to fetch' and adds no additional meaning for fields, readMask, or other parameters.

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

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

The description clearly states 'Returns the specified location as last set by the merchant', providing a specific verb and resource. It also distinguishes this tool from siblings like getgoogleupdated by emphasizing the merchant-set viewpoint, making its purpose distinct.

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 says the returned data may not reflect Google or user-generated content, giving a clear when-not-to-use condition. It also implies when to use it: when you need the merchant's last set version. This provides explicit usage guidance even without naming 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable context about the data source (merchant-set) and its potential staleness regarding Google/user-generated updates. This goes beyond the annotations by clarifying the specific semantics of the returned data, though the openWorldHint already hinted at external changes.

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 concise sentences, with the main action front-loaded and the caveat in one clarifying sentence. Every word earns its place; there is no fluff or repetition of schema information.

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

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

For a simple read-only tool with strong annotations and no output schema, the description is complete: it explains what the tool retrieves, the caveat about data freshness, and implicitly differentiates from sibling tools. The absence of return-structure details is acceptable given the simplicity and lack of 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?

All 5 parameters have descriptions in the schema, achieving 100% schema_description_coverage. The description does not add any parameter-level details beyond what is already in the schema. Per the rubric, the baseline for high coverage is 3, and the description provides no additional semantic value.

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 function: 'Retrieves attributes for a location as last set by the merchant.' It specifies the verb (GET), resource (attributes for a location), and scope (merchant-set, not live Google data). This distinguishes it from sibling tools like gmb_info_locations_attributes_getgoogleupdated, which presumably fetches Google-updated attributes.

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 implicit usage context by noting the data is 'as last set by the merchant' and 'may not reflect updates from Google or user-generated content.' This suggests that for live Google-updated attributes, the agent should look at alternative tools (e.g., the getgoogleupdated sibling). However, it does not explicitly name an alternative tool, so it falls short of full when/when-not guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context: the returned data may differ from the merchant's version and includes masks indicating differing fields. This goes beyond the annotation baseline, though it doesn't cover error cases or pagination.

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 that immediately state the verb and resource, then add meaningful context about the response nature. No filler or redundant information beyond the API path, which is acceptable.

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

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

With rich annotations (readOnly, idempotent, non-destructive) and a 100% schema coverage, the description adequately completes the picture by explaining the response's key feature (masks indicating differences). It doesn't detail pagination or error behavior, but for a single-resource GET this is 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?

Schema description coverage is 100%, with all six parameters already described (e.g., `name` as 'Required. The name of the location to fetch'). The tool description adds no parameter-specific meaning beyond the schema, so the baseline of 3 applies.

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

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

The description clearly states a specific verb ('Returns') and resource ('the specified location as it appears live on Google Maps and Search'). It distinguishes this tool from sibling `gmb_info_locations_get` by emphasizing the 'consumer-facing view' that may differ from the merchant's version.

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 that this tool returns the live consumer-facing view rather than the merchant's version, implying use when the live Google view is needed. It doesn't explicitly name alternatives like `gmb_info_locations_get`, but the differentiation is evident.

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 only says 'Updates', which is consistent with annotations (readOnlyHint=false), but it adds no extra behavioral context such as the requirement for updateMask, the use of validateOnly for validation-only requests, or the partial-update semantics of PATCH. Annotations already imply a write operation, so the description adds minimal value.

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 and front-loaded with the HTTP method and resource, but it is too sparse for the complexity of the tool. It has no wasted words, yet lacks the detail needed for effective agent decision-making.

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?

This is a complex tool with 8 parameters and nested objects, and no output schema. The description fails to mention critical details like the required updateMask parameter, the validateOnly option, or what the response contains, making it completely inadequate for the tool's complexity.

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

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

Schema description coverage is 100%, and the input schema thoroughly documents all parameters including the required updateMask. The description itself adds no information about parameters, so the baseline of 3 applies.

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

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

The description clearly states the tool updates a specified location, using a specific verb (PATCH) and resource (location). This distinguishes it from sibling tools like gmb_info_locations_get and gmb_info_locations_delete, 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?

The description provides no guidance on when to use this tool versus alternatives, no exclusions, and no mention of preconditions or parameters like updateMask. It merely states the action without 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?

The description simply restates the operation name and adds the HTTP method. Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description contributes no additional behavioral context such as the requirement for attributeMask, partial update semantics, or deletion behavior, which are covered only in the schema.

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

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

The description is extremely short but front-loaded. However, it is under-sized for the complexity of the tool; a one-liner omits critical usage details like the role of attributeMask. While there is no wasted wording, the brevity is not appropriately sized for this operation.

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 tool has 7 parameters, nested objects, and complex mask-based update logic, yet the description provides only the most basic idea. It fails to mention partial update behavior, required fields, or how to delete attributes. Since there is no output schema, the description should provide more context for correct invocation, but it does not.

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 provides 100% coverage with detailed descriptions for all parameters (e.g., attributeMask includes extensive update/delete logic). The description adds no parameter information, so baseline 3 is appropriate since the schema fully compensates.

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 a specific verb ('Update') and resource ('attributes for a given location'), making it distinct from sibling tools like gmb_info_locations_getattributes (read) and gmb_info_locations_patch (update location details). The restatement is precise and 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?

No guidance is provided on when to use this tool versus alternatives. It does not mention related tools, prerequisites, or scenarios where this tool is appropriate. Given the number of sibling update tools, this lack of differentiation is a significant gap.

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 the tool as read-only, idempotent, open-world, and non-destructive. The description adds no extra behavioral context beyond repeating the HTTP method; however, annotations cover the safety profile, so a baseline score of 3 is appropriate.

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, concise sentence that front-loads the HTTP method and purpose. No unnecessary words or redundant information.

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

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

For a simple read-only GET with comprehensive schema descriptions and annotations, the description is adequate. It explains the core function, and the schema covers parameter usage. The lack of return-shape or typical output details is a minor gap given the tool's 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?

The input schema provides full descriptions for all parameters (100% coverage), so the description itself adds no additional parameter semantics. Per calibration, when schema coverage is high, the baseline is 3.

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: it performs a GET to return the Lodging of a specific location. The verb 'Returns' and the resource 'Lodging of a specific location' are explicit, and the tool is easily distinguished from siblings like 'updatelodging' and 'getgoogleupdated'.

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

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

No guidance is provided on when to use this tool versus alternatives, such as 'getgoogleupdated' for fetching updated lodging data. The description lacks any context for selection or exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint false, covering the safety profile. The description adds minimal context by specifying 'Google updated', but does not describe response format, pagination, or field selection behavior. 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 concise sentence, front-loaded with the HTTP verb and endpoint. Every word is meaningful, with no redundancy or filler.

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

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

Despite no output schema, the description states it returns the Lodging resource, which provides a basic understanding. However, it lacks differentiation from sibling tools and does not describe the structure of the response or the meaning of 'Google updated'. The comprehensive annotations and full schema coverage prevent this from being a worse score, but more context would improve completeness.

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 descriptions cover 100% of parameters, including the required 'name' and optional 'readMask' and 'fields'. The description adds no extra parameter semantics beyond what the schema provides, so the baseline of 3 applies.

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

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

The description clearly states the tool returns the Google updated Lodging for a specific location, using a specific verb and resource. The 'Google updated' qualifier distinguishes it from the sibling 'getlodging' tool, though not explicitly.

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

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

The description provides no guidance on when to use this tool versus alternatives like gmb_lodging_locations_getlodging. There is no mention of use cases, exclusions, or selection criteria, leaving the agent to infer usage from the name alone.

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

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

The description adds no behavioral context beyond stating 'updates.' Annotations already indicate readOnlyHint=false and idempotentHint=true, so the mutation nature is known, but the description does not disclose that updates are partial (updateMask controlled), what happens to unspecified fields, or any side effects. With annotations present, the description should still add value; it does not.

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, front-loaded sentence that immediately identifies the HTTP method and resource. It is concise and free of filler, achieving its purpose with minimal word count.

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 the complex schema with many nested objects and the absence of an output schema, the description is minimal and does not explain update semantics, response format, or the critical role of updateMask. The schema covers parameters, but the tool's behavior and return value remain unexplained, leaving the agent with significant 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 description coverage is 100%, so the baseline is 3. The description itself provides no parameter information, but the schema includes detailed descriptions for each field, including the updateMask parameter. No additional semantics are added beyond the schema, so the middle score 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 clearly states the action (PATCH/update) and the resource (Lodging of a specific location). It distinguishes from read-only lodging tools like getlodging, but does not elaborate on scope beyond the resource name. A solid, specific statement, though not as rich as the high benchmark.

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

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, when to prefer updating over reading, or when a different update tool (e.g., locations_patch) should be used. The description simply states what it does, leaving the agent to infer 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the HTTP GET method and the fact that it returns settings, but it does not disclose any additional behavioral details such as pagination or error handling. With annotations present, the added value is moderate.

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 concise sentence that is front-loaded with the HTTP method and resource. It contains no unnecessary words and is well-structured for quick scanning.

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 tool with full schema annotations and no output schema, the description adequately conveys the primary return value ('pubsub notification settings'). It could possibly mention the resource name pattern, but that is fully documented in the schema. Overall, it is complete enough for an agent to understand the tool's purpose and invocation.

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%, with all 5 parameters fully described in the input schema. The description does not add any parameter-level meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool returns pubsub notification settings for an account, using a specific verb ('Returns') and a specific resource. This distinguishes it from sibling tools like gmb_notifications_accounts_updatenotificationsetting, which updates the same settings.

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 implies this is the read/get operation for notification settings, and the context is clear given the HTTP GET method and the resource type. However, it does not explicitly mention when not to use it or name alternatives, though the sibling update tool is somewhat self-evident.

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 convey readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds valuable transparency about the singleton resource, the one-topic limit, and the delete-by-empty-list behavior, which goes beyond the annotations and helps the agent predict side effects. It does not cover rate limits or authorization details, but the schema's pubsubTopic parameter mentions the required permissions.

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 long, starts with the HTTP method, and every sentence provides actionable information. There is no filler or repetition of schema details. It efficiently covers purpose, manipulation, constraints, and deletion semantics.

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 complexity (7 parameters, nested body, no output schema), the description covers the core workflow well: setting, manipulating, and deleting the notification setting. It does not describe the response shape, but for an update operation that is often not critical. The absence of an output schema and the presence of a sibling get tool make this acceptable.

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 semantic context by explaining the relationship between notification_types and the pubsub topic, and clarifies that an empty array deletes the setting. This goes beyond the raw schema descriptions and helps the agent understand how parameters interact.

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 function: 'Sets the pubsub notification setting for the account informing Google which topic to send pubsub notifications for.' It uses a specific verb ('Sets') and resource ('pubsub notification setting'), and the PATCH method is indicated upfront. This distinguishes it clearly from the sibling get tool.

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 practical usage guidance: 'Use the notification_types field within notification_setting to manipulate the events an account wants to subscribe to' and explains the singleton nature ('only one notification setting resource'). It also explains how to delete by updating with an empty notification_types. However, it doesn't explicitly contrast with the get tool or list when not to use it, so a small gap remains.

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 behavior. The description adds the important limitation that hourly metrics are not supported, and the example request clarifies the URL structure. This goes beyond annotations without contradicting them.

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 reasonably concise, front-loads the purpose, and includes a practical example. The URL in the example is long but serves as a concrete illustration. No unnecessary filler.

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

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

Despite no output schema, the description adequately states what is returned (values per date) and key constraints (daily only). With 12 parameters, the schema and example cover usage. Some details about response format are missing but not critical given the clarity of the purpose.

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's example request adds value by showing how to specify multiple dailyMetrics and construct the date range, which helps parameter usage.

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 returns daily metric values for each date in a given time range. The verb 'Returns' and resource 'daily metrics time series' are specific. However, it does not differentiate from the similar sibling tool 'gmb_performance_locations_getdailymetricstimeseries'.

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 no guidance on when to use this tool versus alternatives. It notes that only daily data is available, which is a constraint rather than usage guidance. No alternative tools or scenarios are mentioned.

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

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

The annotations already indicate a safe, read-only, idempotent operation. The description adds meaningful behavioral context beyond annotations: it clarifies that only daily data is supported (hourly is not) and that the return is per-date values. It also includes an example request illustrating required parameters, which provides practical operational insight not present in 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 starts with the redundant HTTP endpoint 'GET v1/{+name}:getDailyMetricsTimeSeries' which repeats the tool name, and includes a long example URL that could be summarized. While the core explanation is only two sentences, the example is verbose and somewhat repetitive. It is not poorly structured but contains unnecessary duplication, earning a 3.

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 has 17 parameters but full schema descriptions, the description plus schema is largely sufficient for selection and basic invocation. The description explains the daily-only limitation and gives an example request, which covers key usage details. Minor gaps include lack of response format details and no reference to the multi-metric sibling, but these are not critical for understanding the tool's function. Overall, it is fairly complete for the complexity involved.

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 has 100% description coverage for all 17 parameters, so the baseline is 3. The description's example request shows how to combine dailyMetric and dailyRange start/end dates, adding a small practical illustration. However, it does not meaningfully enrich the parameter meanings beyond what the schema already provides, so 3 is appropriate.

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

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

The description clearly states the tool returns daily metric values for a given date range using the verb 'Returns' and specifies the resource (daily metrics time series for a location). However, it does not differentiate from the sibling tool gmb_performance_locations_fetchmultidailymetricstimeseries, which also handles time series data. The purpose is clear but lacks sibling differentiation.

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 usage constraint ('Only daily data is available. Hourly metrics are not supported'), implying when this tool should not be used. It does not explicitly mention alternatives or compare to the multi-metric sibling. Guidance is mostly implied rather than explicit, so it earns a 3.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds context that results are aggregated monthly, but does not describe pagination behavior, response format details, or any potential edge cases. This is acceptable but not exceptional.

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 and front-loaded with the endpoint and a clear statement of purpose. The example request is useful but slightly verbose. All sentences contribute value with 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?

Given the complexity (13 params) and no output schema, the description covers the core purpose and provides an illustrative example. It explains what is returned (keywords with monthly impressions). Missing details like pagination or response structure are partially covered by schema and annotations, making it fairly complete.

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

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

Schema description coverage is 100%, so parameters are already well-documented. The description adds no additional parameter semantics beyond the example request for monthlyRange, which is already covered by the schema. Baseline 3 is appropriate per guidelines.

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 returns search keywords used to find a business in search or maps, aggregated monthly. The verb 'Returns' and specific resource ('searchkeywords/impressions/monthly') make it distinct from siblings like getdailymetricstimeseries and fetchmultidailymetricstimeseries.

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 context by describing the monthly aggregation and giving an example request. It implies when to use it (search keyword impressions) but does not explicitly mention alternatives or exclusions. However, the naming and description are sufficient to infer appropriate usage.

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

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

Annotations already mark this as destructive and non-read-only. The description adds meaningful context beyond that: the operation is limited to the current user's answer, the resource is under a question, and the tool is deprecated. This helps the agent understand the exact behavioral scope.

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, front-loaded sentence that includes the deprecation status, HTTP method, resource path, and action. Every word contributes useful information with no redundancy.

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

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

For a simple deletion tool, the description adequately explains what it does and the scope. However, it lacks a recommended replacement for the deprecated functionality, and there is no output schema or mention of expected responses. The annotations cover safety aspects, but the absence of alternative guidance leaves a 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 the schema already describes all parameters. The description does not add extra semantics about the name format or query parameters, but it clarifies that 'name' refers to a question path. This is baseline value; no additional parameter insights are provided.

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 verb 'Deletes', the resource 'the answer written by the current user to a question', and includes the REST method and path. It is immediately distinguishable from sibling tools like list, upsert, and question-level delete, and the deprecated marker adds clarity.

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 no guidance on when to use this tool versus alternatives. It does not mention replacement tools or exclusions, aside from the implicit 'current user' scope. The '[DEPRECATED]' label hints that it should not be used but does not point to an 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?

Annotations already indicate a safe, idempotent, read-only operation. The description adds useful non-obvious behavior: pagination ('paginated list') and deprecation status ('[DEPRECATED]'). It does not contradict annotations. This goes beyond what annotations provide, earning a 4.

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, front-loaded sentence that immediately signals deprecation, then states the HTTP verb, endpoint, and core behavior. No wasted words; every element 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 read-only list operation with full schema coverage and strong annotations, the description is nearly complete. It covers the return type ('paginated list') and required parent context. The only gap is that deprecation is announced without an alternative, reducing completeness slightly.

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 fully documents all 8 parameters with descriptions, achieving 100% coverage. The description does not add parameter details, but the schema already carries that burden. Baseline 3 is appropriate as the description provides no additional semantic value.

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 function: 'Returns the paginated list of answers for a specified question.' It uses a specific verb ('Returns'), identifies the resource ('answers'), and scopes it to a question via the 'parent' parameter. This distinguishes it from sibling tools like question list or answer create/delete.

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 implies usage for fetching answers to a specific question, but it does not explicitly discuss when to use this tool versus alternatives. The [DEPRECATED] tag signals it should likely not be used, yet no replacement tool is mentioned, leaving the agent without clear guidance on 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?

Annotations already indicate readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description adds useful behavioral context: the one-answer-per-question limitation and the fact that the answer is 'written by the user.' It does not contradict annotations and provides meaningful extra detail beyond the structured fields.

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 extremely concise: two short sentences plus the HTTP path. Every piece of information (deprecated, endpoint, action, constraint) earns its place, with no redundant or filler content.

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

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

The tool has 6 parameters and a nested object schema, but no output schema. The description explains the core purpose and a key constraint, but does not mention what the response contains (e.g., the created/updated Answer object) or any auth requirements. For a mutation tool without an output schema, this is a notable gap, though the parameter schema is comprehensive.

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

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

Schema description coverage is 100%, so the parameters are fully documented in the schema. The description does not add significant parameter semantics, but it does tie 'parent' to 'the specified question' and clarifies the answer action. Since the schema carries the load, the baseline of 3 is appropriate.

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

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

The description clearly states a specific action: 'Creates an answer or updates the existing answer written by the user for the specified question.' The verb-resource pairing is explicit, and the constraint 'A user can only create one answer per question' adds specificity. It distinguishes this from sibling tools like gmb_qanda_locations_questions_answers_delete and gmb_qanda_locations_questions_answers_list.

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

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

The description gives clear context for when to use the tool (to write an answer, creating or updating), and the 'one answer per question' rule implies updating an existing answer. However, it does not explicitly state when not to use it or mention alternatives (e.g., to delete an answer use the delete tool). The '[DEPRECATED]' flag provides some caution but no 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?

Annotations already indicate readOnlyHint=false, and the description's 'Adds' and 'POST' align with that write operation. The deprecated status is additional context beyond annotations, but the description does not disclose auth requirements, side effects, or return behavior. No contradiction exists, but the added transparency is minimal.

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 only two short clauses: '[DEPRECATED] POST v1/{+parent}. Adds a question for the specified location.' It is front-loaded with the deprecation warning, followed by a clear purpose. Every word is purposeful, with no redundancy.

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

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

The schema is rich with detailed field descriptions and output-only indicators, but the description does not explain what the response will be (no output schema). It also omits any permissions or prerequisite context. The deprecation note is critical, but overall the description lacks some context an agent would need for confident invocation.

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

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

The input schema has 100% description coverage, including fields like parent (required), body, and output-only properties. The tool description itself adds no parameter details—it does not even mention the required parent or the body object. Baseline score applies because the schema carries the burden.

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

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

The description clearly states 'Adds a question for the specified location,' using a specific verb and resource. It distinguishes from sibling qanda tools (delete, list, patch) by indicating a create operation. The deprecated marker adds useful context without undermining the purpose.

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

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

The deprecation note is the only usage indication, implying the tool should be used with caution or avoided in favor of newer alternatives, but no substitute tool is named. There is no explicit guidance on when to use this create tool versus the list/delete/patch siblings, though the verb 'Adds' implies creation context.

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