Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

papajohns_menu

Get a Papa John's restaurant's priced menu by store ID, or the national default menu. Returns full menu with prices, calories, and customization options for US and Canada locations.

Instructions

Get a Papa John's restaurant's priced menu. Returns a Papa John's US or Canada restaurant's full menu with that restaurant's own prices. Prices are per restaurant, not national -- the same 14-inch pizza can differ by several dollars between two stores -- so pass a store_id from GET /papajohns/store or GET /papajohns/nearby. Omitting it returns the national default menu, flagged as national_default in the response. Each category is returned with its sections and product groups, and every orderable SKU carries its price, calories, serving size, slice count and image. Set include_options to also get each product group's customization axes: every size and crust it is sold in, and every preparation instruction (how much cheese, how well done) with its choices. This is the US and Canada menu -- for India use GET /papajohns/india/menu, and for Chile, Costa Rica, Guatemala, Panama, Portugal or Spain use GET /papajohns/intl/menu.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
categoryNoReturn only one category. One of: dippingsauces, desserts, drinks, extras, papabowls, pizza, sandwiches, sides, wings
store_idNoRestaurant id from GET /papajohns/store or GET /papajohns/nearby. Omit for the national default menu.
include_optionsNoInclude each product group's sizes, crusts and preparation instructions. Default false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.17.5
    • addedInput schema / properties / category / enum
      Added value: +[
+  "dippingsauces",
+  "desserts",
+  "drinks",
+  "extras",
+  "papabowls",
+  "pizza",
+  "sandwiches",
+  "sides",
+  "wings"
+]
  2. Addedv1.16.2

TDQS

A4.9/5.0
Behavior5/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 per-store versus national pricing behavior, the national_default flag, the response composition (categories, sections, product groups, SKU fields), and the effect of include_options. For a read-only menu fetch this is comprehensive behavioral disclosure.

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 long but every sentence earns its place: it front-loads the core purpose, justifies the store_id requirement with a concrete pricing example, explains default behavior, enumerates response contents, and closes with geographic routing. No filler or repetition of schema trivia.

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?

With three optional parameters, no output schema, and a family of geographic menu siblings, the description covers what an agent needs: default behavior, parameter effects, return contents, and how to route to alternative menus. The response shape is described sufficiently even without an output schema.

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 real meaning beyond the schema for store_id by naming its source endpoints and explaining the default behavior, and for include_options by describing exactly what customization axes are returned. Category is less elaborated, but the enum already documents it fully.

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 a Papa John's restaurant's priced menu.' It clearly distinguishes this US/Canada menu endpoint from sibling country-menu tools such as papajohns_india_menu and papajohns_intl_menu, and from store lookup endpoints it references as input sources.

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?

It explicitly says when to use the tool (US/Canada menus) and when not to (India, Chile, Costa Rica, Guatemala, Panama, Portugal, Spain), naming the alternative endpoints. It also gives concrete usage guidance for store_id: pass one from the store/nearby endpoints for restaurant-specific prices, or omit it for the national default.

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