Crawlora MCP

starbucks_nutrition

Read-only

Recalculate calories, fat, sugars, and protein for a CUSTOMIZED Starbucks drink -- swap the milk, change the espresso-shot or syrup-pump count -- rather than the standard recipe. Starbucks offers this for only four hot espresso beverages: product_number/form must be 406/hot (Caffe Americano), 407/hot (Caffe Latte), 408/hot (Caffe Mocha), or 413/hot (Caramel Macchiato); anything else returns an invalid-parameter error naming those four. size_sku comes from a starbucks_product result's sizes[].sku. modifiers is the COMPLETE build, not a change-set: start from that size's default_recipe, adjust what you want, and send the whole list back; an empty list is rejected. Each modifier takes a sku, an optional quantity (default 1, and the dial that matters for countable modifiers like espresso shots), and an optional replaced_sku when substituting a pick-one slot such as the milk. Returns Starbucks' own four-value dynamic-nutrition panel, which is smaller than the full per-size panel starbucks_product returns for the standard build. market selects which country site answers, one of us or ca (default us).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "product_number": "<product_number>",
      "form": "<form>",
      "size_sku": "<size_sku>",
      "modifiers": "<modifiers>"
    },
    "name": "starbucks_nutrition"
  }
}

Input Schema

Name	Required	Description
`form`	Yes	Product form. Only hot is supported for this endpoint. Documented values: hot.
`market`	No	Market selects which country site answers. Defaults to us.
`size_sku`	Yes	SizeSKU is the sku of the size being built, from a /starbucks/product result's sizes[].sku.
`modifiers`	Yes	Modifiers is the COMPLETE build, not a delta from the default. Start from the size's default_recipe (returned by /starbucks/product), change what you want, and send the whole list back. An empty list is rejected by Starbucks with "Modifiers list required".
`product_number`	Yes	Starbucks numeric product id. One of: 406, 407, 408, 413

Output Schema

Name	Required	Description	Default
`data`	Yes	The tool result payload (shape varies per tool; see each tool's docs resource).

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedOct 7, 2026

addedInput schema / properties / form / description

Added value: +"Product form. Only hot is supported for this endpoint. Documented values: hot."

addedInput schema / properties / market / description

Added value: +"Market selects which country site answers. Defaults to us."

addedInput schema / properties / modifiers / description

Added value: +"Modifiers is the COMPLETE build, not a delta from the default. Start\nfrom the size's default_recipe (returned by /starbucks/product),\nchange what you want, and send the whole list back. An empty list is\nrejected by Starbucks with \"Modifiers list required\"."

addedInput schema / properties / modifiers / items / properties / quantity / description

Added value: +"Quantity is how many of this modifier. Defaults to 1. For countable\nmodifiers (formCode \"qty\" -- espresso shots, syrup pumps) this is the\ndial that actually moves the numbers."

addedInput schema / properties / modifiers / items / properties / replaced_sku / description

Added value: +"ReplacedSKU is the default modifier this one substitutes, when the\ncaller is swapping a pick-one slot such as the milk. Leave empty for\na modifier that is not replacing anything."

addedInput schema / properties / modifiers / items / properties / sku / description

Added value: +"SKU is the modifier's sku, from a product size's default_recipe[].sku\nor from an option in the product's options tree (e.g. a different\nmilk)."

addedInput schema / properties / product_number / description

Added value: +"Starbucks numeric product id. One of: 406, 407, 408, 413"

addedInput schema / properties / size_sku / description

Added value: +"SizeSKU is the sku of the size being built, from a /starbucks/product\nresult's sizes[].sku."

First observedOct 5, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations only cover readOnly/openWorld, so the description carries real behavioral weight: empty modifier list is rejected, out-of-range product numbers produce an invalid-parameter error naming the four allowed values, modifiers must be a complete build rather than a delta, and the returned panel is smaller than starbucks_product's. This is substantive disclosure beyond the annotations.

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?

Front-loaded with the core action, then constraints, then parameter mechanics. Despite being a single dense paragraph, every sentence introduces a distinct operational fact with no filler.

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?

An output schema exists, so return explanation is optional, yet the description still characterizes the response (four-value dynamic-nutrition panel). Constraints, prerequisites, and the customization workflow are all present, leaving no material gap for correct invocation.

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 schema already documents individual fields. The description adds cohesive workflow context (start from default_recipe, send the whole list back, quantity as the dial for countable modifiers, replaced_sku for pick-one slots), though a fair amount restates schema text. Slightly above baseline.

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?

States a specific verb and resource (recalculate calories/fat/sugars/protein for a CUSTOMIZED drink) and explicitly distinguishes this from the standard recipe. The contrast with starbucks_product's full per-size panel makes the purpose unmistakable against siblings.

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?

Gives explicit when-to-use (customized builds) vs when-not (standard recipe), names the four permitted products, states that anything else errors, and specifies prerequisites (size_sku from starbucks_product's sizes[].sku). Routing to the correct sibling and call sequence is fully specified.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Crawlora MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?