Crawlora MCP

starbucks_product

Read-only

One Starbucks product's full detail: name, description, product type, image, Rewards star cost, customization options, and every size with its own nutrition panel (serving size, calories, calories from fat, and per-fact values for total fat with saturated and trans fat subfacts, cholesterol, sodium, total carbohydrates, protein, and caffeine). product_number is the numeric id from a starbucks_menu result or a product page URL. form is that product's form, one of hot, iced, single, packaged, whole-bean, via. store_number optionally scopes availability to one store. Starbucks does not expose dollar pricing on this surface, so no price is returned; star_cost is the Rewards star cost. market selects which country catalog to resolve against, one of us or ca (default us). Each size also carries its default_recipe, the standard build, which is the required starting point for starbucks_nutrition. An unknown product number, or a form that product is not sold in, returns not found.

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>"
    },
    "name": "starbucks_product"
  }
}

Input Schema

Name	Required	Description
`form`	Yes	Product form. One of: hot, iced, single, packaged, whole-bean, via. Documented values: hot, iced, single, packaged, whole-bean, via.
`market`	No	Starbucks country site to read. One of: us, ca. Defaults to us. Documented values: us, ca.
`store_number`	No	Starbucks store number to scope availability to, e.g. 101-54
`product_number`	Yes	Starbucks numeric product id

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.

Changed4 schema fields changedOct 7, 2026

addedInput schema / properties / form / description

Added value: +"Product form. One of: hot, iced, single, packaged, whole-bean, via. Documented values: hot, iced, single, packaged, whole-bean, via."

addedInput schema / properties / market / description

Added value: +"Starbucks country site to read. One of: us, ca. Defaults to us. Documented values: us, ca."

addedInput schema / properties / product_number / description
```
Added value: +"Starbucks numeric product id"
```

addedInput schema / properties / store_number / description

Added value: +"Starbucks store number to scope availability to, e.g. 101-54"

First observedOct 5, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the readOnlyHint/openWorldHint annotations: it discloses that no dollar price is returned and why (star_cost is the Rewards star cost), that store_number optionally scopes availability, and that an unknown product number or an unsold form returns a not-found error. That is exactly the behavioral context annotations cannot carry.

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?

Front-loaded with the payload and then the parameters, in one dense paragraph. The exhaustive enumeration of nutrition subfacts (saturated/trans subfacts, cholesterol, sodium, caffeine) is somewhat verbose for a description, but the ordering is logical and each sentence carries operational 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?

With an output schema and readOnly/openWorld annotations present, the description still closes the remaining gaps: parameter origins, the market default, the not-found failure mode, and the hand-off contract to starbucks_nutrition. Nothing needed to invoke it correctly is missing.

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, but the description adds real meaning: it explains product_number's provenance, that form is the product's own form, that store_number is an optional availability scope, and that market (us/ca, default us) selects the catalog. Slightly under 5 only because the two required params are also self-evident from the schema.

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 resource ('One Starbucks product's full detail') and enumerates the returned fields — name, description, product type, image, star cost, customization options, per-size nutrition panels. It clearly separates itself from starbucks_menu (source of product_number) and starbucks_nutrition (consumer of default_recipe).

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?

Gives concrete context: product_number comes from a starbucks_menu result or a product page URL, and default_recipe is called out as the required starting point for starbucks_nutrition. It does not state an explicit when-not or an alternatives tradeoff (e.g., menu vs product detail), so it stops short of full routing guidance.

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?