parsley-mcp
# Parsley MCP Server
An [MCP](https://modelcontextprotocol.io/) server that gives AI assistants access to [Parsley](https://parsleycooks.com) — recipe management, menu planning, and event operations for food service.
## Hosted
A hosted version is available at [parsley.vein.io](https://parsley.vein.io). Connect any MCP client using a Remote transport with your Parsley API token, passed either as a Bearer token in the `Authorization` header or as a `?token=` query parameter.
Read-only endpoint:
```
https://parsley.vein.io/mcp
```
Read-write endpoint (includes event and user management):
```
https://parsley.vein.io/mcp/write
```
Demo endpoint (no auth required, mock data):
```
https://parsley.vein.io/mcp/demo
```
### Filtering tools
Pass `?tools=a,b,c` to register only the tools you need, trimming the tool schema from the context window:
```
https://parsley.vein.io/mcp?tools=list_menu_items,get_recipe,list_events
```
Unknown names return 400. Works on `/mcp`, `/mcp/write`, and `/mcp/demo`.
## Local (stdio)
Run locally via npx:
```bash
PARSLEY_API_TOKEN=your_token npx parsley-mcp
```
Or with write access:
```bash
PARSLEY_API_TOKEN=your_token npx parsley-mcp --enable-writes
```
### Claude Desktop configuration
```json
{
"mcpServers": {
"parsley": {
"command": "npx",
"args": ["parsley-mcp"],
"env": {
"PARSLEY_API_TOKEN": "your_token"
}
}
}
}
```
## Tools
**Read-only:** list/get menu items, menus, recipes, ingredients, events, chef users, chef tags, serving stations, commissary reports, and CDN access tokens.
**Write (opt-in):** create/update events, push sales/waste/leftover data, create/update/delete chef users, and manage chef tags.
## Development
```bash
npm install
npm run build
npm start
```
Deploy to Cloudflare Workers:
```bash
npm run deploy
```
## Parsley API
This server wraps the [Parsley public API](https://app.swaggerhub.com/apis-docs/parsleysoftware/parsley).
## License
MIT
TDQS
Scored across 19 tools
Each tool targets a distinct resource+action, and the list-vs-search pairs (list_menus/search_menus, list_ingredients/search_ingredients, list_menu_items/search_menu_items) are clearly differentiated by their descriptions. The only mild overlap is between get_menu, get_menu_item, and get_recipe, but these map to genuinely different entities so an agent can select correctly.
Every tool follows a clean snake_case verb_noun pattern (list_/search_/get_/clear_/configure_). The verbs are used consistently: list_* for enumeration, search_* for fuzzy query, get_* for single-entity fetch, matching the description semantics.
19 tools is at the higher end but justified given the domain spans menus, recipes, ingredients, menu items, events, plus utility/auth tools (configure_token, clear_cache, get_access_token). Nothing feels redundant given the list/search/detail triad per entity.
The surface covers read operations comprehensively across all entities (list, search, get for menus/ingredients/menu items, plus recipes, events, stations, chef tags/users, report). There are no write/update/delete operations, but the server appears intentionally read-only (24h GET cache), and only minor detail getters (e.g. serving station, chef user) are absent.