Starbucks MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool has a distinct purpose: auth flows, favorite management, order placement (favorite vs custom), order confirmation/cancellation, and menu lookup. No two tools overlap in a way that would confuse an agent.
Naming Consistency5/5
All tool names follow a consistent pattern of action + 'starbucks' + target (e.g., login_starbucks, list_starbucks_favorites, order_starbucks_custom). The naming is uniform and predictable across the entire set.
Tool Count5/5
10 tools is well-scoped for a Starbucks ordering and favorites management server. The count covers the essential workflows without being bloated or thin.
Completeness4/5
The toolset covers the core lifecycle: auth, menu access, placing and managing orders, and managing favorites. Minor gaps exist such as no delete/update favorite and no order history, but these are not critical for the primary ordering flow.
Average 3.7/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits like authentication requirements, duplicate handling, or return value. It only states 'Save a new Starbucks favorite order' without any additional context, leaving the agent unaware of side effects 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence containing only essential information, with no redundancy. It is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is too sparse. It fails to mention potential conflicts (e.g., duplicate names), authentication needs, or what the response will look like, making it incomplete for an agent to use reliably.
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?
The input schema already documents both parameters with descriptions ('Name for this favorite', 'Items in this favorite order'). The tool description adds no further parameter semantics, so it meets the baseline expectation given 100% schema coverage.
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 uses the specific verb 'Save' and identifies the resource as a 'new Starbucks favorite order', which clearly distinguishes it from sibling tools like list, order, and cancel. It communicates the core function in a single, unambiguous phrase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool relative to alternatives, such as prerequisites (e.g., logging in first) or conditions that would make it inappropriate. There is no mention of when this tool is preferred over order_starbucks_favorite or other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral details beyond 'check'. It does not state whether the tool is read-only, what it returns, or any side effects. For a tool that likely validates authentication state, this minimal disclosure is insufficient without annotation support.
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?
The description is a single, front-loaded sentence with no filler. Every word adds value, making it appropriately concise and structured for a trivial check operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 params, no output schema), the description is minimally adequate but leaves out the result type (e.g., boolean or status object). Without an output schema, a brief mention of the return value would improve completeness, so a mid-range score is appropriate.
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?
The input schema has zero parameters, so there is nothing to explain. The baseline for 0 params is 4, and the description correctly avoids adding unnecessary parameter details.
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 'Check if Starbucks session is authenticated' uses a specific verb ('Check') and resource ('Starbucks session'), clearly distinguishing this from sibling tools like login_starbucks or order_starbucks_favorite. It is unambiguous and immediately conveys the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description only states the purpose, leaving the agent to infer the proper context (e.g., before ordering or after login). No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It states the action ('Confirm and place') but does not disclose whether placing the order is irreversible, triggers a charge, or what the response/confirmation looks like. This is a significant gap for a mutating tool that finalizes a transaction.
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 one sentence, front-loaded with the action, and every word contributes meaning. It is suitably concise, though it could include a brief note on prerequisites or effects without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is too sparse. It lacks critical context such as the prerequisite of having a pending order, the irreversibility of placing the order, and any confirmation details. The empty input schema does not compensate for these omissions.
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?
The tool has zero parameters, so the schema is trivially complete at 100% coverage. The description does not need to explain parameters, and per the guidelines, a baseline of 4 is appropriate for zero-parameter tools.
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 uses a specific verb 'Confirm and place' with a clear resource 'a pending Starbucks order', and the phrase 'after review' distinguishes this from siblings like cancel_starbucks_order or order_starbucks_favorite. It uniquely identifies the tool's role in finalizing an already-created order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('after review') but provides no explicit when-to-use or exclusions, and does not mention alternatives like cancel_starbucks_order for changing one's mind. It gives a hint that this is the final step in an order workflow, but the guidance is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only restates the operation and does not mention authentication requirements, default location behavior, response format, or error handling.
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?
The description is a single, concise sentence that is front-loaded with the main action and includes the search variant. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has low complexity (2 optional params, no output schema), but the description omits potentially important context such as whether authentication is required and the handling of default location (though the schema covers it). Without annotations or output schema, the description is adequate but not fully complete.
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% and both parameters are fully described. The description adds minimal context by referencing query and location usage, but does not significantly enhance the schema's own descriptions. Baseline 3 applies.
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 clearly states the tool's function with a specific verb ('Get') and resource ('menu'), and also mentions the optional search capability. It is distinctly different from sibling tools like login/order/auth tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving menu items, but does not explicitly state when to use this tool versus alternatives (e.g., ordering tools). No exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation but does not disclose whether login is required, what the output structure looks like, or any rate limits or side effects. It is not misleading but severely minimal.
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?
The description is a single clear sentence with no unnecessary words. It is front-loaded with the action verb and resource, making it immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 params, no output schema), the description provides the basic purpose. However, it lacks context such as the need for prior login (given sibling auth tools) and what information is returned (e.g., favorite names, IDs). This is adequate but leaves gaps for an agent.
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?
The tool has 0 parameters, and the schema is empty. The description's inclusion of 'all' clarifies that there are no filtering parameters, adding a small but useful semantic beyond the schema. Baseline for 0 params is 4, which is appropriate here.
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 uses a specific verb 'list' and a clear resource 'saved Starbucks favorite orders'. It distinguishes from sibling tools like add_starbucks_favorite and order_starbucks_favorite by indicating a read-only retrieval action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. The description does not mention that listing favorites is a prerequisite for ordering or that authentication is required, leaving the agent to infer usage from sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description carries the full burden for behavioral disclosure. It only states the action without explaining consequences (e.g., irreversibility, side effects, authentication requirements, or what happens if the order is not pending). For a destructive operation, this is a significant gap.
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?
The description is a single, front-loaded sentence with no wasted words. It is concise and directly conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a mutation tool with no annotations, no output schema, and an empty input schema, the description is insufficient. It fails to explain how the order to cancel is identified or any behavioral context (e.g., whether it cancels the most recent order, requires login, etc.). The empty schema raises critical questions that the description leaves unanswered.
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?
The input schema is empty (0 parameters), so there is no parameter semantics to explain. The baseline for 0 params is 4, and the description does not need to add parameter information since none exist.
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 clearly states the verb (Cancel), resource (Starbucks order), and scope (pending). It distinguishes from sibling tools like confirm_starbucks_order and order_starbucks_favorite by specifying the action and target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for pending orders, providing some context. However, it does not explicitly state when to use this tool vs alternatives, nor any prerequisites like authentication. The 'pending' qualifier gives partial guidance but no exclusions or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of disclosing side effects and workflow. It fails to mention that placing an order likely triggers a purchase, requires authentication, or that confirmation may be needed (given siblings like confirm_starbucks_order). The menu prerequisite is a useful constraint, but the description omits critical behavioral context about order placement and consequences.
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?
The description is two sentences, front-loaded with the primary action, and includes a crucial tip in an attention-grabbing way. Every word earns its place; no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool operates within a complex workflow (login, order, confirm, cancel), yet the description provides no context about authentication, order confirmation, or cancellation. It does not mention that confirm_starbucks_order may be required after placing the order. While the schema covers parameter structure, the description fails to convey the surrounding process, making it incomplete for an agent to use correctly.
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 description coverage is 100%, so the baseline is 3. The description adds minimal extra meaning beyond the schema—it merely mentions 'specific drinks and food' and the menu prerequisite, which is more of a usage guideline than parameter semantics. The schema already provides useful examples and definitions.
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 clearly states the action ('Place a custom Starbucks order') and specifies the content ('specific drinks and food'). It distinguishes itself from sibling 'order_starbucks_favorite' by explicitly labeling this as 'custom', making the purpose unambiguous.
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 provides an explicit prerequisite: 'Always use get_starbucks_menu first to get exact item names before ordering.' This gives clear guidance on a necessary precondition. However, it does not state when not to use this tool (e.g., for favorites) or explicitly contrast with siblings, so it misses the full 'when-not' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses a potential failure mode (item names not found) and suggests recovery, which is valuable. However, it does not mention side effects like payment, confirmation, or how order status is returned, leaving gaps for a mutation tool.
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?
Two sentences, with the primary action front-loaded and the troubleshooting tip highlighted with 'IMPORTANT'. Every word earns its place; no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides a useful failure-recovery note, but the tool lacks an output schema and does not explain what happens after ordering (e.g., auto-confirm, cancellation, or status return). Sibling tools like confirm_starbucks_order and cancel_starbucks_order suggest additional steps, yet the description does not guide the agent on these dependencies.
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% with descriptions for both parameters. The description adds value over the schema by giving examples of favorite names ('Morning Coffee Run', 'Breakfast'), which helps infer the expected format. The location parameter is mentioned in schema and not expanded, but the description's examples enhance understanding.
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 clearly states the action: 'Order a saved Starbucks favorite' with concrete examples. It distinguishes from siblings like order_starbucks_custom by focusing on 'saved' favorites, and from list_starbucks_favorites by indicating an ordering action.
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?
It gives a clear when-to-use context ('Order a saved favorite') and a specific conditional fallback: 'If order fails due to item names not found, use get_starbucks_menu first'. However, it does not explicitly contrast with order_starbucks_custom or mention prerequisites like login, but the siblings signal these are available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a key trait: it requires a prior manual login in the browser. However, it does not describe side effects like session creation, token handling, or failure behavior, leaving the agent with limited understanding of the tool's internal actions.
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?
The description is a single, clear sentence with no wasted words. The key information (action, resource, precondition) is front-loaded, making it highly efficient.
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?
For a zero-parameter tool with no output schema, the description provides essential context: what it does and when to use it. The precondition 'after user has logged in manually in the browser' is critical. However, it does not cover edge cases like calling without the prerequisite, but given its simplicity, it is reasonably complete.
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?
The tool has zero parameters, so there is nothing to explain. The description adds no parameter details, but none are needed. Per the rubric, 0 params merits a baseline of 4, and the description meets this 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 uses a specific verb 'complete' with the resource 'Starbucks login' and specifies the precondition 'after user has logged in manually in the browser.' This clearly differentiates it from siblings like login_starbucks and check_starbucks_auth, making the purpose unambiguous.
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 explicitly states the condition for use: after the user has manually logged in via the browser. This implies a follow-up step and provides a clear prerequisite. It does not explicitly name alternative tools, but the sibling context makes the usage scenario evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the key behavior ('Open browser') and the conditions under which it is used. It does not elaborate on possible side effects or post-conditions, but for a simple browser-opening tool, this is adequate transparency.
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?
The description is a single, concise sentence that is front-loaded with the action ('Open browser') and purpose. Every word earns its place, with no redundant or excessive information.
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 the tool's simplicity (no parameters, no output schema) and its role as one step in a larger authentication flow (with sibling tools like complete_starbucks_login), the description provides enough context to understand what the tool does and when to invoke it. It could mention that it requires user interaction, but that is implied by 'login'.
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?
The input schema has zero parameters, and schema coverage is 100% (trivially). According to the rubric, baseline is 4 for zero parameters. The description does not need to explain parameters and does not add any, which 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 uses a specific verb 'Open browser' and clearly states the resource ('Starbucks login') and purpose ('first-time setup or to refresh expired session'). This distinguishes it from sibling tools like complete_starbucks_login or check_starbucks_auth by indicating it initiates the login flow by opening a browser.
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 explicitly states when to use the tool ('first-time setup or to refresh expired session'), providing clear context. It does not mention explicit exclusions or alternative tools, but the given context is sufficient for an agent to decide to use this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![starbucks-mcp-server MCP server](https://glama.ai/mcp/servers/deanwenstrand/starbucks-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/deanwenstrand/starbucks-mcp-server)

Score Badge

Copy to your README.md:

[![starbucks-mcp-server MCP server](https://glama.ai/mcp/servers/deanwenstrand/starbucks-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/deanwenstrand/starbucks-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/deanwenstrand/starbucks-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server