Geolocate Me

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

The description adds valuable behavioral context beyond what annotations provide. While annotations indicate read-only and closed-world operations, the description specifies the data source ('Geolocate Me app running on the user's phone'), the specific device limitation ('only works for the device that authenticated this MCP session'), and details about what gets returned ('most recent GPS ping with latitude, longitude, accuracy in meters, a timestamp, a human-readable relative age, and a reverse-geocoded street address'). No contradiction with annotations exists.

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

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

The description is appropriately sized and front-loaded with the core purpose in the first sentence. Each subsequent sentence adds valuable information about usage, return data, and limitations. While slightly longer than minimal, every sentence earns its place by providing essential context for proper tool selection and use.

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 (location retrieval with multiple data points) and the absence of an output schema, the description provides comprehensive context about what gets returned. It covers the data source, device limitations, return format details, and usage boundaries. The main gap is not explicitly mentioning error conditions or what happens when location data is unavailable.

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?

With 0 parameters and 100% schema description coverage, the baseline would be 4. The description appropriately explains that no parameters are needed ('Get the user's current real-world location') and provides context about what drives the location retrieval ('from their phone's GPS'), which adds semantic value beyond the empty schema.

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

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

The description clearly states the tool's purpose with specific verb ('Get') and resource ('user's current real-world location'), and distinguishes it from a general-purpose location service by specifying it only works for the authenticated device. It explicitly differentiates from the sibling tool 'get_location_history' by focusing on current location rather than historical data.

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 guidelines with multiple examples of when to use this tool ('whenever the user asks where they are, where their phone is, what their current address is, where they parked, where they last were, or any question about their present location'). It also clearly states when NOT to use it ('it is NOT a general-purpose location lookup service'), creating a clear boundary for appropriate usage.

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

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

The description adds valuable behavioral context beyond the annotations: it specifies return limits ('Returns up to 1000 pings'), default behavior ('If no filters are passed, returns the most recent 1000 pings'), data source constraints ('phone that authenticated this MCP session'), and system dependencies ('Ping frequency and retention depend on the user's in-app settings'). The annotations (readOnlyHint: true, openWorldHint: false) are consistent with the description's read-only nature and closed-world scope.

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

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

The description is efficiently structured with purpose first, followed by usage examples, return format details, parameter guidance, default behavior, and system constraints. Every sentence adds value, with no redundant information. The front-loaded examples immediately clarify the tool's application.

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

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

For a read-only tool with good annotations and comprehensive schema coverage, the description provides excellent contextual completeness. It explains the return format in detail (including all data fields), documents default behavior, clarifies data source limitations, and provides system dependency information. The lack of output schema is compensated by the detailed return format description.

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?

With 100% schema description coverage, the baseline score is 3. The description adds some context about parameter usage ('Filter by time using hours, or from/to for specific date ranges') and clarifies the relationship between parameters ('if both hours and from are provided, from wins'), but doesn't provide significant additional semantic value beyond what's already well-documented in 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 clearly states the tool's purpose with specific verb ('Get') and resource ('user's past GPS location history from their phone'), distinguishing it from the sibling tool 'get_current_location' which presumably provides current location rather than historical data. The description explicitly lists example use cases that demonstrate its distinct function.

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 guidance on when to use this tool ('any question about where the user has been') with concrete examples of appropriate queries. It also implicitly distinguishes from the sibling tool by focusing on historical data rather than current location, and provides context about data limitations ('Data is limited to the phone that authenticated this MCP session').

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