Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

sonic_directory

Browse Sonic Drive-In's restaurant directory by country, state, and city. Returns a hierarchical tree with restaurant counts to discover available locations.

Instructions

Browse Sonic Drive-In's restaurant directory by country, state and city. Returns Sonic Drive-In's restaurant directory as a country to state to city tree, with a restaurant count at every level. Use it to discover which states and cities have restaurants before calling GET /sonic/locations or GET /sonic/nearby. Each city carries both its display name and the slug that composes into a store path. Counts here describe listed restaurants and are internally consistent (the city counts sum to total_count); GET /sonic/locations enumerates a larger set of store pages, so the two totals intentionally differ.

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": "sonic_directory"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.16.2

TDQS

A4.7/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently explains the returned structure (tree, counts, city names/slugs) and even discloses the internal consistency of counts and their intentional divergence from GET /sonic/locations. While it doesn't mention pagination or error behavior, the core behavioral traits are well covered, and there is no contradiction with any annotations (since none exist).

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 about 100 words but every sentence earns its place: purpose, output structure, usage guidance, and a critical note about count consistency. Front-loaded with the core function, it avoids fluff and is structured logically. This is a model of concise, informative tool documentation.

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?

For a parameterless browse tool with no output schema, the description is remarkably complete. It covers what it returns, how to use it, and how it relates to sibling tools, including the intentional count mismatch. An agent can decide when to call this tool and interpret its results correctly without additional information. This is exceptional completeness for the tool's complexity.

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 tool has zero parameters, so the description has no parameter semantics to explain. Per rubric, the baseline for 0 params is 4. The description does clarify the output field semantics (display name, slug, counts) in a way that adds value beyond the schema, but since there are no parameters, this dimension is inherently high-scoring.

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 precise verb and resource: 'Browse Sonic Drive-In's restaurant directory by country, state and city.' It clearly states the output format ('country to state to city tree, with a restaurant count at every level') and explicitly contrasts itself with sibling tools (GET /sonic/locations and GET /sonic/nearby) by positioning it as a discovery step. This makes the tool's role unmistakable.

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 when-to-use guidance: 'Use it to discover which states and cities have restaurants before calling GET /sonic/locations or GET /sonic/nearby.' It also clarifies the relationship with those endpoints by explaining the intentional difference in counts, preventing the agent from misinterpreting the discrepancy. This is clear, actionable usage context.

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