Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

raisingcanes_directory

Browse the Raising Cane's store directory by state, city, or store, returning child names, paths, URLs, and store counts for each branch.

Instructions

Browse the Raising Cane's store directory. Returns one level of Raising Cane's store directory tree. Omit path for the root, which lists the US states Raising Cane's operates in; pass a child's path to descend (state to cities, city to stores). Each child carries its name, path, URL and how many stores sit under that branch. A child with is_store true is a store record rather than another directory level -- pass its path to GET /raisingcanes/store. This is a directory browse, not a proximity search: use GET /raisingcanes/nearby for a radius lookup.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathNoDirectory path from a previous response's children[].path, e.g. la. Omit for the root state index.

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?

No annotations are provided, so the description carries the full burden. It discloses that the tool returns only one level at a time, what each child contains (name, path, URL, store count), and how to identify a store record (is_store true) versus another directory level. It also clarifies that this is not a proximity search. However, it doesn't mention potential response limits or pagination behavior, but for a directory browse this is acceptable.

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 well-structured, starting with the core purpose and then progressively detailing the traversal mechanicscars, ending with a clear distinction from the sibling tool. Every sentence adds useful information, and the key distinction is placed at the end, but the first line already sets the context. No wasted words.

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 the tool's complexity (a simple one-parameter browse with a clear output structure described in the text), the description is complete. The output schema is absent, but the description clearly enumerates what fields children will have (name, path, URL, store count) and how to identify store records. An agent can successfully invoke this tool and interpret its response.

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 description coverage is 100%, and the schema already explains the 'path' parameter. The description adds value by explaining how to obtain the path ('from a previous response's children[].path') and the effect of omitting it (root). It also gives an example ('e.g. la'). This goes beyond simple schema repetition.

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 it's a directory browse tool with a specific verb ('Browse'), resource ('Raising Cane's store directory'), and behavior (returns one level of the tree). It explicitly distinguishes from sibling raisingcanes_nearby by stating 'This is a directory browse, not a proximity search.'

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 explicitly instructs when to use this tool (to browse the directory tree) and when not to (use GET /raisingcanes/nearby for proximity search). It also explains the traversal pattern (omit path for root, pass child's path to descend) and mentions the alternative tool by name.

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