How do I use Coffee Shop MCP?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Coffee Shop MCP What's on the menu? Then make me a large latte." 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.

Coffee Shop MCP

by HaswanthKurevella

Overview Schema Source Related Servers Discussions Admin

Python

Local

☕ Coffee Shop MCP

A hands-on Model Context Protocol (MCP) project. An LLM (VS Code Copilot in Agent mode) takes your coffee order and "makes" it by coordinating a Barista server and four machine servers.

Built with the official MCP Python SDK's FastMCP.

How it works

The LLM is the orchestrator. Servers are dumb specialists — none of them talk to each other. The Barista returns a recipe, and the LLM walks that recipe across the machines.

flowchart TD
    User([You]) --> LLM[VS Code Copilot<br/>orchestrator]
    LLM --> Barista[Barista server<br/>menu · orders · recipes]
    LLM --> Grinder[Grinder]
    LLM --> Brew[Brew unit]
    LLM --> Steamer[Steamer]
    LLM --> Dispenser[Dispenser]

Related MCP server: mcp-coffee

Order flow

sequenceDiagram
    participant U as You
    participant L as Copilot (LLM)
    participant B as Barista
    participant M as Machines

    U->>L: What's on the menu?
    L->>B: get_menu()
    B-->>L: 4 drinks
    U->>L: Large latte, extra shot
    L->>B: place_order(...)
    B-->>L: order id + recipe
    L->>M: grind → brew → steam → dispense
    L->>B: mark_order_ready()
    L-->>U: Your latte is ready ☕

Drink	Milk?	Notes
Espresso	No	Base shot
Americano	No	Espresso + hot water
Latte	Yes	Steamed milk, light foam
Cappuccino	Yes	Steamed milk, thick foam

Machines

Component	Job	Used by
Grinder	Beans → grounds	All
Brew unit	Pull the shot (+ Americano water)	All
Steamer	Texture milk	Latte, Cappuccino
Dispenser	Assemble the cup	All

Espresso skips the Steamer. Latte vs Cappuccino differ only in foam thickness.

Project layout

coffee-shop-mcp/
├── .vscode/mcp.json
└── src/coffee_shop_mcp/
    ├── server.py       # Barista
    ├── grinder.py
    ├── brew_unit.py
    ├── steamer.py
    └── dispenser.py

Setup

uv venv
uv add "mcp[cli]"

Test one server in the browser Inspector:

uv run mcp dev src/coffee_shop_mcp/server.py

Run in VS Code

.vscode/mcp.json:

{
  "servers": {
    "coffee-shop": { "type": "stdio", "command": "uv",
      "args": ["run", "python", "src/coffee_shop_mcp/server.py"] },
    "grinder":     { "type": "stdio", "command": "uv",
      "args": ["run", "python", "src/coffee_shop_mcp/grinder.py"] },
    "brew-unit":   { "type": "stdio", "command": "uv",
      "args": ["run", "python", "src/coffee_shop_mcp/brew_unit.py"] },
    "steamer":     { "type": "stdio", "command": "uv",
      "args": ["run", "python", "src/coffee_shop_mcp/steamer.py"] },
    "dispenser":   { "type": "stdio", "command": "uv",
      "args": ["run", "python", "src/coffee_shop_mcp/dispenser.py"] }
  }
}

Open the folder in VS Code, click Start on each server in mcp.json.
Open Copilot Chat → Agent mode.
Say: "What's on the menu? Then make me a large latte and run it on the machines."

Notes

In-memory only — orders reset when the server restarts.
Simulated hardware — machines return text results, nothing physical happens.
Idle servers get stopped/restarted by VS Code automatically — that's normal.

A learning project. ☕

Available Tools

7 tools

check_order_statusA

Check the current status of a placed order by its order ID. Returns the drink, size, current status, the full step-by-step status history with timestamps, and when it was placed. Use this to tell the customer whether their order is still being made or is ready.

ParametersJSON Schema

Name	Required	Description	Default
`order_id`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

No annotations are provided, so the description carries full burden. It discloses that the tool returns status, history with timestamps, and placement time, implying a read-only operation. It does not explicitly state lack of side effects or authorization needs, but the detail on return values compensates for a simple query 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?

The description is two sentences long, front-loads purpose, and efficiently covers input, output, and usage. No redundant information; every sentence adds value.

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 simple tool with one parameter and no output schema, the description fully explains the input (order_id) and output (drink, size, status, history, timestamp) and provides a usage scenario. It is complete enough for an agent to understand and invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, meaning the parameter `order_id` has no description in the schema. The description only mentions 'by its order ID' without providing format, length, or examples. Given the low coverage, the description should add more semantic context, but it does not.

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 specifies the action (check status) and resource (placed order by ID). It distinguishes from sibling tools like `update_order_status` and `mark_order_ready` by stating it is for querying, not modifying. The explicit use case 'tell the customer whether their order is still being made or is ready' further solidifies its unique purpose.

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 ('to tell the customer whether their order is still being made or is ready'), providing clear context. It does not explicitly mention when not to use it or alternatives, but the purpose is specific enough that the agent can 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.

