Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

starbucks_nutrition

Recalculate calories, fat, sugars, and protein for a customized Starbucks drink by swapping milk, espresso shots, or syrup pumps. Get exact figures for your build from four hot espresso beverages.

Instructions

Recalculate nutrition for a customized Starbucks drink. Recalculates calories, fat, sugars, and protein for a customized build of a Starbucks beverage: swap the milk, change the number of espresso shots or syrup pumps, and get the real figures for that exact drink rather than the standard recipe. Starbucks only offers this for four hot espresso beverages; product_number and form must be one of 406/hot (Caffe Americano), 407/hot (Caffe Latte), 408/hot (Caffe Mocha), or 413/hot (Caramel Macchiato). Any other product returns an invalid-parameter error naming the four that work. 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 needs a sku, an optional quantity (defaults to 1, and is 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. This returns Starbucks' own four-value dynamic-nutrition panel, which is smaller than the full per-size panel /starbucks/product returns for the standard build.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
formYesProduct form. Only hot is supported for this endpoint
requestYesThe size and the complete modifier build
product_numberYesStarbucks numeric product id. One of: 406, 407, 408, 413

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.17.5
    • addedInput schema / properties / form / enum
      Added value: +[
+  "hot"
+]
    • addedInput schema / properties / request / properties
      Added value: +{
+  "form": {
+    "type": "string"
+  },
+  "market": {
+    "description": "Market selects which country site answers. Defaults to us.",
+    "type": "string"
+  },
+  "modifiers": {
+    "description": "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\".",
+    "items": {
+      "properties": {
+        "quantity": {
+          "description": "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.",
+          "type": "integer"
+        },
+        "replaced_sku": {
+          "description": "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.",
+          "type": "string"
+        },
+        "sku": {
+          "description": "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).",
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "type": "array"
+  },
+  "product_number": {
+    "description": "ProductNumber and Form identify the product. Only the four\ncombinations in dynamicNutritionProducts are supported upstream.",
+    "type": "string"
+  },
+  "size_sku": {
+    "description": "SizeSKU is the sku of the size being built, from a /starbucks/product\nresult's sizes[].sku.",
+    "type": "string"
+  }
+}
  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 present, the description carries the full behavioral burden and meets it: it discloses the complete-build-not-delta semantics, the empty-list rejection with its error message, the invalid-product error behavior, the requirement that size_sku come from /starbucks/product, and the reduced four-value output panel. Nothing contradicts the (absent) annotations.

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 long, but each sentence earns its place: eligibility, input sourcing, modifier semantics, and output shape. The only blemish is mild redundancy between the first two sentences, both introducing 'recalculate nutrition for a customized build'; merging them would tighten it without losing information.

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?

For a nested-parameter tool with no output schema, this is complete: it covers purpose, product eligibility and error behavior, how to source size_sku, the complete-build requirement, modifier fields, and the return shape (four-value dynamic panel). No aspect an agent needs to construct a valid call is left unexplained.

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 description coverage is 100% and already documents size_sku, modifiers structure, quantity semantics, and replaced_sku, so the baseline is 3. The description adds value on top by mapping the four product numbers to human-readable drink names and by clarifying that product_number/form must form one of the four valid combos, marginally exceeding the 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?

The description opens with a specific verb-resource pair ('Recalculate nutrition for a customized Starbucks drink') and immediately names the four nutrients and the customization actions (swap milk, change shots/pumps). It also distinguishes itself from starbucks/product by clarifying this is the dynamic custom-build version rather than the standard per-size panel.

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 states when to use the tool (customized build rather than the standard recipe), names the alternative it compares to (/starbucks/product's full per-size panel), and spells out an exclusion (only 406/hot, 407/hot, 408/hot, 413/hot; anything else errors). An agent can decide between this and the sibling starbucks/product without further inference.

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