Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

papajohns_intl_ingredients

Fetch Papa John's international ingredient catalogs for six markets, listing toppings, sauces, cheeses with family, pricing, and optional category filters.

Instructions

Get a Papa John's menu's ingredient catalog (international). Returns every topping, sauce, and cheese a pizza can be built with on one menu, in one of six international markets: Chile, Costa Rica, Guatemala, Panama, Portugal, and Spain. Each ingredient reports its family (meat, vegetable, base sauce, and so on), whether it is included on pizzas by default, whether it is charged at the premium rather than the normal rate, and whether it can be applied to just one half. The response also carries what one extra ingredient costs at each size, for both the normal and premium rates. Menu ids come from GET /papajohns/intl/stores.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
marketYesMarket. One of: chile, costa-rica, guatemala, panama, portugal, spain
menu_idYesMenu id from a restaurant returned by GET /papajohns/intl/stores
categoryNoReturn only one ingredient category. One of: base_cheese, base_sauce, extra_cheese, extra_sauce, meat, not_ingredient, premium, vegetable

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.17.5
    • addedInput schema / properties / category / enum
      Added value: +[
+  "base_cheese",
+  "base_sauce",
+  "extra_cheese",
+  "extra_sauce",
+  "meat",
+  "not_ingredient",
+  "premium",
+  "vegetable"
+]
    • addedInput schema / properties / market / enum
      Added value: +[
+  "chile",
+  "costa-rica",
+  "guatemala",
+  "panama",
+  "portugal",
+  "spain"
+]
  2. Addedv1.16.2

TDQS

A4.2/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 exactly what the response contains—each ingredient's family, default inclusion, premium rate, half-applicability, and extra ingredient costs at each size. This is transparent about the data returned. It does not mention potential side effects, permissions, or rate limits, but for a read-only menu catalog this is likely acceptable and not misleading.

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 and front-loaded with the core purpose. Every sentence contributes to explaining what the tool does and what it returns, without any redundancy or fluff. It is appropriately sized for the complexity of the tool.

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 tool that returns a detailed ingredient catalog, the description covers the essential context: scope (international markets), required inputs (menu_id), and the nature of the output. It does not mention pagination or potential response size, but given that this is a catalog lookup, the information provided is sufficient for an agent to call it correctly. Minor gap, but not critical.

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?

The input schema already provides descriptions for all three parameters (market, menu_id, and category), covering 100% of them. The description text does not add meaningful parameter-specific semantics beyond what the schema already states; it only mentions that menu ids come from a stores endpoint, which is already in the schema. Since schema coverage is high, the baseline of 3 is appropriate.

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 tool returns an ingredient catalog for a specific Papa John's menu in one of six named international markets. It specifies the exact content: every topping, sauce, and cheese, with attributes like family, default inclusion, premium status, half-applicability, and extra ingredient costs. This goes beyond a simple restatement of the tool name and distinguishes it from related tools like papajohns_intl_menu or papajohns_intl_product by focusing on ingredients and pricing.

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 gives clear usage context: it applies to international menus in six markets and explicitly tells the agent that menu ids come from GET /papajohns/intl/stores, which is a necessary prerequisite. However, it does not mention any alternative tools or conditions when one would not use this tool, so it stops short of the highest score.

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