Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

mcdonalds_item_list

Retrieve nutrition and allergen data for up to 20 McDonald's items in one call, providing per-component ingredient and allergen breakdowns that single-item lookups miss.

Instructions

Get nutrition and allergen detail for a batch of McDonald's items. Returns the same published nutrition detail as GET /mcdonalds/item for up to 20 items in one call, plus the per-component ingredient and allergen breakdown that the single-item endpoint does not expose -- a composite item's overall allergen statement is the union of its parts' (a burger's bun, patty, cheese and condiment each carry their own ingredient statement and allergens), so this is the source to use when the full breakdown matters, not just the item-level summary. Item ids come from GET /mcdonalds/menu and are market-specific, so pass the same country back. The response echoes the requested ids so a caller can tell which ones McDonald's returned nothing for.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
countryNoMarket (default us). One of us, ca, au, ie, nz, ch, se. Must match the market the item ids came from.
item_idsYesComma-separated McDonald's numeric product ids, up to 20

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.17.5
    • addedInput schema / properties / country / enum
      Added value: +[
+  "us",
+  "ca",
+  "au",
+  "ie",
+  "nz",
+  "ch",
+  "se"
+]
  2. Addedv1.16.2

TDQS

A4.1/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 and does well: it discloses the batch size limit, the added per-component breakdown versus the single-item endpoint, and the composite allergen union semantics with a concrete burger example. It also reveals that the response echoes requested ids so callers can detect missing items. It does not cover error behavior or rate limits, but the most important behavioral traits are disclosed.

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 description is longer than a two-sentence definition, but every sentence carries information: purpose, batch capability, differentiating breakdown logic, prerequisite id source, market matching, and response echoing. The parenthetical burger example illustrates the union point without fluff. It could be tightened slightly, but no sentence is wasted.

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?

Given there is no output schema, the description adequately covers what the tool returns (same nutrition detail as single item plus per-component breakdown) and how to interpret missing ids via echoing. It also provides the key prerequisite for correct invocation (market-specific ids from the menu endpoint). An example response would be a minor bonus but is not necessary for correct invocation.

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?

Schema coverage is 100%, so the baseline is 3. The description adds the useful fact that item_ids come from GET /mcdonalds/menu and reinforces market-specificity, but the schema already documents the comma-separated format, the 20-item limit, and the country-match requirement. The added value is marginal, so 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 opens with a specific verb and resource: 'Get nutrition and allergen detail for a batch of McDonald's items.' It explicitly contrasts itself with the single-item endpoint (GET /mcdonalds/item), making the distinction from sibling mcdonalds_item unambiguous. The batch limit of 20 and the extra per-component breakdown further sharpen the definition.

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 concrete usage context: item ids come from GET /mcdonalds/menu and are market-specific, so the same country must be passed. It also states when this tool is the right choice ('use when the full breakdown matters, not just the item-level summary'), though it stops short of explicitly naming the alternative for item-level-only needs.

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