Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
JavaScript
Remote

fiveguys_store

Fetch a single Five Guys restaurant's full published profile by its locator path, covering address, phone, hours, coordinates, amenities, order links, photos, and franchisee details.

Instructions

Get one Five Guys restaurant by its locator path. Returns one Five Guys restaurant's full published profile by its locator slug -- address, phone, weekly in-store hours, separate delivery hours, coordinate, Google Place id, restaurant-amenity labels, and order/delivery/menu URLs. Get a path from GET /fiveguys/search or /fiveguys/nearby's locations[].path, or from GET /fiveguys/directory's children[].path where is_location is true. It also returns three detail-only extras that search and nearby results do not carry: description (this restaurant's own blurb, templated but genuinely per-location), photos (its published gallery images, omitted for the many locations that publish none), and breadcrumbs (the directory trail above it, each entry's path feeding straight back into GET /fiveguys/directory). Two fields available on search and nearby results are not published on this surface and are omitted here: price_range and pickup_and_delivery_services. A profile block, populated best-effort from a second Yext key, adds further per-restaurant detail no other field in this family carries: google_attributes (structured amenity flags, richer than services), review_page_url/review_invite_url, featured_message/featured_message_url, google_cid/facebook_store_id, routable_latitude/routable_longitude (a driving destination, distinct from the display coordinate), payment_options, meals_served, services, permanently_closed, directory_listing_url, franchisee_group (the operator of this specific restaurant -- a corporate code or a franchisee's own company name), facebook_vanity_url (this location's own Facebook handle), and faq (this restaurant's own generated question set, distinct from the national corpus GET /fiveguys/faq serves). Passing a state or city path returns 404 -- use GET /fiveguys/directory for those.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoThe restaurant's entity id, e.g. \
pathNoThe restaurant's locator slug, e.g. \

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.16.2

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the full burden, and it is mostly excellent: it discloses the returned field set, detail-only extras, fields intentionally omitted, the best-effort nature of the secondary Yext profile block, and the 404 behavior for state/city paths. It does not explicitly state what happens if neither parameter is supplied, but the overall read-only retrieval behavior is clear.

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?

The description is front-loaded with a strong summary, but the rest is a single dense paragraph with a very long field inventory and nested parentheticals. Much of the detail is relevant, but the structure is harder to scan than it should be, and the first two sentences partially repeat the same idea.

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?

There is no output schema, so the description must explain the returned fields, and it does so comprehensively: core profile fields, three detail-only extras, omitted fields, and the full `profile` sub-block. It also warns about an invalid input class and directs the caller to the proper sibling, making the tool effectively self-contained.

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. The description adds meaning beyond the schema by explaining that `path` is the locator slug, where to obtain it, and that state/city paths are invalid. It does not add much beyond the schema for `id`, but the path guidance is material.

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 description opens with a specific verb and resource: 'Get one Five Guys restaurant by its locator path.' It clearly states scope ('one') and enumerates what is returned. It also distinguishes this tool from siblings by contrasting its fields with search/nearby/directory surfaces.

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

Usage Guidelines5/5

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

The description gives explicit guidance on where to obtain the path: from GET /fiveguys/search, /fiveguys/nearby, or /fiveguys/directory. It also says that state/city paths return 404 and that GET /fiveguys/directory should be used in that case, and it contrasts which fields are unique to this endpoint versus siblings.

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

Install Server

Other Tools