google-my-business-mcp

by jie8357IOII

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.0
Disambiguation4/5
Most tools are clearly distinct by resource and action, with verbose hierarchical names. However, the presence of both v1 and v4 versions for similar resources (e.g., gmb_info_locations vs. gmb_v4_accounts_locations) and multiple 'get' variants (get vs. getgoogleupdated) could cause some ambiguity.
Naming Consistency3/5
Tool names generally follow a gmb_<service>_<resource>_<action> pattern with underscores, but there are notable inconsistencies: camelCase action names (fetchMultiDailyMetricsTimeSeries), version prefixes placed differently (gmb_v4_accounts vs. gmb_accounts), and one tool with an auto-generated hash suffix (mo_4ba8b09f).
Tool Count2/5
With 72 tools, this server is far beyond the typical well-scoped MCP server range. The sheer number of endpoints mirrors the full Google Business Profile API, which is too heavy and likely overwhelming for most agent use cases.
Completeness4/5
The tool surface covers a wide range of Google My Business domains: accounts, locations, admins, invitations, actions, notifications, Q&A, media, local posts, reviews, verification, performance, and lodging. Minor gaps exist (e.g., no singular 'get' for admin entities), but the overall lifecycle coverage is strong.
Average 3.7/5 across 72 of 72 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 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.
Usage Guidelines2/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is already covered. However, the description adds no behavioral context beyond the endpoint, such as pagination behavior, ordering, or what is included in the returned media list. It does not contradict the annotations, but it also provides no new useful behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence with a clear endpoint and one-line summary. There is no redundant text or filler; every word serves a purpose. It is appropriately front-loaded with the HTTP method and resource path.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list operation with three parameters and no output schema, the description is too sparse. It does not explain pagination via pageToken, the return format, or when this tool is suitable compared to related operations. The annotations cover safety but not the operational details needed to invoke the tool correctly in various scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for its three parameters, so the description must compensate. The endpoint pattern 'accounts/*/locations/*' gives context for the parent parameter, but pageSize and pageToken are left entirely unexplained. The description does not mention pagination or how these params affect the result, leaving a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists media for a location ('Lists media for a location.'), and the endpoint pattern 'GET v4/{parent=accounts/*/locations/*}/media' provides the resource path. It distinguishes from sibling media_get/media_create but does so implicitly via the word 'list' and the resource scope, so it is clear but not as explicit as the best examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like media_get, media_create, or other list operations (e.g., localposts_list, reviews_list). The description does not mention any prerequisites, exclusions, or conditions under which this tool should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness3/5
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.
Completeness1/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already providing destructiveHint=true, idempotentHint=true, and readOnlyHint=false, the description's "Deletes a local post" adds no behavioral context beyond what is already structured. It doesn't disclose whether deletion is permanent, whether it affects associated data, or whether auth is required. It neither contradicts the annotations nor enriches them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with the REST path front-loaded, followed by a plain-language purpose statement. It is economical and avoids waste, though the 'DELETE v4/' prefix is largely redundant with the tool's name and intent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter delete tool with no output schema, the description covers the essential purpose and parameter pattern, and the annotations handle the behavioral profile. However, it omits context such as what happens on success, whether deletion is reversible, or any caveats about deleting a local post. It is minimally adequate but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the bare 'name' parameter. The path template v4/{name=accounts/*/locations/*/localPosts/*} does add meaning by indicating the expected resource-name pattern for the parameter. However, it doesn't explain the exact string format beyond the wildcard pattern or any constraints on the name value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states "Deletes a local post," which is a specific verb+resource combination that clearly indicates the tool's function. The REST path template (accounts/*/locations/*/localPosts/*) further clarifies the target resource and helps distinguish this from sibling delete tools like gmb_qanda_locations_questions_delete or gmb_accounts_locations_admins_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It simply restates what the tool does without covering when a local post should be deleted, who can perform the deletion, or how this relates to the other localposts tools (create/get/list/patch).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate readOnlyHint=true and destructiveHint=false, so the description's 'Gets' adds no new behavioral information. It does not disclose any side effects, required permissions, rate limits, or response detail. There is no contradiction with annotations, but the description contributes no additional behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences. It front-loads the HTTP method and resource path, then states the operation. No words are wasted, though it could potentially add a brief explanatory clause without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only getter with strong annotations and full schema descriptions, the description covers the essentials. However, it lacks any explanation of what VoiceOfMerchantState is or what conditions apply, which leaves some contextual gap for an agent unfamiliar with the domain. Given the tool's simplicity, this is a reasonable minimal viable description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all 5 parameters including 'name' described as 'Resource name of the location.' The description itself adds no parameter information beyond the schema, so a baseline of 3 is appropriate per the rubric.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Gets the VoiceOfMerchant state' and includes the HTTP GET endpoint. It identifies a specific resource (VoiceOfMerchant state) which distinguishes it from sibling tools like gmb_info_locations_get or gmb_verify_locations_fetchverificationoptions. However, it does not explain what the VoiceOfMerchant state is or when to use it, slightly impacting clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not mention when to use this tool versus alternatives, nor does it specify prerequisites or context such as whether the location must be verified. The agent is given no guidance beyond the basic operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint=false), openWorldHint=true, and non-idempotent. The description adds no extra context about side effects—e.g., that it may send a postcard, email, or SMS—or that a verification token must be obtained beforehand. For a mutation tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently includes the HTTP method and resource name. It is front-loaded and has no filler. However, it is slightly too minimal, omitting useful context that could be added without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex mutation tool with six parameters, nested objects, no output schema, and dependencies on prior API calls (e.g., fetching verification options). The one-line description is insufficient to guide an agent on correct invocation, side effects, or the verification workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: every parameter (name, body, fields, etc.) has a description, including detailed explanations for method, phoneNumber, emailAddress, and others. The tool description itself adds no parameter semantics, but the schema carries the burden, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Starts the verification process for a location' with an explicit HTTP method (POST) and resource pattern (v1/{+name}:verify). This is a specific verb+resource pairing that distinguishes it from sibling tools like 'verifications_complete' or 'fetchverificationoptions', though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 related verification tools. It does not mention prerequisites such as calling FetchVerificationOptions first, nor does it explain that this should be followed by a completion step. There is no exclusionary or alternative tool referencing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the agent understands this is a non-read, non-idempotent mutation. The description adds minimal context beyond this: it says the token is used 'to verify the location'. It does not disclose side effects, token expiry, or that the caller must be an owner/manager (though that is in the schema). Since annotations already provide the safety profile, a score of 3 is appropriate for the small additional value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with only two sentences. The first provides the exact API endpoint, and the second states the core purpose. There is no redundant filler. The only slight deficiency is that the second sentence could be more precise (e.g., specifying 'instant verification token'), but it is still efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is overly minimal for a tool that participates in a multi-step verification workflow. It lacks information about what the token is used for, how it relates to sibling verification tools, and what the response looks like (no output schema). Given the complexity of the API and the presence of several verification-related siblings, the description does not provide enough context for an agent to use it correctly in a broader process.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with detailed descriptions for all parameters (e.g., locationId, fields, quotaUser). The tool description adds no additional parameter semantics beyond what the schema already provides. The phrase 'provided location data' is vague and does not enhance understanding. Baseline 3 is applicable because the schema carries the full burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Generate a token for the provided location data to verify the location.' This distinguishes it from generic operations and gives a specific outcome. However, it does not explicitly differentiate from sibling tools like gmb_verify_locations_verifications_complete or gmb_verify_locations_fetchverificationoptions, which also relate to verification. The verb 'generate' and resource 'verification token' are specific enough to avoid ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 prerequisites (e.g., locationId from an unverified listing) or the relationship to other verification steps. The sibling tools include several verification-related operations, and without any contextual cues, an agent cannot determine when to choose this over gmb_verify_locations_verify or gmb_verify_locations_verifications_complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are 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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's 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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and idempotentHint=false, so the write nature is disclosed. The description adds the HTTP method and path but no additional behavioral context (e.g., visibility of the post, validation rules, or side effects). It does not contradict the annotations, so it meets the baseline but adds little beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the HTTP method and path before stating the action. It is efficient with no filler words, earning a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and the description does not mention the response format or the content of the request body. For a create operation, the agent lacks details about what constitutes a valid local post and what to expect back, making the description incomplete despite the low parameter count.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%; the `parent` parameter is clarified by the REST path template in the description, but the `body` parameter is only described generically as 'JSON request body' with an `x-google-schema-ref` to `LocalPost`, and the description does not explain what fields a local post requires. With 50% coverage, the description should compensate more but only partially does.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Creates' and identifies the resource as 'a local post for a location', with the REST path template `v4/{parent=accounts/*/locations/*}/localPosts`. This clearly distinguishes it from sibling operations like `localposts_list`, `localposts_patch`, and `localposts_delete`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating a new local post but does not explicitly state when to use it versus alternatives (e.g., using `localposts_patch` for updates). No exclusions or alternative tools are mentioned, leaving the agent to infer from the verb and resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds no extra behavioral context (e.g., error handling, auth requirements), but it does not contradict the annotations. Given the annotations, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences: the first gives the HTTP method and path pattern, the second states the function. It is concise and free of fluff, though the first sentence is somewhat redundant with the tool name. Still, it earns its place by conveying the resource format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple get operation with one parameter, annotations that cover safety, and no output schema. The description states the core function and the resource pattern, which is sufficient for a basic read. It lacks details about the return value or error conditions, but for a straightforward get, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no description for the 'name' parameter (0% coverage). The description includes the path template '{name=accounts/*/locations/*/localPosts/*}', which gives some meaning beyond the schema by showing the resource pattern. However, it does not explain what 'name' specifically refers to (e.g., the local post ID), so it only partially compensates for the missing schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Gets') and the resource ('a local post'), and the path template accounts/*/locations/*/localPosts/* distinguishes it from sibling tools like create, delete, and list. This is a specific verb+resource statement with no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention prerequisites, context, or when to prefer this over other local post operations or other get tools. The description provides no usage scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 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.
Usage Guidelines2/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already well-documented. The description'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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior4/5
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.
Conciseness3/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe read operation is known. The description adds no extra behavioral context beyond the API path, aligning with the annotations and providing minimal additional value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence effectively conveys the operation, with no wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple list operation with 3 parameters and no output schema. The description covers the core action and scope, but it does not mention pagination behavior or what the response would contain, and it leaves pageSize/pageToken semantics unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The parent parameter is somewhat explained by the path template 'accounts/*/locations/*', but pageSize and pageToken are not described at all, leaving their roles ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Lists local posts for a location' with a specific verb and resource, distinguishing it clearly from sibling tools like get, create, delete, and patch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The list verb implies when to use the tool, but no explicit guidance on choosing between this and alternative tools (e.g., get for a single post) is provided. It is clear enough for basic usage but lacks explicit exclusions or alternative mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint=false, so the safety profile is clear. The description adds the GET verb and endpoint format, which is consistent with read-only behavior. However, it does not disclose additional behavioral nuances like pagination limits or response ordering, so it adds only minimal context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using only two short sentences. It front-loads the endpoint format and then provides a one-sentence functional summary. 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation, the description covers the core purpose and resource. However, the absence of output schema or parameter descriptions means the agent must infer pagination behavior and response shape. Given the tool's complexity (3 params, no output schema), the description is minimally sufficient but lacks rich context that would improve correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It only clarifies the parent path pattern ('accounts/*/locations/*') but does not explain the purpose of pageSize or pageToken. Since pagination parameters are common but not self-evident to all agents, the lack of compensation is a notable gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Lists reviews for a location.' The verb 'Lists' and resource 'reviews' are specific and unambiguous. It also includes the exact endpoint pattern, distinguishing it from review-related siblings like get, updatereply, and deletereply.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to list reviews for a location, but it does not explicitly mention alternatives or when not to use this tool. It lacks any comparison to reviews_get for single-review retrieval or guidance on pagination, leaving usage context implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only and destructive hints. The description adds valuable context beyond annotations by stating that the operation is deprecated and that only questions written by the current user can be updated, which clarifies authorization scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with the deprecated status front-loaded. It contains no redundant or filler text, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 adequate but does not mention the requirement for updateMask or that only question text can be updated. These details are present in the schema, so the description is not severely incomplete, but it leaves some context implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the input schema thoroughly documents all parameters. The description adds no additional meaning or context about the parameters, so it does not exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Updates' and the resource 'specific question written by the current user'. It distinguishes this patch operation from sibling tools like create, list, and delete by specifying the update action and the user scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided about when to use this tool versus alternatives. It does not mention that this should be used for updating existing questions rather than creating new ones, nor does it suggest an alternative given its deprecated status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a write operation (readOnlyHint=false) and non-destructive behavior (destructiveHint=false). The description adds the behavioral detail that media is created from a source URL (implying a fetch), but does not disclose potential failure modes, required permissions, or side effects. This goes slightly beyond annotations but not richly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the HTTP method and resource path, followed by a clear action statement. Every word adds value; there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a create operation with a complex body (MediaItem object, additionalProperties true) and no output schema. The description covers the core action and source, but omits any indication of the response format, required fields beyond source URL, or possible asynchronous behavior. It is minimally complete but leaves important gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a generic description for 'body' and none for 'parent', giving 50% coverage. The description compensates by showing the parent path format (accounts/*/locations/*) and by indicating the body must include a source URL, which adds meaning to the ambiguous 'body' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Creates a media item') and specifies the resource (media under a location), including the exact HTTP method and path template. It distinguishes from sibling media tools by indicating creation specifically, and 'from a source URL' adds a meaningful qualifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives such as media_patch (update) or media_list. There is no mention of prerequisites, alternatives, or exclusion criteria, leaving the agent to infer usage solely from the name and endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true). The description adds the HTTP method (POST) and language-dependence, but doesn't disclose side effects, permission requirements, or rate limits. It 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose and avoids unnecessary verbosity. The endpoint string 'POST v1/{+location}:fetchVerificationOptions' is slightly redundant with the tool name but helps clarify the HTTP method and resource path.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema (100% coverage), annotations, and the tool's relatively straightforward read-like nature, the description is minimally acceptable. However, it doesn't explain what the verification options represent, how they relate to the verification workflow, or what to do with the results. No output schema is present, so a bit more context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented in the schema. The description mentions 'language' and 'location' but these map directly to existing schema fields without adding new meaning. Baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what the tool does: 'Reports all eligible verification options for a location in a specific language.' This clearly identifies the verb (reports), the resource (verification options), and scope (location and language). It also distinguishes itself from sibling tools like gmb_verify_locations_verify (which performs verification) and gmb_verify_locations_getvoiceofmerchantstate (which retrieves verification state).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (to fetch eligible verification options) but does not explicitly mention when not to use it or compare it directly to alternatives. The distinction from sibling tools is implied by the different verbs, but no direct guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's 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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's 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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the agent knows this is a safe read operation. The description adds no additional behavioral context (e.g., return format, error behavior), but it does not contradict annotations. With annotations covering the 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no unnecessary words, making it highly concise and easy to parse. It front-loads the resource path and then states the action clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get operation with one parameter and rich annotations, the description covers the essential behavior. It lacks explicit usage guidance but is otherwise adequate for the tool's simplicity, given that the URL pattern and method convey the core meaning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single 'name' parameter with no description, and schema description coverage is 0%. The description compensates somewhat by providing the path template `{name=accounts/*/locations/*/media/*}`, indicating that the name parameter must be a resource path of that form. However, it does not explain the semantics beyond the template, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Gets a media item' with the specific resource path pattern, making its purpose unambiguous. It distinguishes from siblings like media_create, media_delete, media_list, and media_patch by explicitly describing a get operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit alternatives or exclusions are mentioned. The 'GET' method and resource path imply its use for retrieving a single media item, but the description does not state when to choose this over media_list or provide other context. Usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover destructiveHint=true and idempotentHint=true, so the safety profile is known. The description adds the REST path pattern but no extra behavioral context (e.g., irreversibility, permission needs). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences, front-loaded with the HTTP method and path. Every word is valuable, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter, the description is mostly sufficient. Annotations cover destructive/idempotent behavior, and the resource pattern is given. It lacks explicit mention of return value or prerequisites, but these are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single 'name' parameter with no description (0% coverage), but the description provides the resource name pattern (accounts/*/locations/*/reviews/*), clarifying that 'name' refers to the review resource and '/reply' is the endpoint. This compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes a reply to a review, with a specific resource path pattern (accounts/*/locations/*/reviews/*). This distinguishes it from sibling tools like updatereply (update) and get/list (read).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., a reply must exist) or reference sibling operations like updatereply for modifying a reply.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already well-documented. The description adds 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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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 value by disclosing the deprecation status and the ownership requirement (current user only). It does not elaborate on side effects or authorization, but the annotations cover the core behavioral profile, so 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences) and front-loads the key information. However, the first sentence '[DEPRECATED] DELETE v1/{+name}' largely repeats the tool name and HTTP method, providing marginal value. The second sentence is substantive and concise, but the redundancy prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation, the description combined with rich annotations (destructive, idempotent) and full schema coverage is sufficient. It states the action, resource, ownership constraint, and deprecation. No output schema exists, but a delete tool doesn't need extensive return-value documentation. The lack of explicit prerequisites beyond ownership is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage, with clear descriptions for all parameters including the required 'name' pattern and optional fields like 'fields' and 'quotaUser'. The description adds no additional parameter 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Deletes a specific question written by the current user.' It specifies the resource (question), the operation (delete), and the scope (written by the current user), which distinguishes it from related question tools like create, patch, and list. The sibling list confirms distinct tools for questions, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit when-to-use guidance or alternatives. The '[DEPRECATED]' label implies it should not be used for new integrations, but no replacement tool is named. The 'written by the current user' constraint gives an implicit usage condition but no explicit exclusions or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true, which cover the safety profile. The description adds the behavioral detail of using an update mask, implying partial updates. However, it does not disclose error behavior, authentication needs, or whether the full updated resource is returned. With annotations present, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the HTTP method and path, then states the action. No redundant information or filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides the essential action and path but lacks information about return values (no output schema) and the exact format of the update mask. It also does not mention prerequisites like the local post existing. For a patch operation with no output schema, the description carries more responsibility, and while the path and method are clear, the incomplete parameter details leave gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (33%), with only 'body' having a generic description. The description adds meaning to 'updateMask' by indicating its role, and 'name' is implicitly identified in the path template. 'body' is not explained beyond the schema's generic reference. The description partially compensates for the schema gaps but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Updates a local post using an update mask.' It uses a specific verb ('Updates') and resource ('local post'), and the mention of 'PATCH' and the path template distinguishes it from sibling operations like create, delete, and get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it updates an existing local post via PATCH with an update mask. It does not explicitly mention alternatives or when not to use it, but the verb and method make the intended use apparent. No exclusions or misleading guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds the key detail that updates use an update mask, indicating a partial update. This complements the annotations (readOnlyHint=false, idempotentHint=true) without contradiction, giving useful context beyond the structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with the HTTP method, endpoint, and core action. No superfluous words, fitting the conciseness ideal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While annotations cover safety and idempotency, the description is minimal for a mutation tool: it does not mention what fields can be updated, permissions required, or the format/semantics of the update mask. Given no output schema, this leaves some operational gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, and the description provides no details about the 'name' or 'body' parameters beyond referencing MediaItem. It does clarify 'updateMask' usage via 'using an update mask', partially compensating for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states a specific verb+resource: 'Updates media item metadata'. The endpoint pattern and operation distinguish it from the many sibling media tools (create, delete, get, list). No ambiguity about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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 versus alternatives, nor does it provide exclusions or alternate tool suggestions. The intended use is implied by the wording but not explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 that results are ordered by create time, but does not disclose pagination or other behavioral details beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the HTTP verb, path, and core semantics. Every word contributes value with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple list operation with no output schema, but the description is sparse—it does not mention response format or pagination behavior, though pagination parameters are in the schema. It is minimally complete but leaves some contextual details unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, so the schema already explains each parameter. The description does not add any meaning beyond the schema, meriting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'List' and the resource 'verifications of a location', and even includes the HTTP method and path. It distinguishes from sibling verification tools by focusing on listing rather than verifying or fetching options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when you need to list verifications for a location. While it doesn't explicitly exclude alternatives, the context is unambiguous and the sibling tools perform different actions (verify, fetch options, complete).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's 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.
Usage Guidelines3/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds valuable behavioral context: deprecation, the verified-location requirement, pagination, and that only 'some' answers are included. This goes beyond the structured 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences deliver the core purpose, a deprecation warning, and a precondition. Every word earns its place; front-loading the deprecation status is especially useful for an agent deciding whether to invoke the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a paginated list tool, the description covers the main action, scope, verification precondition, and deprecation. Although there is no output schema, the parameter schema is rich and the description adequately explains the operation's context. Minor gap: it does not note that page size defaults to 10, but that is in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter already fully documented (e.g., pageSize defaults, filter options, orderBy valids). The description adds no parameter-specific details, which is acceptable given the exhaustive schema; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Returns') and clearly identifies the resource ('paginated list of questions and some of its answers for a specified location'). It distinguishes this list operation from sibling create/update/delete tools, and the '[DEPRECATED]' marker adds important context without obscuring the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear prerequisite ('only valid if the specified location is verified') and signals deprecation, but does not mention alternative tools or explicitly state when not to use it. The deprecation implies avoiding new use, yet no replacement is named, leaving the guidance incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, which convey the key safety relevant behavior. The description adds no additional context (e.g., permanence, side effects, or authentication), so it neither contradicts nor enriches the annotation info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that conveys the HTTP method, resource pattern, and action. Every element earns its place, and there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete operation with destructiveHint annotation, the description is mostly complete. It specifies the resource pattern and the action. It could mention irreversibility, but the annotation already signals destructiveness, and no output schema means return format is not a concern.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema has 0% description coverage, the description includes the full path template 'accounts/*/locations/*/media/*', which effectively documents the expected format for the single 'name' parameter. This adds valuable meaning beyond the bare schema type string.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the HTTP method (DELETE) and resource pattern (accounts/*/locations/*/media/*), followed by the action 'Deletes a media item.' This unambiguously identifies the tool's purpose and distinguishes it from sibling tools like media_get, media_list, and media_patch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by saying 'Deletes a media item,' but it does not explicitly state when to use this tool versus other deletion tools (e.g., localposts_delete) or mention any prerequisites like permissions or irreversibility. The intent is clear but guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, covering the safety profile. The description adds the resource hierarchy pattern, which clarifies the scope of the operation. It does not contradict annotations, but also does not disclose additional behavioral traits like permissions or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, front-loaded with the HTTP method and resource pattern. Every word earns its place, and there is no fluff or repetition of schema details. It is appropriately sized for a simple GET operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with rich annotations and a single parameter, the description is adequate for an agent to select and invoke it correctly. It lacks details on return format or error handling, but the lack of an output schema and the simplicity of the operation make this acceptable. The annotation hints (readOnly, idempotent) compensate for missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'name' with no description (0% coverage), but the description explicitly shows the expected path format 'accounts/*/locations/*/reviews/*'. This gives the agent the essential syntactic constraint. It does not elaborate on what the name represents, but the pattern is the core semantic.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation as 'Gets a review' with the full resource pattern 'accounts/*/locations/*/reviews/*'. This distinguishes it from sibling tools like 'reviews_list' (which lists reviews) and 'reviews_updatereply' (which updates a reply). The verb+resource structure is explicit and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: call this tool when you need to fetch a single review by its resource name. However, it provides no explicit guidance on when to prefer this over the sibling 'reviews_list' or other review-related tools. There are no explicit exclusions or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutation (readOnlyHint=false). The description adds the state transition from PENDING to VERIFIED and clarifies AUTO behavior, which is useful. However, it doesn't disclose error conditions, required permissions, or side effects beyond the state change, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the action and use clear code formatting. Every word adds value, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately explains the core purpose and the specific scenario where this tool applies. Given the tool's moderate complexity and the rich schema, it doesn't need to describe return values. The AUTO vs non-AUTO distinction adds necessary context, though it could mention prerequisites like having an existing pending verification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the `pin` field is already described as 'Required. PIN code received by the merchant to complete the verification.' The description adds no additional parameter semantics, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Completes') and the resource ('a PENDING verification'). It also distinguishes this tool from siblings by specifying it's only necessary for non-AUTO verification methods, which differentiates it from the broader verify tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit condition for when to use the tool (non-AUTO verification methods) and when not to (AUTO methods are instantly VERIFIED). This provides clear usability context, though it doesn't explicitly name the alternative tool for initiating verification, leaving some implicit workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, idempotent, non-destructive operation. The description adds the create-or-update semantics, which is a valuable behavioral trait beyond the annotations. It does not detail side effects or error cases, but the combination of annotations and description is adequately transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the method, path pattern, and action. It is front-loaded and every word adds value. No fluff or repetition beyond the path template, which is useful for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides the essential purpose but omits details about the request body contents, required fields, or response behavior (no output schema exists). For a tool with a nested object parameter and no output schema, the description is minimal. However, the path and action are clear enough for an API-saavy user, and sibling tools provide context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%: the 'name' parameter lacks any description, and 'body' only has a generic 'JSON request body' description plus a schema reference. The description's path template clarifies that 'name' is the review resource path, but it offers no detail about the expected body structure or fields. Since coverage is moderate and the tool has nested objects, the description should compensate more but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Creates or updates the reply to a review.' It explicitly includes the HTTP method and path template, making it unambiguous. This distinguishes it from sibling tools like delete reply, get, or list reviews.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the intended action (create or update a reply) without ambiguity. While it does not explicitly name alternatives or exclusions, the sibling list and the 'creates or updates' phrasing are sufficient inference. It lacks explicit 'when not to use' guidance, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's 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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's 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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already well documented. The description adds 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's 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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![google-my-business-mcp MCP server](https://glama.ai/mcp/servers/jie8357IOII/google-my-business-mcp/badges/card.svg)](https://glama.ai/mcp/servers/jie8357IOII/google-my-business-mcp)

Score Badge

Copy to your README.md:

[![google-my-business-mcp MCP server](https://glama.ai/mcp/servers/jie8357IOII/google-my-business-mcp/badges/score.svg)](https://glama.ai/mcp/servers/jie8357IOII/google-my-business-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jie8357IOII/google-my-business-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server