Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

mcdonalds_restaurants

Find McDonald's restaurants near any location using latitude and longitude. Returns store info, hours, amenities, and delivery links across ten markets.

Instructions

Find McDonald's restaurants near a location. Returns McDonald's restaurants near a latitude/longitude, in any of ten markets. Each restaurant carries its store id, name, street address, city, state, postal code, phone, coordinates, timezone, open status, today's dining and drive-thru hours, the full published week of hours, and McDonald's own amenity codes (for example DRIVETHRU, WIFI, MOBILEOFFERS, GIFTCARDS). A delivery deep link is included where McDonald's publishes one; note it points at a third-party delivery platform. A coordinate with no McDonald's nearby returns an empty list rather than an error. Set country to search outside the United States -- the locator covers more markets than the menu and item endpoints do, so a country valid here is not necessarily valid there.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
radiusNoSearch radius in miles, 1-100 (default 20)
countryNoMarket to search (default us). One of us, gb, ca, au, de, ie, nz, ch, nl, se.
latitudeYesSearch center latitude
longitudeYesSearch center longitude
max_resultsNoMaximum restaurants to return, 1-50 (default 10)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.17.5
    • addedInput schema / properties / country / enum
      Added value: +[
+  "us",
+  "gb",
+  "ca",
+  "au",
+  "de",
+  "ie",
+  "nz",
+  "ch",
+  "nl",
+  "se"
+]
  2. Addedv1.16.2

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full transparency burden, and it does so thoroughly: it enumerates the complete returned payload, discloses the empty-list edge case, warns that delivery deep links point to third-party platforms, and explains that country coverage differs from menu/item endpoints.

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 long but dense, and much of the length is justified by the absence of an output schema: returned fields, edge behavior, and caveats all need to be expressed. The opening is front-loaded, though the second sentence partially restates the first, preventing a perfect score.

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 no output schema and no annotations, the description covers call semantics, return shape, edge behavior, market limitations, and external-link caveats. An agent has enough information to select and invoke the tool correctly without consulting anything else.

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 schema already documents all five parameters with ranges and defaults, so the 100% coverage baseline applies. The description adds meaningful country-specific context beyond the enum—that the locator supports more markets than the menu/item endpoints—which justifies a score above baseline.

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 first sentence names a specific verb ('Find') and resource ('McDonald's restaurants near a location'), then narrows it to a latitude/longitude search across ten markets. This distinguishes it clearly from sibling menu/item tools like mcdonalds_restaurant_menu and mcdonalds_menu, which serve a different 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 usage context: pass coordinates, use country for non-US searches, and expect an empty list when nothing is nearby. It does not explicitly name alternative tools or state when not to use this one, so it stops short of fully explicit routing.

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

Deploy Server

Other Tools