The For Five Coffee MCP Server provides programmatic access to For Five Coffee's menu data through both MCP tools for AI assistants and a REST API for applications.
Access full menu data including all categories and items via the get_full_menu tool or /api/menu endpoint
Search menu items by name, description, or category using the search_menu_items tool or /api/menu/search?q={query} endpoint
Browse categories through the get_menu_categories tool or /api/menu/categories endpoint
Filter by category using the get_items_by_category tool or /api/menu/category/{name} endpoint
Integrate with AI assistants like Claude Desktop and Cursor through MCP protocol for natural language queries
Build web applications using the HTTP API with health checks, server info, and menu operations
Use in multiple programming languages with JavaScript and Python client examples
Handle common issues automatically with SSL fallback mechanisms and error handling
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., "@For Five Coffee MCP Server What coffee drinks does For Five Coffee have?"
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.
A Model Context Protocol (MCP) server that provides access to For Five Coffee menu data. Works with Claude Desktop, Cursor, and other MCP clients, plus provides a REST API.
git clone https://github.com/Kong/for-five-mcp.git
cd for-five-mcp
npm install
npm startThis starts both:
MCP Server (stdio) - for AI assistants
HTTP API (port 3000) - for web apps
Related MCP server: @striderlabs/mcp-shakeshack
Add to claude_desktop_config.json:
{
"mcpServers": {
"for-five-coffee": {
"command": "node",
"args": ["/path/to/for-five-mcp/server.js"]
}
}
}Option 1: Let Cursor start the server
Add to ~/.cursor/mcp.json:
{
"mcpServers": {
"for-five-coffee": {
"command": "node",
"args": ["/path/to/for-five-mcp/server.js"],
"env": {
"PORT": "3000"
}
}
}
}Option 2: Connect to already running server
If you're running npm start separately, add this to ~/.cursor/mcp.json:
{
"mcpServers": {
"for-five-coffee": {
"url": "http://localhost:3000/mcp",
"transport": "http"
}
}
}This connects Cursor to the running MCP server via HTTP JSON-RPC 2.0 transport.
"What coffee drinks does For Five Coffee have?"
"Search for pastries on the menu"
"What's the cheapest coffee option?"
"Show me all tea varieties"
# Get full menu
curl http://localhost:3000/api/menu
# Search for items
curl "http://localhost:3000/api/menu/search?q=latte"
# Get categories
curl http://localhost:3000/api/menu/categories// Fetch menu data
const response = await fetch('http://localhost:3000/api/menu');
const menu = await response.json();
// Search items
const search = await fetch('http://localhost:3000/api/menu/search?q=coffee');
const results = await search.json();import requests
# Get menu
menu = requests.get('http://localhost:3000/api/menu').json()
# Search
results = requests.get('http://localhost:3000/api/menu/search',
params={'q': 'latte'}).json()Endpoint | Description |
| Server info |
| Health check |
| Full menu |
| Search items |
| All categories |
| Items by category |
| MCP JSON-RPC 2.0 endpoint |
get_full_menu - Get complete menu
search_menu_items - Search by query
get_menu_categories - List categories
get_items_by_category - Filter by category
npm run dev # Start with auto-restart
npm test # Run all tests
npm run test:unit # Unit tests only
npm run test:http # HTTP API tests only
npm run test:mcp # MCP transport tests only
npm run test:integration # Integration tests only
npm run lint # Check code styleMCP not working?
Check the absolute path to server.js in your config
Restart your MCP client after config changes
Run npm start manually to test
HTTP API not responding?
Make sure server is running: npm start
Check port 3000 isn't in use: lsof -i :3000
Test: curl http://localhost:3000/health
No menu data?
Check internet connection
The server handles SSL issues automatically
Website structure may have changed (fallbacks included)
Apache 2.0
Get all menu items from a specific category
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | The category name to filter by |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool retrieves items but doesn't mention whether it's paginated, returns all items at once, requires authentication, has rate limits, or what happens if the category doesn't exist. This leaves significant behavioral gaps for a read 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 a single, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized for a simple tool and front-loads the core purpose immediately.
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 read tool with one parameter and no output schema, the description covers the basic purpose adequately. However, without annotations or output details, it lacks information about return format (e.g., list structure, item fields) and error handling, making it minimally viable but incomplete.
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 schema description coverage is 100% (the single parameter 'category' is fully documented in the schema), so the baseline is 3. The description adds no additional parameter information beyond what's already in the schema, such as category format examples or constraints.
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 ('Get') and resource ('menu items') with a specific scope ('from a specific category'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'search_menu_items' or 'get_full_menu', which prevents a perfect score.
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 no guidance on when to use this tool versus alternatives like 'search_menu_items' or 'get_full_menu'. It mentions filtering by category but doesn't explain when category-based filtering is preferred over other methods, leaving the agent with no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The tools are mostly distinct with clear purposes: get_full_menu retrieves everything, get_items_by_category filters by category, get_menu_categories lists categories only, and search_menu_items searches by name or category. However, get_items_by_category and search_menu_items could potentially overlap if searching by category, but their descriptions clarify the distinction—one lists all items in a category while the other searches within items.
All tool names follow a consistent verb_noun pattern using snake_case: get_full_menu, get_items_by_category, get_menu_categories, and search_menu_items. The verbs 'get' and 'search' are appropriately used and maintain a predictable naming convention throughout the set.
With 4 tools, this server is well-scoped for a coffee shop menu domain. Each tool serves a distinct function in retrieving or filtering menu data, and the count is appropriate—not too sparse or bloated—for the apparent purpose of exploring a menu.
The tool set covers the core read operations for a menu: fetching the full menu, filtering by category, listing categories, and searching items. A minor gap is the lack of tools for updating or managing the menu (e.g., add_item, update_price), but as a read-only surface for menu exploration, it is reasonably complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI-native restaurant discovery: verified/menu-indexed/discovered tiers + signed allergy-safety data.
Run your restaurant from an AI client: orders, menu, reports, refunds, payouts and staff.
The brain for restaurant costs, pricing, and true profit (read/edit menu, recipes, costs).
Live Google Maps business search, review, and photo data for AI agents over MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Kong/for-five-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
