Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

papajohns_intl_menu

Get a specific Papa John's restaurant's priced menu across six international markets, with per-item prices, sizes, crusts, calories, and machine codes. Use store ID and market to return full menu data.

Instructions

Get a Papa John's restaurant's priced menu (international). Returns one Papa John's restaurant's full menu with that restaurant's own prices, in one of six international markets: Chile, Costa Rica, Guatemala, Panama, Portugal, and Spain. Prices are per restaurant, not national, so two restaurants in the same market can differ. Each pizza lists every size and crust combination it is sold in with that combination's own price and, where published, its calorie and portion figures; sides, drinks and desserts list their own portions. Machine codes for size and crust are returned alongside the market's own display labels in the local language. Currency is whatever the market trades in -- euros in Spain and Portugal, Chilean pesos in Chile, and so on -- so do not compare figures across markets. Use GET /papajohns/intl/stores to find a store_id. For India use GET /papajohns/india/menu; for the US and Canada see GET /papajohns/nutrition.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNoReturn only one product kind. One of: pizza, side
marketYesMarket. One of: chile, costa-rica, guatemala, panama, portugal, spain
store_idYesRestaurant id from GET /papajohns/intl/stores. Prices are specific to this restaurant.
food_typeNoReturn only products carrying this dietary or heat marker. One of: hot, mild, spicy, vegetarian. Products upstream does not mark are excluded.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.17.5
    • addedInput schema / properties / food_type / enum
      Added value: +[
+  "hot",
+  "mild",
+  "spicy",
+  "vegetarian"
+]
    • addedInput schema / properties / kind / enum
      Added value: +[
+  "pizza",
+  "side"
+]
    • addedInput schema / properties / market / enum
      Added value: +[
+  "chile",
+  "costa-rica",
+  "guatemala",
+  "panama",
+  "portugal",
+  "spain"
+]
  2. Addedv1.16.2

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It discloses non-obvious facts: prices are restaurant-specific rather than national, size/crust combinations have individual prices and optional calorie/portion data, machine codes accompany local-language labels, and currencies vary by market so cross-market comparison is invalid.

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

Conciseness4/5

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

The core purpose is front-loaded in the first sentence, and subsequent sentences add useful return-content and usage detail rather than repeating schema. The description is longer than the minimum, but the added length is justified by six markets, currency caveats, and per-item composition. Minor redundancy around 'own prices' and 'per restaurant, not national' keeps it from a 5.

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?

Even without an output schema, the description tells the agent what the response contains, how to find the required store_id, and which alternate endpoints to use for other regions. Optional filtering behavior is covered by the input schema, and the non-obvious currency and per-restaurant semantics are clearly explained.

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, and the description adds real value for market by explaining currencies and warning against cross-market price comparison. It also reinforces store_id's per-restaurant nature, though it adds little for kind and food_type beyond the already-clear schema descriptions.

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 uses a specific verb and resource: 'Get a Papa John's restaurant's priced menu (international)' and clarifies it returns a single restaurant's full menu. It names the exact six markets and per-restaurant pricing, which clearly distinguishes it from nearby sibling tools like papajohns_intl_deals, papajohns_intl_product, and papajohns_menu.

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 tells an agent how to obtain the required store_id via GET /papajohns/intl/stores and directs India and US/Canada use to sibling endpoints. It also enumerates the supported markets, so an agent knows precisely when this tool applies and when it does not.

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