get_customization_optionsA

Get the available customization options for a specific drink (size, extra shot, etc.). Call this after the customer has chosen a drink from the menu, so you know what to ask them about. The drink argument must be a drink name from the menu.

ParametersJSON Schema

Name	Required	Description	Default
`drink`	Yes

TDQS

A4.2/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. Describes return as customization options but does not detail structure or side effects. Since it's read-only, the main behavior is clear, but more detail on return format would help.

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 concise sentences with no fluff. Front-loaded with purpose and usage. Every part earns its place.

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 one required parameter and no output schema, the description covers purpose, when to call, and parameter constraint. It could mention output format but is sufficient for a simple tool.

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?

Only one parameter (drink). Description adds that it must be a drink name from the menu, which is valuable beyond the schema. Schema has 0% description coverage, so description compensates well.

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?

Clearly states the tool retrieves customization options for a specific drink, with examples like size and extra shot. Distinguishes from siblings like get_menu or place_order.

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?

Explicitly says to call after the customer chooses a drink from the menu, providing clear context. Does not explicitly say when not to use, but the instruction implies appropriate usage.

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

get_menuA

Get the coffee shop's current menu: every drink we can make, whether it contains milk, and a short description. Call this FIRST to see what the customer can order. Do not guess drinks or read source files.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.8/5.0

Behavior4/5

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

No annotations exist, so description carries full burden. It accurately describes the read-only retrieval of menu data. While it doesn't mention caching or latency, the straightforward nature of the tool makes this acceptable.

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 that are perfectly efficient: first sentence states purpose and output, second provides usage guidance. No unnecessary words.

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?

Given the simple 0-parameter tool with an output schema, the description sufficiently covers what the tool does, what it returns, and when to use it. No gaps for an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and 100% schema coverage, so the description doesn't need to add parameter details. It adds value by clarifying the purpose and output.

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 retrieves the coffee shop's current menu, listing specific output fields (drinks, milk info, description). It distinguishes itself from siblings by advising 'Call this FIRST' and 'Do not guess drinks or read source files'.

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?

Explicitly tells agents to use this tool first ('Call this FIRST') and provides a constraint ('Do not guess drinks or read source files'), making the usage context unambiguous.

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

mark_order_readyA

Mark an order as ready for collection. Call this after ALL machine steps in the recipe have been completed successfully. Flips status to 'ready', records the completion timestamp, and closes the lifecycle. After calling this, tell the customer their order is ready to collect.

ParametersJSON Schema

Name	Required	Description	Default
`order_id`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

Describes what the tool does: flips status to 'ready', records timestamp, and closes lifecycle. No annotations provided, so description carries full burden; it does so adequately without contradictions.

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, front-loaded with purpose, no wasted words. Each sentence adds value: what, when, effect, and post-call action.

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?

Given the tool's simplicity (1 param, no output schema), the description covers all essential aspects: purpose, prerequisite, behavior, and follow-up. Complete for its complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter `order_id` with no schema description. The tool description does not add any meaning beyond the schema, such as format or constraints. With 0% schema coverage, the description should compensate but does not.

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 marks an order as ready for collection, with a specific verb and resource. It also distinguishes from sibling tools like 'update_order_status' by specifying the exact action and context.

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?

Explicitly says 'Call this after ALL machine steps in the recipe have been completed successfully,' providing a clear prerequisite. Also advises to inform the customer after calling. No explicit exclusions or alternatives, but sufficient guidance.

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

pingA

Check that the Barista MCP server is alive and responding.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.9/5.0

Behavior5/5

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

With no parameters and no annotations, the description fully explains the tool's read-only, side-effect-free behavior. No contradictions.

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?

Single sentence, directly to the point, no wasted words.

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?

Given zero parameters and an output schema, the description fully covers the tool's purpose and behavior. Nothing 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?

Zero parameters, so baseline 4. No additional parameter information needed.

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 checks server liveness, distinguishing it from order-based sibling tools. Verb 'check' and resource 'Barista MCP server' are explicit.

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?

No alternative tools exist for health checks, and the description implicitly indicates it's a diagnostic tool with no usage restrictions.

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

place_orderA

Place a coffee order. Call this once the customer has chosen a drink and confirmed their customizations. Returns an order ID and the recipe (the ordered list of machine steps to make the drink). drink must be on the menu; size is small/medium/large; extra_shot adds a second shot.

ParametersJSON Schema

Name	Required	Default
`size`	No	medium
`drink`	Yes
`extra_shot`	No

TDQS

A4.4/5.0

Behavior4/5

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

Without annotations, description carries full burden. It details return values (order ID and recipe), constraints (drink on menu, size options), and extra_shot behavior. Lacks side effects like cost or inventory, but good overall.

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?

Three sentences: purpose+timing, return values, parameter details. No wasted words, front-loaded with key info.

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?

Covers purpose, when to use, parameters, return values. Lacks error handling or success criteria, but for a simple order tool with 3 params and no output schema, it's fairly 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?

Schema has 0% description coverage, so description compensates. It explains drink must be on menu, size is small/medium/large, extra_shot adds a second shot. Could be more precise about size values, but adds significant meaning.

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?

