Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

wingstop_store

Fetch one Wingstop store's full details by directory path, including address, weekly hours, pickup/delivery services, coordinates, status, and price tier.

Instructions

Get one Wingstop store's detail. Returns one Wingstop store: name, full postal address, phone, coordinates, its general weekly hours plus a per-channel breakdown (pickup, delivery, takeout, drive-through), which pickup/delivery services it offers, its operating status, price tier and Google Place id. Store paths come from GET /wingstop/directory entries whose is_store is true. Passing a directory path here returns a 404 rather than a hollow record.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "path": "<path>"
    },
    "name": "wingstop_store"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathYesStore path from a /wingstop/directory child with is_store true

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.16.2

TDQS

A4/5.0
Behavior3/5

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

With no annotations provided, the description partially carries the behavioral burden. It explicitly discloses that passing a directory path with is_store false results in a 404 rather than an empty record, which is valuable error behavior. However, it does not mention other aspects like rate limits, idempotency, or what happens if the path is invalid, but for a read-only retrieval tool, the error disclosure is decent. A 3 is appropriate given the partial coverage.

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

Conciseness5/5

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

The description is concise, with three sentences that pack essential information: what is returned, where inputs come from, and an edge-case behavior. The most critical detail (the return fields) is front-loaded, and the error case is appended logically. No fluff or redundancy.

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 single-parameter retrieval tool with no output schema, the description provides a thorough enumeration of return fields and input provenance, plus an error behavior. Given the simplicity of the tool, this is near-complete. A slight gap is the lack of mention of response format (e.g., JSON structure) or any special handling, but the field list compensates. 4 is appropriate.

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

Parameters3/5

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

Schema description coverage is 100%, with the 'path' parameter already described as 'Store path from a /wingstop/directory child with is_store true'. The description adds a bit of nuance by explaining that directory paths without is_store true lead to a 404, but it does not provide additional syntax or format details. Baseline 3 is justified as the schema does the heavy lifting.

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 clearly states the verb ('Get'), the resource ('one Wingstop store's detail'), and enumerates the specific fields returned (name, address, phone, coordinates, hours, services, status, price tier, Google Place id). It distinguishes itself from siblings like wingstop_delivery_store, wingstop_nearby, and wingstop_directory by focusing on single-store detail with path input.

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 specifies that paths must come from GET /wingstop/directory entries with is_store true, providing clear context on input provenance. It does not explicitly mention alternatives like 'use wingstop_nearby for proximity search' or 'wingstop_delivery_store for delivery-specific info', but the context of directory-sourced paths is sufficient for most agents to select this tool over others.

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