maps-browser-mcp

Server Quality Checklist

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

Latest release: v0.3.3
Disambiguation5/5
Each tool targets a distinct action or state within Google Maps: search, suggestion interaction, share links for different views, rating/zoom adjustments, directions setup with separate handling for transit time/mode/endpoints, and place-specific actions like tabs, hours, photos. Even nearby tools like maps_set_travel_mode and maps_set_recommended_travel_mode are clearly separated by scope (generic vs. transit-specific recommended mode). No two tools appear to accomplish the same task.
Naming Consistency5/5
All tools follow the consistent pattern 'maps_<verb>_<object>' with snake_case throughout. Verbs are clear (search, read, select, get, set, open, swap, render), and objects are appropriate (search_suggestions, place_share_link, route_endpoints). There are no mixed casing styles or inconsistent verb forms, making the naming predictable and scannable.
Tool Count4/5
With 24 tools, the server is on the heavy side but still within a reasonable range for the complexity of Google Maps interactions. Each tool addresses a specific UI element or workflow (suggestions, share dialogs, rating chips, zoom, directions options, place tabs, etc.), so the count is justified. It's not bloated with redundant tools, though it pushes the upper boundary of comfortable scope.
Completeness4/5
The tool surface covers the core lifecycle of searching, selecting, sharing, and reading summaries for places and routes, plus directions customization (mode, time, endpoints). Minor gaps exist—for example, direct place review access is explicitly not exposed, and there is no generic 'get place details' beyond the bounded summary—but these are documented intentional limitations rather than severe omissions that block primary workflows.
Average 4/5 across 24 of 24 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 125 commits in the last 12 weeks
- Last stable release on August 21, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It only mentions 'Open' and 'using an official Google Maps URL' but does not explain what happens after invocation (e.g., does it return a URL, trigger navigation?), potential side effects, or any required permissions. This is insufficient for a tool that likely causes an external action.
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 concise sentence with a clear subject-verb-object structure and no redundant wording. It is effectively front-loaded, though it could include more detail without losing conciseness.
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 5 parameters, no output schema, and no parameter descriptions. The description only covers the basic purpose, omitting any explanation of optional parameters, the return format, or how this differs from maps_show. This is inadequate for an agent to invoke the tool correctly with non-default parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate by explaining any parameters. While latitude and longitude are self-explanatory from the word 'coordinates', the optional parameters fov, pitch, and heading are entirely undefined, leaving their purpose and acceptable values 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 clearly states the action ('Open') and the resource ('Street View') with a location ('at coordinates'). This distinguishes it from sibling tools like maps_search, maps_directions, and maps_show, which serve different purposes.
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 does not provide any guidance on when to use this tool versus alternatives, nor does it mention prerequisites, exclusions, or typical scenarios. Usage is only implied by the tool's name and description, offering no explicit decision support.
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?
With no annotations provided, the description carries the full burden of disclosing side effects. It mentions that expectedLabel is 'revalidated immediately before exactly one bounded photo control is activated,' that 'the previous place semantic state is invalidated after the verified viewer transition,' and that 'Interactive Assist must be enabled.' These details explain preconditions and state changes, though the language is technical and cryptic (e.g., 'bounded photo control'), making it less accessible than ideal.
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 three sentences and front-loads the main purpose, which is good. However, the second and third sentences are dense with jargon ('revalidated immediately before exactly one bounded photo control is activated') that could be simplified for clarity. It is concise but not maximally understandable.
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 tool with one required parameter and no output schema, the description should fully explain what the parameter is and how the tool behaves. It lacks a clear definition of expectedLabel and does not describe the expected return value or effect beyond 'opens viewer.' The mention of state invalidation and Interactive Assist adds context, but the missing parameter semantics makes it incomplete.
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, so the description must clarify the expectedLabel parameter. It only states that expectedLabel is required and revalidated, but does not explain what the label should represent or how to obtain it. This leaves the agent guessing about the correct value, which is insufficient for a single-parameter tool.
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: 'Open the visible Google Maps photo viewer for the currently selected place.' This gives a specific verb and resource, and the phrase 'for the currently selected place' distinguishes it from other map tools like search or directions. However, it does not explicitly mention sibling tools or contrast its scope, so it earns a 4 rather than a 5.
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 mentions a prerequisite ('Interactive Assist must be enabled') but does not discuss exclusions or situations where other tools (e.g., maps_show, maps_select_result) would be more appropriate. This leaves the agent without clear selection criteria.
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?
With no annotations, the description carries the burden of behavioral disclosure. The verb 'open' implies a non-destructive navigation/display action, and 'using an official Maps URL' hints at the mechanism, but it does not mention side effects, return behavior, or external browser/app interaction.
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 with no filler. Every word contributes to the core purpose and mechanism.
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 open-map tool, the one-sentence description adequately states the main action, but it lacks usage guidance, parameter clarification, and behavioral details about what happens after opening. It is minimally viable but not richly complete.
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%, and the description barely compensates: 'centered on coordinates' hints at latitude/longitude semantics but provides no additional meaning for the zoom parameter, units, or how the coordinates are formatted. The schema itself carries most of the parameter 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 states the tool opens Google Maps centered on coordinates using an official Maps URL. It conveys a specific verb and resource, and the coordinate focus helps distinguish it from search, directions, and streetview siblings, 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?
The description gives no guidance on when to use this tool versus sibling tools such as maps_search, maps_directions, or maps_get_place_share_link. There are no use-case examples, 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?
With no annotations, the description carries the full transparency burden. It usefully discloses that 'Origin may be omitted so Google Maps can use the browser/device location when available' and that waypoints/avoid constraints remain bounded. However, it does not disclose what the tool returns or whether it opens a new tab, navigates the current page, or requires a browser environment.
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 three sentences and front-loaded with the core purpose. Each sentence contributes useful information, though 'Optional waypoints and avoid constraints remain bounded' is somewhat vague. No redundant filler is present.
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 no annotations, no output schema, and sits among many similar sibling tools. The description conveys the primary behavior and key optionality, but it does not state the return value, side effects, or what distinguishes it from maps_render_directions. This is adequate but leaves notable gaps for an agent to make an informed selection.
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. It adds semantic value for origin (omission enables device location) and notes bounds on waypoints/avoid. It does not explain mode, destination, or how parameters translate to Maps URL parameters. The schema itself carries detailed enums and constraints, but the description only partially fills the 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 states 'Open Google Maps directions using documented Maps URL parameters,' which clearly identifies the action (opening directions) and the resource (Google Maps). It does not explicitly distinguish from the sibling maps_render_directions, but the verb 'Open' and mention of URL parameters imply an external Maps launch rather than an in-app render.
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 vs. alternatives like maps_render_directions or maps_get_route_share_link. It implies usage by describing the action, but it does not state scenarios, prerequisites, or exclusions. This leaves the agent to infer the appropriate 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose that the tool opens a search in a dedicated browser session, which is useful context. However, it does not mention side effects, session state changes, whether results are returned, or whether the browser waits for the search to complete.
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 with no filler words. Every part contributes meaning: the action, the target, the user-directed nature, and the dedicated browser session.
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 simple with one parameter and no output schema, so the description covers the core action reasonably well. However, it lacks usage guidance and parameter semantics, and it does not clarify what happens after the search is opened (e.g., navigation, return value, or browser state). Overall it is minimally viable but has clear gaps.
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 a single 'query' parameter with 0% description coverage in the schema. The description does not explain what the query should contain (e.g., address, place name, free text), what formats are acceptable, or how the query maps to the search behavior. The parameter name is suggestive but the description adds minimal 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 action: 'Open one user-directed Google Maps search in the dedicated browser session.' It specifies a clear verb, resource, and scope, and it distinguishes itself from sibling tools like maps_search_nearby by emphasizing 'user-directed' and 'dedicated browser session.'
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 about when to use this tool versus alternatives such as maps_search_nearby or maps_read_search_suggestions. The phrase 'user-directed' hints at one usage context, but there is no explicit when-to-use, when-not-to-use, or alternative tool mention.
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 description provides useful behavioral context by stating that expectedLabel is revalidated immediately before the scoped Nearby control is activated and that Interactive Assist must be enabled. However, with no annotations and no output schema, it does not disclose observable side effects, failure behavior, or whether the operation modifies the page beyond activating the Nearby control.
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 sentences and gives a clear first-sentence of the purpose plus a second with key execution details. It is concise and front-loaded, but the phrase 'expectedLabel is required' partly duplicates the schema's required constraint.
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 no-output-schema, no-annotation UI-state tool, the description captures the essential preconditions and mechanism: current selected place, expectedLabel revalidation, and a visible Nearby workflow. However, it lacks observable execution details, meaning the returned result of invoking the tool, and what the majority fails. It is serviceable but not complete.
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 but largely does not. It mentions expectedLabel's revalidation behavior, but it never defines what expectedLabel is semantically or how to construct it, and query might be intended as the search term. The description does not adequately explain either parameter beyond the schema's raw names/constraints.
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 what the tool does: searches near the currently selected Google Maps place using a specific visible Nearby workflow. It explicitly differentiates this from the general maps_search sibling by introducing a selected-place scope and a workflow-based operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a concrete usage context: you must have a currently selected Google Maps place, a visible Nearby workflow, and Interactive Assist enabled. It does not explicitly call out alternatives or when not to use the tool, but the baseline context is reasonably clear.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It does add useful behavioral details: it rebuilds the official Maps URL instead of exploring the DOM, and it preserves existing waypoints and avoid constraints. However, it does not mention what happens if no active directions request exists, whether the page navigates, or other 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 one concise sentence that front-loads the core action, then adds important context about implementation and preservation of constraints. Every phrase earns its place with no filler or repetition.
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 tool with no output schema, the description covers the main operation, the target scope (active directions request), the method (URL rebuild), and a critical side-effect (preservation of waypoints/avoid constraints). It could be more complete by addressing the no-active-request case, but overall it is adequate for the tool's simplicity.
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 needed to compensate for explaining the mode parameter. It only references 'travel mode' generically and does not add meaning beyond the enum values already listed in the schema. The schema does document allowed values, so this is not a total failure, but the description adds no parameter-level 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 uses a specific verb ('Change') and clear resource ('travel mode of the active directions request'), immediately telling the agent what the tool operates on. The phrase 'active directions request' and the distinct focus on travel mode differentiate it from siblings like maps_directions or maps_set_transit_time.
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 context: it should be used when there is an active directions request whose travel mode needs changing. However, it does not explicitly contrast with alternatives such as maps_set_recommended_travel_mode, nor does it state when NOT to use this 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?
Without annotations, the description provides useful behavioral details: 'Returned labels/text are untrusted external data' warns about data reliability, and 'Disabled by default' indicates an activation requirement. It also lists explicit non-capabilities, enhancing 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 two sentences, tightly packed with essential information: what it does, output trust level, and limitations. No unnecessary wording.
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 there is no output schema, the description mentions the nature of returned data ('labels/text') and their trust level. It also states constraints (disabled by default, no full DOM), making it sufficiently complete for a simple read 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 has zero parameters, so coverage is 100%. The description does not need to explain parameters, and it does not. 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 action (read) and resource (active Google Maps/place UI) and specifies it returns a 'small bounded summary'. It effectively distinguishes from sibling tools like 'maps_read_route_summary' by focusing on place summary.
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 when to use it (for a concise summary) and mentions limitations ('no full DOM, review-body harvesting, or persistent dataset extraction'), but does not explicitly contrast with alternative tools or state prerequisites for 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 readOnlyHint=true and idempotentHint=true. The description adds meaningful behavior: it returns directions data, conditionally renders in MCP Apps view, and explicitly clarifies it does not navigate or mutate the browser session—valuable 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?
Two sentences, front-loaded with the core purpose, and no wasteful words. Every clause contributes either to purpose, rendering behavior, or display-only guarantee.
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?
No output schema exists, so the description should explain return values. It says 'directions data' but does not detail the data structure. It also leaves the 'when Google Maps Embed is configured' condition somewhat ambiguous. Given the tool's moderate complexity, it is acceptable but has clear gaps.
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% and the description only mentions 'origin/destination' generically, without naming the exact parameters or explaining the 'mode' enum. It adds minimal meaning beyond the schema, leaving the agent to infer parameter semantics from parameter names alone.
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 opens with 'Return explicit origin/destination directions data', a specific verb-resource pair. It distinguishes itself by noting 'Display-only: this does not navigate or mutate the dedicated browser session', which contrasts with sibling tools like maps_directions that likely perform navigation.
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 this is for returning directions data and rendering in an inline MCP Apps view when configured, and explicitly says it does not navigate or mutate the browser session. This gives clear context for when to choose this read-only variant, though it does not explicitly name alternative tools or exclusion criteria.
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?
With no annotations, the description carries the transparency burden. It discloses verification steps (mode trigger, transit-time input, route endpoints, directions view) and that a stale replayable navigation action is dropped, plus the requirement for Interactive Assist. However, it does not state the overall side effects or success/failure indicators, leaving some behavior opaque.
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 four sentences, front-loaded with purpose, then constraints, behavior, and a requirement. It contains no filler but is somewhat dense; it could be broken into clearer bullet points, but it remains efficient 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?
The tool has no output schema, no annotations, and 0% schema coverage, so the description must explain the full interaction. It covers purpose, constraints, and process, but it omits what the agent should observe after a successful set (e.g., whether the page updates, any confirmation) and does not mention error cases. This incompleteness may leave the agent unsure of the outcome.
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 0%, so the description must compensate. It does: it explains that expectedOrigin and expectedDestination must match the active request, mode has only two allowed values, and time must be in 24-hour HH:MM. This adds functional meaning beyond the raw 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 sets a same-day depart-at or arrive-by time on a Google Maps transit directions request. It specifies the resource (transit directions request) and the action (set time), and distinguishes it from siblings like maps_set_travel_mode by focusing on transit time rather than travel mode.
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 explicit prerequisites: expectedOrigin and expectedDestination must match the active maps_directions request, Interactive Assist must be enabled, and mode/time are restricted. It implies when to use it but does not explicitly contrast with alternative tools, though the constraints give clear 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?
Without annotations, the description carries the burden and does well: it discloses the mechanism (rebuilding URL parameters), preconditions (expected values must match active request), failure behavior (fail closed), and preservation of mode and avoid constraints. It omits any return value or side effect but provides substantial 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the core action, and packs necessary details (preconditions, failure modes, preservation) without fluff. Every clause adds value.
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 two required params, no output schema, and no annotations, the description covers the swap action, preconditions, and failure behavior, but leaves ambiguity around what 'fresh' means and what the tool returns or updates on success. It doesn't explicitly state the effect on the map/URL state after swap, which could confuse 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?
Schema coverage is 0%, so the description must explain parameters. It does: expectedOrigin and expectedDestination are defined as expected values that must match the active canonical request, clarifying they are validation inputs rather than the new swapped values. This adds meaningful semantic beyond the plain string schema, though format specifics are not given.
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 swaps origin and destination for a directions request, differentiating from sibling tools like maps_directions or maps_set_travel_mode by specifying the action on an existing request. The implementation detail (rebuilding URL params vs. UI button) reinforces uniqueness.
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 implies usage for swapping endpoints on an active simple request and mentions failure conditions (waypoint routes, omitted origins), but doesn't explicitly contrast with alternatives like maps_directions or maps_get_route_share_link. There's no direct 'do not use for X' or 'use this when Y' guidance, though prerequisites are stated.
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?
Given no annotations, the description carries full responsibility for transparency. It discloses the exact zoom level, the restriction on direction ('in|out'), the revalidation of expectedQuery, and the success criteria (same query and URL change). This gives a clear behavioral contract, though it could be more concise.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly verbose and repetitive, with phrases like 'exactly one level', 'exact-one level', and 'exact one-level' repeated. It could be condensed to a couple of sentences without losing meaning. The structure is functional but not polished.
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 provides essential context: the tool operates on the active search-result viewport, requires an enabled interactive map, and defines success via URL change. It doesn't describe return values (no output schema), but that's not required. It is complete for a simple zoom action.
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?
Both parameters are touched upon: direction is clarified as restricted to 'in|out', and expectedQuery is described as the search query to be preserved and revalidated. This adds semantic meaning beyond the bare schema, covering both parameters adequately.
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: zooming the Google Maps viewport by exactly one level while preserving a search query. It distinguishes from sibling tools (search, directions, etc.) by focusing on the zoom 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 explains when to use the tool (to zoom while preserving a search query) and mentions the required condition 'Interactive Maps must be enabled'. However, it doesn't explicitly contrast with alternative zoom methods or state when not to use it, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the revalidation of expectedLabel against the visible tab identity before the action, which is a safety check. It also states the prerequisite that Interactive Assist must be enabled. However, it does not specify whether the action is a read-only view switch or a mutating operation, what happens if validation fails, or whether it returns any result. This leaves 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?
The description is concise and well-structured, covering purpose, validation, exclusions, and a prerequisite in just a few sentences. There is no redundant or verbose language, and it efficiently conveys essential 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 selection tool, the description covers key aspects: what it does, what parameters are required, the validation behavior, an exclusion, and a system requirement. It lacks an explicit statement about side effects (e.g., it changes the visible tab) and does not describe error handling or return values. Given the scope and no output schema, this is reasonably complete but could be enhanced with a note on whether it is read-only or returns a status.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain the parameters. It explains expectedLabel as required and revalidated against the tab identity, clarifying its purpose. The tab parameter is effectively described by the phrase 'Overview or About tab', and the exclusion of Reviews further clarifies valid values. While not exhaustive, the description provides sufficient semantic guidance.
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: selecting the verified Overview or About tab for the currently selected Google Maps place. It uses a specific verb and resource, and it distinguishes itself from sibling tools by focusing on tab selection within a place, not search, results, or directions.
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 context on when to use the tool: for the Overview or About tab. It also gives a clear exclusion: Reviews is intentionally not exposed. It mentions the prerequisite that Interactive Assist must be enabled, and it explains the revalidation of expectedLabel. However, it does not explicitly name alternative tools for other tabs or scenarios.
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?
With no annotations provided, the description carries the full load for behavioral disclosure, and it does disclose one genuinely non-obvious behavior: 'guard against UI reordering.' This reveals statefulness and a consistency mechanism that would be impossible to infer from the schema. However, it never defines side effects, failure modes (e.g., out-of-range index), or result semantics, leaving some 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 sentences and roughly 35 words, with the core purpose front-loaded first. The first sentence establishes the action; the second adds a single, high-value refinement. Every word pulls weight—no fluff, no restating the schema.
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 low-complexity tool (2 primitive params, no output schema), the description covers the action, the interaction model (UI-based candidate selection), and a key safety mechanism (expectedLabel guard). It's missing some ideal context like what happens on failure, what the return/acknowledgement is, and whether the selection persists—but for such a simple tool, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate, and it does so meaningfully: 'zero-based index' clarifies the integer parameter's semantics (range is already in the schema) and 'Pass expectedLabel from maps_read_route_summary when available to guard against UI reordering' explains the optional string's purpose and provenance. Both parameters receive worthwhile elaboration beyond what the raw JSON Schema types/ranges convey, though more precise format details for expectedLabel would push it to a 5.
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-resource-scope pattern: 'Select a currently displayed route candidate by zero-based index.' The qualifiers 'currently displayed' and 'zero-based' precisely scope the operation and distinguish it from related tools like maps_select_result (search results) or maps_set_travel_mode.
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 through 'currently displayed route candidate' (implying you should use this only when route candidates are on screen), and the tip about 'Pass expectedLabel from maps_read_route_summary' hints at a workflow. However, it never explicitly names alternatives, excludes any scenario, or states when NOT to use this tool. The context is sufficient to avoid obvious misuse, but the guidance is implicit, not prescriptive.
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?
With no annotations provided, the description carries the full behavioral burden. It discloses postconditions: verifies the exact Best/おすすめ radio and unchanged resolved endpoints, drops the stale URL action, and preserves the current directions view. It also indicates failure behavior for mismatched or non-transit requests.
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 dense but efficient: three sentences front-load the primary action, then add necessary conditions and behavioral outcomes. No filler or redundancy; every clause adds value.
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 specialized UI radio-selector with no output schema and no annotations, the description covers purpose, preconditions, failure cases, and side effects well. It does not mention sibling alternatives, but the bounded scope makes the description largely 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 0%, so the description must compensate. It explains that expectedOrigin and expectedDestination must match the active maps_directions request, which is the key semantic constraint. However, it does not elaborate on the meaning of origin/destination values beyond this matching requirement.
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: selecting Google Maps' live-observed Recommended/Best travel-mode radio for a fresh simple transit directions request. It distinguishes itself from sibling tools like maps_set_travel_mode by scoping to the Recommended/Best radio and explicitly failing on non-transit requests.
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 concrete usage conditions: expectedOrigin and expectedDestination must match the active maps_directions request, and non-transit or request-with-omitted-features scenarios fail closed. It also notes the Interactive Assist prerequisite. It does not explicitly name alternative sibling tools, but the context is clear enough for selection.
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?
With no annotations provided, the description carries the full behavioral burden. It discloses that the tool never reads clipboard contents, is intentionally transit-only, targets the visible Share directions dialog, and depends on Interactive Assist. It does not describe failure behavior or exact output format, but the disclosed constraints are substantial.
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 three focused sentences with the core purpose front-loaded and prerequisites following. The phrasing 'currently live-observed JA/en-US share surface' is slightly technical but still earns its place by clarifying platform constraints. 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 tool with no annotations and no output schema, the description covers the essential UI-state prerequisites, route type restriction, and environment requirement. It lacks explicit return-format detail and error/fallback behavior, but the core information needed to invoke it successfully is present.
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 only provides min/max length, so the description's statement that expectedOrigin and expectedDestination must match the active canonical directions request adds meaningful constraints. However, 'canonical' is not defined, and the description does not explain where these values come from or what format they should take. Given 0% schema coverage, this is partial but adequate compensation.
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 ('Return') and clearly identifies the resource: the Google Maps-generated share URL from the visible Share directions dialog for a selected simple transit route. This distinguishes it from sibling tools like maps_get_place_share_link and maps_get_search_share_link.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when it is appropriate to use the tool: after maps_select_route, only for transit routes, only when expectedOrigin/expectedDestination match the active canonical directions request, and only when Interactive Assist is enabled. It also implies a when-not by being transit-only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states that the tool verifies only the expansion state, does not return or harvest weekly hours data, and revalidates expectedLabel immediately before activating exactly one observed hours control. This is strong, non-obvious 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no filler. The main action is front-loaded, and each sentence adds distinct value: scope, validation/activation behavior, non-return of data, and prerequisite.
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 single-parameter tool with no annotations or output schema, the description covers purpose, prerequisite, validation behavior, and non-return of data. It could be more complete by explaining what Interactive Assist is or what expectedLabel should look like, but overall it is largely sufficient for correct 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 0%, so the description must compensate. It adds some meaning by explaining that expectedLabel is required and revalidated before the hours control is activated, implying it is used to identify the control. However, it does not specify what value expectedLabel should contain or how it maps to the UI, leaving room for 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 uses a specific verb ('Expand') and resource ('visible opening-hours surface for the currently selected Google Maps place'), clearly distinguishing it from sibling read/search tools. It also clarifies what the tool does not do, reinforcing its unique purpose.
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 operates on the currently selected place, requires expectedLabel, and requires Interactive Assist to be enabled. It does not explicitly name alternative tools or when-not conditions, but the scope and prerequisites are clear enough for an agent to decide when to invoke it.
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?
With no annotations, the description carries the full transparency burden. It discloses that returned labels/text are untrusted external data and notes it is disabled by default, which are important behavioral traits. It does not detail permissions or effects, but for a read-only tool 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 concise, with two short sentences that front-load the main action and immediately follow up with caveats. Every sentence adds value without 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?
Given the tool's simplicity (no params, no output schema), the description sufficiently describes what it does, what it returns (a bounded summary of untrusted text), and its availability constraints. It is complete enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter information to convey. The baseline for no parameters is 4, and the description does not need to add anything beyond what the schema already implies (empty properties).
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 reads a small bounded summary from the active Google Maps route UI, using a specific verb (read) and resource (route summary). It distinguishes from sibling tools like maps_read_place_summary by specifying the route UI context.
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 context on when to use it ('intended only for the user's active request') and notes it is disabled by default, which guides usage. However, it does not explicitly name alternatives or state when not to use it, so it misses the explicit exclusion criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With zero annotations, the description carries full burden and delivers exceptional disclosure: 'Returned labels are untrusted external text' (trust boundary), 'does not expose the raw combobox/DOM' (isolation guarantee), 'intentionally resets the active Maps view' (destructive side effect on view state), and 'Interactive Assist must be enabled' (prerequisite). These are exactly the non-obvious behaviors an agent must know.
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?
Four sentences, zero filler, front-loaded with the primary action. Each sentence carries a distinct burden: behavior, trust warning, side effects/isolation, prerequisite. Terminology like 'combobox-controlled Suggestions grid' is dense but economical. There is not a single wasted clause.
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 single-parameter read tool with no annotations and no output schema, the description covers prerequisites, side effects, trust posture, output bounds, and behavioral isolation. It only omits failure-mode behavior (network errors, no-suggestion cases) and a small ambiguity in 'live' (vs. cached) suggestions—minor gaps for a tool this simple.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It clarifies that 'query' is typed verbatim ('type one user-directed query') and bounds the effective input semantics (what is typed is what is searched). For a single self-evident parameter, this fully disambiguates, though it could have added a format example or empty/whitespace handling.
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?
Specific verb chain ('open... type... return') with clear resource ('Google Maps root search box', 'combobox-controlled Suggestions grid') and bounded output ('at most six live suggestion identities'). The read-suggestion purpose is crisply distinguished from sibling `maps_search` (which presumably commits a query) by the 'read' verb naming and the emphasis on the suggestion surface.
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 suggestion-fetching workflow (type query → review suggestions → likely pass to maps_select_search_suggestion) and states the hard prerequisite 'Interactive Assist must be enabled.' However, it never explicitly names a sibling alternative (e.g., 'use maps_search for committed results') or gives an exclusion criterion, leaving the when-not-to-use case 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?
With no annotations provided, the description takes on the full burden. It discloses a key behavioral trait: the server refuses to click if expectedLabel doesn't match, indicating a safety mechanism. It also implies selection triggers a click action. It does not mention side effects like navigation, but for a simple 'select' operation, this is sufficient and adds valuable context beyond 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?
Two concise sentences. The first states the core action, the second provides a conditional parameter guideline. No filler, front-loaded, and every word 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 tool with two parameters and no output schema, the description covers the essential context: when to use it (currently displayed results), how to use it (index), and an important safety mechanism. It could mention prerequisites like 'only after a search' or error behavior, but these are implied. It is comparably complete to the high-standard examples.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains the expectedLabel parameter's purpose (a checksum from maps_read_place_summary) and clarifies that index is zero-based (though the schema's minimum of 0 hints at this). It does not detail index beyond that, but the description adds meaningful semantic value, especially for expectedLabel.
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: selecting a currently displayed place result by zero-based index. It specifies the verb (select), resource (place result), and scope (currently displayed), which distinguishes it from sibling tools like maps_select_place_tab or maps_select_route.
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 usage context for the expectedLabel parameter, advising to pass it from maps_read_place_summary when available to prevent clicks if the result list changed. It implies the tool is used after a search yields displayed results, but does not explicitly state alternatives or when-not-to-use, though the sibling context makes this fairly clear.
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?
With readOnlyHint=true in annotations, the description adds value by revealing the validation step (revalidating expectedLabel against the active place) and the prerequisite of Interactive Assist. It does not contradict annotations and provides behavioral context beyond the read-only annotation, though it does not describe error handling or output format.
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, containing only two sentences: the first states the core purpose, and the second provides essential parameter context. It is front-loaded and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, read-only), the description covers all key aspects: what it does, prerequisites, and validation behavior. With no output schema, naming the return as a 'share link' is sufficient. No major gaps exist.
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 0%, so the description must explain the parameter. It says 'expectedLabel is required and is revalidated against the active place,' which clarifies its purpose—matching the label to the currently selected place. This adds meaning beyond the schema's bare string type.
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 specifically states the tool returns a 'Google Maps-generated share link for the currently selected place,' which clearly identifies the action and resource. It implicitly distinguishes from sibling share-link tools (e.g., for routes or search) by focusing on 'currently selected place.'
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 explains that the tool is used when the Share control is about to be activated and that expectedLabel is revalidated. It also states the prerequisite that Interactive Assist must be enabled. However, it does not explicitly mention when not to use this tool or suggest alternatives, so it lacks explicit 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?
The description goes beyond the readOnlyHint annotation by detailing internal revalidation steps, verification of the Send a link tab, dialog closure, and the explicit guarantee that clipboard contents are never read. It adds meaningful behavioral context without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense paragraph that front-loads the purpose. It contains some detailed internal steps that could be trimmed, but every sentence contributes unique information. No wasted words, though slightly verbose.
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 single-parameter tool with no output schema, the description covers the purpose, parameter semantics, prerequisites, and safety behaviors. It is complete for the tool's complexity and clearly communicates what the agent needs to know.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for expectedQuery, so the description's explanation that it is 'revalidated against both the canonical maps_search action and the exact visible search combobox' gives essential meaning to the parameter. With 0% schema coverage, this is a strong compensation.
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 function: 'Return the Google Maps-generated share URL for the active search-result list.' It identifies a specific verb (Return), resource (share URL for search-result list), and distinguishes it from sibling share-link tools for places and routes.
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 usage context by tying the tool to the search-result list and mentions prerequisites (Interactive Assist must be enabled) and a safety note (clipboard never read). It doesn't explicitly name alternatives, but the resource specificity makes its intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden and delivers richly: it reveals that expectedQuery is revalidated immediately before each action, the rating is restricted to a live-observed subset, post-conditions include both a visible chip (with exact format example) and a closed Rating menu, the search query is preserved, and Interactive Assist must be enabled. This is exemplary behavioral transparency for a UI-interaction tool.
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 dense sentences with zero fluff — the first front-loads the action, the second covers verification and preconditions. Every clause adds information: 'bounded', 'revalidated', 'for example 4.0+', 'closed Rating menu', 'preserving the expected search query', and 'Interactive Assist must be enabled' all earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter filter tool with no output schema and no annotations, the description covers the action, parameter constraints, post-conditions, verification behavior, and a runtime prerequisite. Absent any need to explain return values (no output schema) or complex nested structures (no nested objects), this fully equips an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description adds meaningful semantics beyond the schema: expectedQuery's revalidation requirement, the 'observed half-step' nature of the enum values, and the exact chip format ('4.0+') as an example. It could have gone further explaining what 'observed' means operationally, but it substantially compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+object construction ('Apply... Rating filter option to the active search result view') and is clearly differentiated from sibling set_* tools like maps_set_transit_time and maps_set_travel_mode. The qualifiers 'bounded' and 'live-observed' add useful scope that distinguishes this tool's behavior from a generic rating filter.
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 that this tool operates on 'the active search result view' and implies workflow usage by noting the query is preserved and revalidated, which tells agents when it's safe to invoke. However, it doesn't explicitly name alternatives or state when-not-to-use, so it stops short of the top score for explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral details: failure modes (duplicate, reordered, missing, stale, changed identities) and success criteria (grid closes, Maps enters verified view). It also mentions the requirement for Interactive Assist, providing full 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 concise yet comprehensive, covering purpose, prerequisites, behavior, and failure modes without unnecessary verbosity. It is well-structured and easy to parse.
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?
The description provides sufficient context within the broader tool set: it relates to maps_read_search_suggestions and explains the expected outcome. It also addresses edge cases and prerequisites, making it self-contained for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters (query, index, expectedLabel) are explained through the description: query must be the same as used for the suggestion list, index and expectedLabel must match the returned values. This adds meaning beyond the schema's bare types.
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: selecting a search suggestion from a previously read suggestion list. It specifies the verb 'Select', the resource (suggestion from maps_read_search_suggestions), and distinguishes it from other selection tools like maps_select_result.
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?
It explicitly states prerequisites (must have read suggestions, same query must be used) and provides clear context for when to use this tool. It also warns against stale or mismatched data, giving practical guidance.
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:

[![maps-browser-mcp MCP server](https://glama.ai/mcp/servers/git-ksk/maps-browser-mcp/badges/card.svg)](https://glama.ai/mcp/servers/git-ksk/maps-browser-mcp)

Score Badge

Copy to your README.md:

[![maps-browser-mcp MCP server](https://glama.ai/mcp/servers/git-ksk/maps-browser-mcp/badges/score.svg)](https://glama.ai/mcp/servers/git-ksk/maps-browser-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/git-ksk/maps-browser-mcp'

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