Description clearly states 'Place a coffee order' with specific verb and resource. It distinguishes from sibling tools like check_order_status and get_menu by focusing on order placement after customer confirms customizations.

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?

Explicitly says 'Call this once the customer has chosen a drink and confirmed their customizations', providing clear context. Doesn't explicitly state when not to use, but alternatives are implied by sibling tool names.

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

update_order_statusA

Update the current machine step for an in-progress order. Call this as you BEGIN each step in the recipe: 'grinding', 'brewing', 'steaming' (milk drinks only), 'dispensing'. Do NOT use this for 'pending' (set by place_order) or 'ready' (set by mark_order_ready). Calling 'steaming' on a non-milk drink is a validation error.

ParametersJSON Schema

Name	Required	Description	Default
`status`	Yes
`order_id`	Yes

TDQS

A4.9/5.0

Behavior5/5

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

No annotations exist, so the description carries full burden. It discloses the behavioral trait of updating the machine step, enumerates allowed statuses, and explicitly warns about validation errors for invalid status-drink combinations.

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?

Three sentences: first states purpose, second lists valid steps, third gives exclusions and error conditions. Every sentence adds value; no redundancy or filler.

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 simple update tool with no output schema, the description is nearly complete. It covers inputs and constraints. A minor gap: it doesn't describe the return value (e.g., success indicator or updated order), but this is not critical for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description adds full context: it lists the exact allowed values for 'status' (grinding, brewing, steaming, dispensing) and explains the constraint linking 'steaming' to milk drinks. It clarifies that 'order_id' is an identifier without format details, which is acceptable.

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 'update' and the resource 'current machine step for an in-progress order'. It lists valid statuses ('grinding', 'brewing', 'steaming', 'dispensing') and distinguishes from siblings like 'mark_order_ready' and 'place_order' by explicitly saying not to use for 'pending' or 'ready'.

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?

Provides explicit when (as you BEGIN each step) and when-not (for 'pending' or 'ready'). Names alternative tools (place_order, mark_order_ready) and flags a specific validation error ('steaming' on non-milk drinks).

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

7 tool updatesv0.1.0Jul 10, 2026
- First observedcheck_order_status
- First observedget_customization_options
- First observedget_menu
- First observedmark_order_ready
- First observedping
- First observedplace_order
- First observedupdate_order_status

Deploy Server

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

TDQS

A4.5/5.0

Scored 2026-07-10 20:25 across 7 tools

Disambiguation5/5

Each tool targets a distinct aspect of the coffee ordering workflow: menu, customization, placing, status, step updates, readiness, and health check. There is no overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with underscores (e.g., get_menu, place_order). 'ping' is a standard exception for health checks and does not disrupt the pattern.

Tool Count5/5

With 7 tools, the set is well-scoped for a coffee shop ordering system. Each tool serves a clear need without redundancy or missing critical functionality.

Completeness4/5

The tool set covers the full order lifecycle: menu browsing, customization, placing, status tracking, step updates, and marking ready. Minor gaps like cancellation or order listing are absent but not essential for the core workflow.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

llm-orchestration-agent-mcp
ai.getvda
LLM Orchestration Agent (Mcp)
Agent Orchestration Autonomous Agents
1
llm-orchestration-agent-2
ai.getvda
MCP-Native LLM Orchestration Agent
Agent Orchestration AI & Machine Learning
1
llm-orchestration-mcp-agent
ai.getvda
LLM Orchestration MCP Agent
Autonomous Agents Agent Orchestration AI & Machine Learning
1
AgentMarketplace A
io.github.raditotev
MCP Server for an Agent Task Marketplace
Autonomous Agents Agent Orchestration
221

Related MCP Servers

meticulous-mcp
Home Automation & IoT
NatiCha
A
license
A
quality
D
maintenance
MCP server for controlling Meticulous espresso machines via Claude and other AI clients.
Updated 7 months ago (2026-01-31 17:29 UTC)
22
109 npm
MIT
mcp-coffee
E-commerce & Retail Customer Support
Ira-Ivaa
F
license
Not graded
quality
B
maintenance
Enables coffee shop order management via MCP, including menu lookup, order creation, and status tracking.
Updated 3 months ago (2026-06-23 08:03 UTC)
-
GRACE Orchestrator MCP
Agent Orchestration Autonomous Agents
Artemyx-DataScientist
F
license
Not graded
quality
B
maintenance
MCP server orchestrating local multi-agent workflows with gated lifecycle, handoff events, and host-level continuation.
Updated 2 months ago (2026-07-28 13:36 UTC)
-
cafe-mcp-server
Search
hanluOMH
F
license
A
quality
B
maintenance
MCP server that recommends coffee based on preferences (mood, milk, caffeine, temperature) from a static menu; includes tools for listing menu, recommending, and explaining recommendations.
Updated a month ago (2026-08-10 17:00 UTC)
3
-

☕ Coffee Shop MCP

How it works

Order flow

Menu

Machines

Project layout

Setup

Run in VS Code

Notes

Available Tools

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers