SiteCheck Shop & Social

Grubhub restaurants delivering to a US ZIP code, optionally

ecommerce_grubhub

Read-only

Grubhub restaurants delivering to a US ZIP code (or lat/lng), optionally matching a search such as pizza or sushi: restaurant id, name, cuisines, rating and rating count, price level (1-4), delivery fee and order minimum (USD), delivery time window (minutes), pickup/delivery, open now, phone, address, distance (miles) and Grubhub link. Up to 20 per page. From Grubhub's own diner API through a US proxy. Related tools on this server, for a different need: ecommerce_aliexpress when you need AliExpress product search from the public search page; ecommerce_backmarket when you need Back Market refurbished-product search on a country site. Price: $0.002 in USDC per successful call, paid with x402 (Base, Solana or Arc); failed calls are not charged.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "ecommerce_grubhub"
  }
}

Input Schema

Name	Required	Description
`lat`	No	Latitude (with lng, instead of zip)
`lng`	No	Longitude (with lat, instead of zip)
`zip`	No	US 5-digit ZIP code, e.g. 10001 (or give lat and lng)
`mode`	No	delivery (default) or pickup
`page`	No	Page number, 1-10 (default 1)
`query`	No	Optional search text: cuisine, dish or restaurant name, e.g. pizza

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses the metered cost ($0.002 USDC per successful call), the payment rail (x402 on Base, Solana or Arc), and the billing rule that failed calls are not charged — a material precondition an agent must know before invoking. It also names the upstream data source (Grubhub's diner API via a US proxy) and the page-size cap, which annotations cannot convey.

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?

Purpose is front-loaded in the first clause, which is good, but the long inline enumeration of every returned field duplicates the output schema and bloats the opening sentence. The sibling-tool sentence and the pricing sentence each earn their place; the return-field list largely does not.

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 read-only open-world lookup with an output schema and full schema coverage, the description covers the essentials: locator modes, optional query, page cap, upstream source, and the payment precondition. Remaining gaps are minor — no statement of geographic coverage limits beyond "US", no rate-limit or auth-flow detail for the x402 payment step.

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 100%, so the baseline is 3, but the description adds meaning the schema does not: the 20-results-per-page limit implied by the paging parameters, and unit clarifications (delivery fee and order minimum in USD, delivery window in minutes, distance in miles). It does not explain the interplay between page and the 1-10 range or precedence between zip and lat/lng beyond what the schema already says.

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?

"Grubhub restaurants delivering to a US ZIP code (or lat/lng), optionally matching a search such as pizza or sushi" gives a specific verb-free but precise retrieval action, the exact resource, the geographic scope, and the optional filter. The description also enumerates the returned attributes and the 20-per-page cap, so an agent knows exactly what it gets back without opening the schema.

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 states the two locator modes (ZIP or lat/lng) and that the search text is optional with examples ("pizza or sushi"), which tells the agent when a query is warranted. It also names two sibling tools and the need each serves, though those siblings (AliExpress, Back Market) are product search rather than the closest restaurant competitors such as ecommerce_rappi, and no explicit when-not-to-use condition is given.

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

All SiteCheck Shop & Social tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?