Google Maps

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

Annotations declare readOnlyHint=true, which matches the read-only nature. Description adds behavioral details: WALK routes are beta and may lack sidewalks, output must use attribution field. No contradiction.

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

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

Well-organized with bold headings and bullet points. Front-loaded with purpose. Slightly long but every sentence adds value.

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

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

Covers input requirements thoroughly, attribution, and beta warning. Output schema exists, so return values need not be explained. No glaring gaps given the tool's complexity.

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

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

Schema coverage is 100%, but description adds clarity on input methods (address, lat_lng, place_id) and allowed combinations, plus an example. This goes beyond the schema descriptions.

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

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

The description states 'Computes a travel route between a specified origin and destination' with a clear verb and resource. It distinguishes itself from sibling tools (weather, URL resolution, name resolution, place search) by focusing on route computation.

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

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

Provides explicit input requirements and methods (address, lat_lng, place_id) with examples. States that missing origin/destination requires asking user. Mentions WALK mode beta status and display warning. Does not explicitly contrast with alternatives, but siblings are dissimilar.

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

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

Annotations already indicate readOnly=true (safe read operation). The description adds valuable behavioral context: timezone handling relative to location, date/hour constraints, rounding down hour for hourly, and the requirement to attribute output using the 'attribution' field. No contradictions with annotations.

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

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

The description is lengthy but well-structured with clear headings and bullet points, making it scanable. The first sentence delivers the core purpose. While every sentence adds value, the length could be slightly trimmed without losing clarity. Still, it earns a 4 for good organization.

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

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

Given the tool's complexity (multiple forecasting modes, location oneof, timezone considerations, constraints), the description covers all necessary information: data available, how to use each mode, parameter constraints, units system, and attribution. With an output schema existing, the description need not detail return values, but it still provides sufficient guidance for correct invocation.

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

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

The input schema has 100% parameter descriptions, but the description adds significant meaning: it explains the 'oneof' nature of the location field, provides examples for each sub-field, clarifies formatting rules (e.g., postal codes with country names), and details the interplay between date, hour, and location parameters. This goes well beyond the schema alone.

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

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

The description clearly states that the tool retrieves comprehensive weather data including current conditions, hourly, and daily forecasts. It lists specific data types (temperature, wind, etc.), and the resource ('weather') is distinct from sibling tools like 'compute_routes' or 'search_places', which are about different domains.

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

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

The description provides explicit usage modes for current, hourly, and daily forecasts, each with clear parameter combinations. It details when not to use (e.g., hourly beyond 120 hours, daily beyond 10 days, historical not supported for daily), and references sibling tool 'search_places' for place IDs. It also instructs to clarify today's date if not in context.

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

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

The description goes beyond the readOnlyHint annotation by detailing batch processing (up to 20 URLs), 1:1 mapping to response indices, the failed_requests map for partial failures, and how to interpret empty entities. This adds significant context for correct invocation.

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

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

The description is well-structured with clear headings and sections (When to call, Input Requirements, Error Handling). It is appropriately sized for a batch tool, though some redundancy exists (e.g., repeating URL formats). It front-loads the core purpose.

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

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

Given the tool has an output schema (so return values are documented separately) and the input schema covers 100% of parameters, the description is complete. It covers input requirements, batch behavior, error handling, and response mapping without gaps.

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

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

The schema has 100% description coverage, so baseline is 3. The description adds meaning by clarifying that URLs must be valid single-place Google Maps URLs of specific formats (e.g., maps.app.goo.gl) and that up to 20 are allowed, reinforcing and extending the schema.

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

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

The description clearly states the tool resolves Google Maps URLs into canonical Place IDs. It uses a specific verb (resolve) and resource (Maps URLs), and distinguishes from siblings like search_places and resolve_names by focusing on URL-to-ID conversion.

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

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

The description includes a 'When to call' section that specifies use when users provide Google Maps sharing links/URLs. It implies when not to use (e.g., for searching places), but does not explicitly name alternative tools like search_places or resolve_names.

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

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

Beyond annotations (readOnlyHint=true), the description details batch processing behavior, mixed results, failed_requests map, and 1:1 index mapping. This fully discloses the tool's operational characteristics.

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

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

The description is well-structured with headings (Input Requirements, Instructions, Error Handling) and front-loaded purpose. It is detailed but not excessively long; each section adds necessary context.

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

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

Given the complexity (batch, error handling) and existence of output schema, the description covers all necessary aspects: input requirements, optional parameters, usage constraints, and error handling. Nothing missing for effective use.

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

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

Schema coverage is 100%, so baseline 3. The description adds value by providing examples for 'text', exact format for 'location_bias' using viewport, and region_code details. It enhances understanding beyond the schema.

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

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

The first sentence clearly states the tool resolves location queries into Google Maps Place IDs. It explicitly distinguishes from siblings by specifying it handles specific place names/addresses, not general search, which differentiates it from 'search_places'.

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

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

Provides explicit when-not-to-use instruction: 'Do NOT call this tool if the downstream tools you plan to invoke already accept raw address or place name strings directly.' Also specifies required specificity of queries, guiding appropriate use.

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

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

Annotations already mark the tool as read-only and non-destructive. The description adds context about result attribution and the need for location specificity. No contradictions. Could mention error handling or rate limits but acceptable.

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

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

Well-structured with headings and bullet points. Front-loads the main purpose. Some repetition and length, but each section provides important guidance. Could be slightly more concise, but overall effective.

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

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

With output schema present, return values need not be explained. Covers all inputs thoroughly, including critical usage instructions. Could address default language or region handling, but sufficient for 4 parameters and complex requirements.

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

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

Input schema has 100% coverage, so baseline is 3. The description adds extensive examples, formatting details, and context for text_query (e.g., including attributes like opening hours) and location_bias (how to omit radius). Adds significant value beyond schema.

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

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

The description clearly identifies the tool as for finding places, businesses, addresses, and Google Maps searches. It distinguishes from sibling tools like compute_routes and lookup_weather by specifying the domain.

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

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

Explicitly states when to call the tool ('when the user's request is to find places') and gives detailed instructions on handling ambiguous locations, using location_bias, and providing specific queries. Implicitly excludes routing and weather tasks.

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