Skip to main content
Glama
aserper

grubhub-mcp

by aserper

autocomplete_search

Fetch location-aware autocomplete suggestions for partial Grubhub food search queries, supporting delivery or pickup context.

Instructions

Get autocomplete suggestions for a search query.

Args: query: The partial search text latitude: Latitude for location context longitude: Longitude for location context location_mode: DELIVERY or PICKUP (default DELIVERY)

Input Schema

NameRequiredDescriptionDefault
queryYes
latitudeYes
longitudeYes
location_modeNoDELIVERY

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.7

TDQS

B3.4/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. It only says it returns suggestions; it discloses nothing about authentication, rate limits, or what a suggestion object contains, though it does usefully surface the location_mode default.

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 purpose is front-loaded in a single clear sentence, and the Args block is compact and justified given the complete absence of schema descriptions. No filler sentences.

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?

An output schema exists, so return values need not be described. Combined with the parameter documentation, the description is nearly complete for a simple read tool, with the only gap being the absence of behavioral/auth context.

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

Parameters4/5

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

Schema description coverage is 0% and no enum is defined, yet the description documents all four parameters in an Args block, clarifying that 'query' is partial text, lat/long are location context, and location_mode takes DELIVERY or PICKUP. This meaningfully compensates for the empty schema.

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?

States a specific verb and resource ('Get autocomplete suggestions for a search query'), which is clearer than a generic search tool. However, it does not distinguish itself from the sibling 'search_restaurants', leaving the agent to infer the autocomplete-vs-full-search boundary on its own.

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 name and phrase 'autocomplete suggestions' imply it is used for typeahead/partial input, but there is no explicit statement of when to use this versus 'search_restaurants' or any prerequisite/context. Usage is implied rather than documented.

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