Allows AI agents to search the Starbucks menu, customize drinks and food, find nearby stores, manage a cart, place mobile pickup orders, and check Starbucks Rewards balance and redeem rewards.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@striderlabs/mcp-starbucks Place a mobile order for a caramel frappuccino"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for Starbucks — let AI agents search the menu, customize drinks, find stores, place mobile pickup orders, and manage Starbucks Rewards.
Full menu search — search by name, category, or dietary preference (vegan, vegetarian, etc.)
Item customization — size, milk type, syrups, espresso shots, temperature, foam, and more
Cart management — add items, view cart, adjust quantities
Store finder — find nearby Starbucks locations with hours and features
Mobile ordering — place mobile pickup orders (requires Starbucks account)
Starbucks Rewards — check Star balance, reward level, and redeem rewards
Order history — view past orders and quickly reorder favorites
Session persistence — cookies saved at ~/.striderlabs/starbucks/cookies.json
Related MCP server: @striderlabs/mcp-chipotle
npm install -g @striderlabs/mcp-starbucks
npx playwright install chromiumAdd to your claude_desktop_config.json:
{
"mcpServers": {
"starbucks": {
"command": "striderlabs-mcp-starbucks",
"env": {
"STARBUCKS_EMAIL": "your-email@example.com",
"STARBUCKS_PASSWORD": "your-password"
}
}
}
}Credentials can also be passed directly via the starbucks_login tool.
Tool | Description |
| Check connection and login status |
| Authenticate with Starbucks credentials |
| Clear session cookies |
| Search menu by name, category, or dietary preference |
| Get full item details and customization options |
| Build a customized drink or food order |
| Add customized item to cart |
| View current cart with pricing |
| Find nearby Starbucks locations |
| Select pickup store |
| Submit mobile pickup order |
| Track order status and pickup time |
| Check Star balance and available rewards |
| Apply a reward to current order |
| View past orders |
| Quick reorder from a past order |
1. starbucks_status → check if logged in
2. starbucks_login → authenticate (if needed)
3. search_menu query="latte" → browse menu options
4. get_item_details itemId="hot-latte"
→ see customization options
5. customize_item itemId="hot-latte"
customizations={"size":"grande","milk":"oat","syrup":"vanilla"}
6. add_to_cart quantity=1 → add to cart
7. view_cart → review order
8. get_nearby_stores address="94105"
→ find pickup location
9. select_store storeId="sbux-1001"
10. get_rewards → check available rewards
11. redeem_reward rewardId="reward-123"
→ apply reward (optional)
12. place_order confirm=false → preview order
13. place_order confirm=true → submit order
14. get_order_status → track preparationshort (8 fl oz) — hot drinks only
tall (12 fl oz)
grande (16 fl oz)
venti_hot (20 fl oz) — hot drinks
venti_cold (24 fl oz) — cold drinks
2percent, nonfat, whole — standard, no charge
oat, almond, coconut, soy — +$0.70
signature (Starbucks Signature Espresso Roast)
blonde (Blonde Espresso Roast)
decaf
vanilla, caramel, hazelnut, toffee_nut, cinnamon_dolce, peppermint, sugar_free_vanilla, brown_sugar, mocha, white_mocha
hot, extra_hot, warm, kids_temp
standard, extra_foam, no_foam, light_foam
Browser automation: Playwright (Chromium) with stealth patches
Session persistence: Cookies stored at ~/.striderlabs/starbucks/cookies.json
Transport: MCP stdio
Ordering: Uses Starbucks web ordering API with Playwright automation fallback
Variable | Description |
| Starbucks account email (optional — can use starbucks_login tool) |
| Starbucks account password (optional) |
MIT — Strider Labs
Add the currently customized item to your cart. Call customize_item first. Optionally specify quantity.
| Name | Required | Description | Default |
|---|---|---|---|
| quantity | No | Number of this item to add (default: 1) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the mutation (adding to cart) but doesn't detail side effects, auth requirements, or rate limits. Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-loading the core action, no wasted words. Structure is efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 optional param, no output schema), the description is sufficient. It covers the main behavior and prerequisite (customize_item), though omits return value info.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes the quantity parameter (number, default 1). The description adds no further meaning beyond stating 'optionally specify quantity,' so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (add) and resource (currently customized item to cart). It distinguishes from sibling tools like customize_item (prior step) and place_order (next step).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call customize_item first and optionally specify quantity. Provides clear context for when to use this tool, though it doesn't discuss when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a customized drink or food order. Specify the item and your customization choices. Call add_to_cart afterwards to add it to your cart.
| Name | Required | Description | Default |
|---|---|---|---|
| itemId | Yes | Item ID from search_menu results | |
| customizations | No | Key-value pairs of customizations from get_item_details options. Examples: { "size": "grande", "milk": "oat", "syrup": "vanilla", "shots": "triple", "temperature": "extra_hot", "whipped_cream": "no_whip" } |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. Only says 'build' without explaining side effects, permissions, or what the tool returns. Lacks detail on whether it mutates state or returns an object.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with no wasted words. Purpose and next action clearly stated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description covers the tool's purpose and workflow. Could mention that the result is a customized item for cart, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. Description adds valuable examples for customizations key-value pairs, enhancing understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'build' and resource 'customized drink or food order'. Distinguishes from sibling tools like add_to_cart (subsequent step) and get_item_details (provides options).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to call add_to_cart afterwards, implying this tool does not add to cart. Provides workflow context but does not state when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details for a menu item including all available customization options (size, milk type, syrups, shots, temperature, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| itemId | Yes | Item ID from search_menu results (e.g., 'hot-latte', 'cold-brew', 'frap-mocha') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions that details include customization options but does not specify exact return fields (e.g., price, category) or behavior (e.g., error handling, data freshness). Adequate but lacks specificity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff. Efficiently communicates purpose and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even without output schema, the description should more thoroughly explain what 'full details' includes (e.g., price, availability) and clarify that this is pre-customization. Sibling tool customize_item implies further steps, but description does not connect the workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for itemId. The description adds context about customization options but does not add meaningful information beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves full details for a menu item, listing customization options. It distinguishes from sibling tools like search_menu (which lists items) and customize_item (which modifies).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied (use after search_menu to get details before customizing), but no explicit when-to-use or when-not-to-use guidance is provided. Does not mention alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find nearby Starbucks locations by address or zip code. Returns store names, addresses, hours, and supported features.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Address, city, or zip code to search near (e.g., '94105', '123 Main St, San Francisco CA') | |
| radius | No | Search radius in miles (default: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It only mentions return fields without stating side effects, authentication needs, or rate limits. As a read-like operation, it fails to assert read-only nature or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that efficiently conveys purpose and return information with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should detail return format more. It mentions fields but lacks info on edge cases (e.g., no results, error conditions). Adequate for a simple listing tool but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds minimal value by reinforcing 'address or zip code' but does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds nearby Starbucks locations by address or zip code, specifies the return fields (store names, addresses, hours, supported features), and distinguishes it from siblings like 'select_store' and 'search_menu'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., 'select_store' or 'search_menu') is provided. The description lacks explicit when/when-not conditions or comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View your past Starbucks mobile orders including items, customizations, store, and totals. Requires being logged in.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it is a view operation (read) and requires login, but lacks disclosure on pagination, data limits, rate limits, or behavior when not logged in.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a short note, front-loaded and free of extraneous content. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 0-parameter tool with no output schema, the description covers the main purpose and a key prerequisite. However, it omits details like order history depth or time range, which could be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema coverage, the description adds the login requirement as a precondition. While not a parameter, it provides context beyond the schema. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'View' and the resource 'past Starbucks mobile orders', listing specific included details (items, customizations, store, totals). It effectively differentiates from sibling tools like get_order_status which deals with current orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite (logged in) but does not provide guidance on when to use this tool versus alternatives like get_order_status or reorder_favorite. No explicit 'when not to use' or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Track the status of a Starbucks mobile order. Shows preparation status and estimated pickup time.
| Name | Required | Description | Default |
|---|---|---|---|
| orderId | No | Order ID to track. If omitted, shows the most recent order status. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description bears full burden. It discloses that the tool shows preparation status and pickup time, but does not specify if it's read-only, requires authentication, or any other behavioral traits like rate limits or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the key purpose and details. Every word earns its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers core functionality well. It is missing hints about return format (e.g., plain text vs structured) and preconditions like authentication, but these are minor given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and already explains the orderId parameter, including default behavior. The tool description adds no further semantic value beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: tracking a Starbucks mobile order status, showing preparation status and estimated pickup time. It uses a specific verb-resource pair and distinguishes from siblings like get_order_history or starbucks_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for tracking orders but lacks explicit when-to-use or when-not-to-use guidance. No mention of prerequisites like being authenticated or having an order placed, and no alternatives are suggested.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check your Starbucks Rewards Star balance, reward level (Green/Gold), and available rewards you can redeem. Requires being logged in.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the tool's read-only nature ('Check'), and the authentication requirement ('Requires being logged in'). No contradictions. It does not elaborate on error handling or rate limits, but for a simple read operation, the disclosure is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the core functionality, the second adds a key prerequisite. Every sentence adds value with no redundancy. It is efficiently front-loaded and appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description could be more explicit about return values (e.g., 'returns star count, level, and list of rewards'). However, it clearly describes what information is checked, and the sibling tools help contextualize. For a tool with zero parameters and low complexity, the description is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema description coverage is 100% (all parameters documented). The description implicitly tells the agent that no input is needed (just 'Check your...'). This exceeds the baseline of 3 for full coverage by adding context that no parameters are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Check' and specifies the resources: Starbucks Rewards Star balance, reward level (Green/Gold), and available rewards. It distinctly covers the tool's purpose and differentiates it from sibling tools like 'redeem_reward' which is for redeeming, not checking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear prerequisite ('Requires being logged in') and implies usage for checking rewards. However, it does not explicitly state when to use this tool versus alternatives or when not to use it. The context from sibling tool names helps, but the description itself lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit your cart as a mobile pickup order at the selected store. Set confirm=false to preview first, confirm=true to actually place it. Requires being logged in.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | Set true to place the order, false to preview only (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It states the login requirement and differentiates between preview and placement. However, it does not mention side effects (e.g., cart clearing), rate limits, or irreversibility. Adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, 28 words, front-loaded with the main purpose. Every sentence provides necessary information. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the essential purpose, parameter usage, and prerequisite. It could mention that items must be in cart, but it's largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description repeats the schema's explanation of the confirm parameter without adding new information. It adds no extra context beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Submit your cart as a mobile pickup order at the selected store.' It specifies the verb (submit) and resource (cart/pickup order), and distinguishes from sibling tools like add_to_cart and view_cart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage guidance: set confirm=false to preview, confirm=true to place, and requires being logged in. It does not explicitly state when not to use or list alternatives, but the prerequisite is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply a Starbucks Reward to your current cart. The reward will be used when you place the order.
| Name | Required | Description | Default |
|---|---|---|---|
| rewardId | Yes | Reward ID from get_rewards results |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description discloses basic behavior (applies reward, used on order) but omits side effects like reward status changes or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, front-loaded sentence with no wasted words; effectively communicates purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers basic action but lacks details on error handling or conditions like invalid rewards.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (one parameter described), and the description adds no extra meaning beyond the schema's text, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool applies a Starbucks Reward to the current cart and is used when placing an order, distinguishing it from siblings like get_rewards and place_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after selecting a reward and before placing an order but lacks explicit guidance on when to use or alternatives, e.g., not using if no reward is available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Quickly reorder from a past order — loads all items from a previous order back into your cart. Requires being logged in.
| Name | Required | Description | Default |
|---|---|---|---|
| orderId | Yes | Order ID from get_order_history to reorder |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions that items are loaded into the cart but does not disclose whether the current cart is cleared, if partial reordering is allowed, or what happens if items are no longer available. This lack of detail limits transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two clear sentences. It starts with the main purpose and adds the key prerequisite, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the purpose, prerequisite, and parameter source. It is nearly complete, though it could benefit from noting the effect on the existing cart.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description adds that orderId comes from get_order_history. This is helpful but does not add significant new meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('reorder from a past order') and the resource ('all items from a previous order back into your cart'). It distinguishes from siblings like add_to_cart by specifying it loads an entire past order, not individual items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes that login is required, providing some context. However, it does not explicitly state when to use this tool versus alternatives (e.g., add_to_cart for individual items) or when not to use it (e.g., if items are unavailable).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Select the Starbucks store for mobile pickup. Must be called before placing an order.
| Name | Required | Description | Default |
|---|---|---|---|
| storeId | Yes | Store ID from get_nearby_stores results |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description implies a mutating operation but does not detail behavioral traits like idempotency or side effects beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, clear and front-loaded with no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
All necessary context provided for a simple tool with one parameter and no output schema; the description is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter storeId has schema coverage 100% and description adds source context ('from get_nearby_stores results'), enhancing meaning beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('select store for mobile pickup') and resource ('Starbucks store'), distinguishing it from sibling tools like get_nearby_stores and place_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('Must be called before placing an order'), but lacks explicit when-not-to-use or alternatives, though context from siblings implies it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Authenticate with your Starbucks account using email and password. Required to place orders, access Starbucks Rewards, and view order history.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Starbucks account email address | ||
| password | Yes | Starbucks account password |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description must fully disclose behavior. It only states authentication method but fails to explain session lifetime, error handling, or side effects like setting cookies. This is a significant gap for a sensitive tool like login.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no redundant words. Efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Minimally adequate for a simple tool; covers core purpose but lacks details on session management, errors, or output. Given no output schema or annotations, additional context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description merely repeats 'email and password' without adding format or constraints beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Authenticate' and resource 'Starbucks account', clearly states it enables orders, rewards, and order history, distinguishing it from sibling tools like starbucks_logout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (required for placing orders, accessing rewards, and viewing history) but does not specify when not to use or provide alternatives. However, no other login tool exists among siblings, so context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Log out of Starbucks by clearing stored session cookies. Use this to reset authentication state.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It explicitly mentions 'clearing stored session cookies', which clearly explains the action and its effect on authentication state. It could add minor details like 'requires a prior login', but it is already transparent enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the action and purpose, and every word adds value. No unnecessary information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and a simple side effect (clearing cookies), the description covers the essential information: what it does and when to use it. It is complete for this straightforward function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so there is no need for additional parameter descriptions. The description correctly omits parameter details, and the baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Log out of Starbucks' and the mechanism 'clearing stored session cookies', which unambiguously distinguishes this tool from siblings like starbucks_login and starbucks_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes the guidance 'Use this to reset authentication state', which implicitly tells the agent when to invoke it (when a logout is needed). It lacks explicit when-not-to-use or alternatives, but for a simple logout function this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check connection status and whether you are logged in to Starbucks. Call this first to verify authentication before ordering.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description adequately conveys that the tool is a read-only check with no side effects, though it could be more explicit about the exact return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences with no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description fully addresses purpose and usage context, leaving no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The baseline score of 4 applies, and no additional param info is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks connection status and login state, distinguishing it from tools like starbucks_login or starbucks_logout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises calling this tool first to verify authentication before ordering, providing clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View all items currently in your cart with customizations, quantities, and pricing. Also shows the selected pickup store.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 accurately describes the read-only nature of viewing the cart and lists the specific information returned (items, customizations, quantities, pricing, pickup store). It does not disclose any side effects, but none are expected for a view operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loading the main purpose and providing specific details. Every word adds value; there is no redundancy or wasted space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description adequately explains what information is returned. However, it could mention whether the cart is empty or if items are grouped, but the current level is sufficient for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty with 100% coverage. The description adds context about what the tool shows, which is valuable beyond the schema. This is appropriate for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('View all items') and the resource ('your cart'), specifying the included details (customizations, quantities, pricing, selected pickup store). It distinguishes from siblings like add_to_cart, place_order, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used to inspect the current cart contents, which is a straightforward use case. No explicit alternatives or exclusions are needed given the tool's simple nature, but a brief note on when not to use (e.g., for placing an order) could improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0add_to_cartcustomize_itemget_item_detailsget_nearby_storesget_order_historyget_order_statusget_rewardsplace_orderredeem_rewardreorder_favoritesearch_menuselect_storestarbucks_loginstarbucks_logoutstarbucks_statusview_cartEach tool has a clearly distinct purpose: authentication, menu browsing, store selection, order customization/cart management, order placement/tracking, and rewards. No two tools overlap in functionality.
All tools follow a consistent verb_noun pattern in snake_case (e.g., add_to_cart, get_nearby_stores, place_order). Even the auth tools use the starbucks_ prefix consistently. No mixing of styles.
16 tools cover the full Starbucks mobile ordering experience without being excessive. Each tool serves a necessary function, from login to ordering to rewards.
The tool set covers the core ordering lifecycle: browse, select store, customize, add to cart, place order, track status, view history, and manage rewards. Minor gaps like removing cart items or canceling an order are missing, but the surface is nearly complete for typical usage.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
Hosted MCP for e-commerce: live product catalog, stock, and pricing for AI agents.
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
Hosted MCP server for live public-data APIs and Skills for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/markswendsen-code/mcp-starbucks'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
