Click on "Deploy 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., "@Paprika MCP Server find recipes with chicken and broccoli"
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 for the Paprika Recipe Manager, allowing AI assistants to search, read, and update recipes.
Search Recipes: Search across recipe titles, ingredients, categories, directions, and notes with context
Read Recipes: Get full recipe data including all metadata, ingredients, and directions
Update Recipes: Safely update recipe fields using find/replace (requires user confirmation)
Related MCP server: Mealie MCP Server
Python 3.10 or higher (Python 3.13 recommended)
A Paprika account with recipes
Node.js (for pre-commit hooks, optional)
Run the setup script to install everything and configure credentials:
cd paprika-mcp
./setup.shThis will:
Install paprika-mcp with dependencies
Set up pre-commit hooks (if npm available)
If you prefer manual setup:
cd ../paprika-recipes
python3 -m venv .venv
source .venv/bin/activate
pip install -e .
deactivatecd ../paprika-mcp
python3 -m venv .venv
source .venv/bin/activate
pip install -e ".[dev]"Option 1: Interactive setup
source .venv/bin/activate
paprika-mcp setupOption 2: Manual config file
Create ~/.paprika-mcp/config.json:
{
"email": "your@email.com",
"password": "yourpassword"
}Set permissions:
chmod 600 ~/.paprika-mcp/config.jsonOption 3: Environment variables
export PAPRIKA_EMAIL="your@email.com"
export PAPRIKA_PASSWORD="yourpassword"The server uses a credential flow designed for MCP stdio transport:
Priority order:
PAPRIKA_EMAIL and PAPRIKA_PASSWORD environment variables
~/.paprika-mcp/config.json file
Note: This server manages credentials independently from the paprika-recipes CLI tool's keyring storage. This simplifies the credential flow for MCP stdio transport where the process is spawned by the AI app.
If you have Paprika for Mac installed, the fork of the paprika-recipes Python package should automatically create a suitable User-Agent string. Otherwise, you might have to set the PAPRIKA_USER_AGENT environment variable or the "user_agent" property in config.json.
Add to your MCP client configuration (e.g., Claude Desktop's ~/Library/Application Support/Claude/claude_desktop_config.json):
{
"mcpServers": {
"paprika": {
"command": "/Users/yourusername/Developer/paprika-mcp/.venv/bin/paprika-mcp"
}
}
}Or use environment variables:
{
"mcpServers": {
"paprika": {
"command": "/Users/yourusername/Developer/paprika-mcp/.venv/bin/paprika-mcp",
"env": {
"PAPRIKA_EMAIL": "your@email.com",
"PAPRIKA_PASSWORD": "yourpassword"
}
}
}
}Format a fraction string to unicode fraction characters. This tool is local-only and doesn't require Paprika server connectivity - useful for testing.
Parameters:
fraction (required): Fraction in the form "numerator/denominator" (e.g., "1/4", " 31 / 200 "), or already formatted unicode
Features:
Handles already-formatted unicode fractions (returns them as-is)
Strips whitespace from input
Converts common fractions to dedicated unicode characters
Composes complex fractions using superscript/subscript digits
Examples:
{
"fraction": "1/4"
}Returns: ¼
{
"fraction": " 31 / 200 "
}Returns: ³¹⁄₂₀₀ (whitespace stripped)
{
"fraction": "¼"
}Returns: ¼ (already formatted, returned as-is)
Common fractions (1/4, 1/2, 3/4, 1/3, 2/3, etc.) use dedicated Unicode characters. Complex fractions are composed using superscript numerator + fraction slash (⁄) + subscript denominator.
Search for recipes by text across multiple fields.
Parameters:
query (required): Text to search for
fields (optional): Array of fields to search in: ["name", "ingredients", "categories", "directions", "notes"]
context_lines (optional): Number of context lines around matches (default: 2)
Example:
{
"query": "chicken",
"fields": ["name", "ingredients"],
"context_lines": 2
}Read full recipe data by ID or title.
Parameters:
id or title (one required): Recipe UUID or exact recipe name
Note: Title matching uses Unicode normalization (NFD), so it works correctly with accented characters regardless of their unicode representation (e.g., "café" will match "café").
Example:
{
"id": "RECIPE-UUID-HERE"
}or
{
"title": "Chocolate Chip Cookies"
}You can provide context to the AI about how you want it to work with your recipes by creating a ~/.paprika-mcp/prompt.md file. This will be automatically loaded as a prompt when the MCP server starts.
Example prompt file:
# Recipe Management Preferences
- Always preserve source URLs and attribution
- Prefer metric measurements
- I'm cooking for 2 people typically
- I avoid peanuts (allergy)
- Categorize using: Breakfast, Lunch, Dinner, Desserts, SnacksSee prompt.example.md for a complete template.
Update a recipe field using find/replace.
⚠️ DANGEROUS: This tool modifies recipe data. User confirmation is recommended before execution.
Parameters:
id (required): Recipe UUID
field (required): Field to update (name, ingredients, directions, notes, etc.)
find (required): Text to find
replace (required): Text to replace with
regex (optional): Treat find pattern as regex (default: false)
Example:
{
"id": "RECIPE-UUID-HERE",
"field": "ingredients",
"find": "1 cup sugar",
"replace": "3/4 cup sugar"
}The package is installed in editable mode (pip install -e .), so:
✓ No rebuild needed: Changes to .py files are immediately available
⚠️ Restart required: MCP clients cache the stdio process - restart VS Code or your MCP client to pick up changes
↻ Reinstall needed: Only for pyproject.toml or entry point changes
Force reinstall if needed:
.venv/bin/pip install -e . --force-reinstall --no-depsPre-commit hooks run automatically via Husky when you commit. They:
Only run on staged Python files
Run isort, black, and ruff
Auto-fix issues and re-stage files
To install hooks manually:
npm installCredentials are stored in plain text in ~/.paprika-mcp/config.json
Environment variables (PAPRIKA_EMAIL, PAPRIKA_PASSWORD) are also supported
MIT
Built on top of paprika-recipes originally by Adam Coddington.
Format a fraction string to unicode fraction characters. Converts simple fractions like '1/4' to '¼' or complex ones like '31/200' to '³¹⁄₂₀₀'. Handles already-formatted unicode fractions and strips whitespace. This tool does not require server connectivity and can be used for testing.
| Name | Required | Description | Default |
|---|---|---|---|
| fraction | Yes | Fraction in the form 'numerator/denominator' (e.g., '1/4', ' 31 / 200 '), or already formatted unicode |
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 effectively describes key behaviors: conversion of simple and complex fractions, handling of pre-formatted unicode, whitespace stripping, and no server connectivity requirement. However, it does not mention error handling, performance limits, or output format details, leaving some gaps.
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 appropriately sized and front-loaded, with every sentence earning its place. It starts with the core purpose, provides examples, handles edge cases, and adds operational context (no server connectivity, testing use) efficiently in a few concise sentences without redundancy.
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 moderate complexity (single parameter, no output schema, no annotations), the description is mostly complete. It covers purpose, usage, and key behaviors, but lacks details on error handling, output format, or performance considerations. With no output schema, some information about return values would be beneficial, though not strictly required.
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%, so the schema already documents the single parameter 'fraction' with its type and format. The description adds minimal value beyond the schema by providing examples ('1/4', ' 31 / 200 ') and mentioning whitespace stripping, but does not elaborate on parameter semantics significantly. Baseline 3 is appropriate as the schema does the heavy lifting.
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 with specific verbs ('format', 'converts') and resources ('fraction string to unicode fraction characters'), distinguishing it from sibling tools like read_recipe, search_recipes, and update_recipe. It provides concrete examples ('1/4' to '¼') and handles edge cases like already-formatted fractions and whitespace stripping.
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 states when to use this tool ('format a fraction string to unicode fraction characters') and mentions it can handle already-formatted fractions, but does not specify when not to use it or provide alternatives to sibling tools. The context is clear but lacks explicit exclusions or comparisons with other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read full recipe data by ID or exact title. Returns all recipe fields including categories, times, ingredients, directions, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Recipe UID to read | |
| title | No | Exact recipe title to read (alternative to id) |
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 discloses that the tool reads data (implying a read-only operation) and returns comprehensive fields, but lacks details on error handling (e.g., what happens if ID/title doesn't exist), authentication needs, rate limits, or response format. It adds some behavioral context but leaves gaps for a tool with no annotations.
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 concise sentences with zero waste: the first specifies the action and inputs, the second details the output scope. It's front-loaded with the core purpose and efficiently structured, making every sentence earn its place.
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 annotations, no output schema, and 2 parameters with full schema coverage, the description is adequate but has clear gaps. It covers the purpose and output scope but lacks behavioral details like error cases or return structure. For a read tool with moderate complexity, it's minimally viable but not fully 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 description coverage is 100%, so the schema already documents both parameters (id and title) with descriptions. The description adds minimal value by reiterating 'by ID or exact title' and implying these are alternatives, but doesn't provide additional semantics like format examples or precedence rules. Baseline 3 is appropriate as the schema does the heavy lifting.
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: 'Read full recipe data by ID or exact title' specifies the verb (read), resource (recipe data), and input methods. It distinguishes from 'search_recipes' by emphasizing exact matching rather than search, but doesn't explicitly contrast with 'update_recipe' or 'format_fraction'.
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 context by stating 'by ID or exact title' and mentioning it returns 'all recipe fields', which suggests this is for retrieving complete records. However, it doesn't explicitly state when to use this versus 'search_recipes' (which likely handles partial matches) or other siblings, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search recipes by text across title, ingredients, categories, directions, or notes. Returns recipe IDs, titles, and context for each match. Use an empty query ('') to get all recipes. Results are paginated and sorted alphabetically. Only non-trashed recipes are included.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Text to search for in recipes. Use empty string '' to get all recipes. | |
| fields | No | Specific fields to search in. If not provided, searches all fields (name, ingredients, categories, directions, notes) | |
| context_lines | No | Number of lines of context to show around matches (default: 2) | |
| page | No | Page number for pagination (default: 1) | |
| page_size | No | Number of results per page (default: 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: pagination, alphabetical sorting, exclusion of trashed recipes, and what fields are searched. It doesn't mention rate limits or authentication needs, but covers most operational aspects.
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 efficiently structured with four sentences that each add value: search scope, return format, special query case, and behavioral constraints. It's front-loaded with the core purpose and wastes no 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 search tool with no annotations and no output schema, the description provides good context about what fields are searched, pagination, sorting, and filtering. It could be more complete by describing the exact return format or error conditions, but covers the essential operational context.
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 description coverage is 100%, so the baseline is 3. The description adds some value by explaining the empty query behavior and context lines purpose, but doesn't provide significant additional parameter semantics beyond what the schema already documents thoroughly.
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 'search' and resource 'recipes', specifies what fields are searched (title, ingredients, categories, directions, notes), and distinguishes from siblings like 'read_recipe' and 'update_recipe' by focusing on search functionality. It provides specific scope and behavior.
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 context for when to use this tool (searching across multiple fields) and includes a specific usage note about empty queries to get all recipes. However, it doesn't explicitly state when NOT to use it or mention alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update recipe fields using find/replace. This is a DANGEROUS operation that requires user confirmation. Can update any text field in a recipe.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Recipe UID to update | |
| field | Yes | Field to update | |
| find | Yes | Text to find in the field | |
| replace | Yes | Text to replace it with | |
| regex | No | Whether to treat 'find' as a regex pattern (default: false) |
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 effectively adds critical context beyond what the input schema provides: it warns that the operation is 'DANGEROUS' and 'requires user confirmation,' which are essential behavioral traits (risk level and confirmation needs) not covered by the schema. This compensates well for the lack of annotations.
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 front-loaded with key information (purpose and danger warning) in just two sentences, with no wasted words. Every sentence earns its place by conveying critical details efficiently, making it appropriately sized and well-structured for quick comprehension.
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 complexity (a dangerous mutation tool with 5 parameters), no annotations, and no output schema, the description does a good job by covering purpose, risk, and scope. However, it lacks details on what happens on success/failure or error handling, which would be helpful for completeness. It compensates well but has minor 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?
The schema description coverage is 100%, meaning all parameters are documented in the schema. The description adds minimal value beyond this, as it only implies that parameters relate to 'find/replace' operations on 'text fields,' which is already clear from the schema. With high schema coverage, the baseline score of 3 is appropriate, as the description does not significantly enhance parameter understanding.
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 specific action ('update recipe fields using find/replace') and resource ('recipe'), distinguishing it from sibling tools like 'read_recipe' (read-only) and 'search_recipes' (searching). It specifies the scope ('any text field in a recipe'), making the purpose explicit and differentiated.
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 context by stating this is a 'DANGEROUS operation that requires user confirmation,' which implicitly guides when to use it (with caution and confirmation). However, it does not explicitly mention when not to use it or name alternatives (e.g., using 'read_recipe' to check first), so it lacks full explicit guidance.
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.
v1.0.0search_recipes3 fields changedInput schema / properties / pageAdded value: +{
+ "default": 1,
+ "description": "Page number for pagination (default: 1)",
+ "type": "integer"
+}Input schema / properties / page_sizeAdded value: +{
+ "default": 20,
+ "description": "Number of results per page (default: 20)",
+ "type": "integer"
+}Input schema / properties / query / descriptionPrevious value: -"Text to search for in recipes"New value: +"Text to search for in recipes. Use empty string '' to get all recipes."format_fractionread_recipesearch_recipesupdate_recipeScored across 4 tools
Each tool has a clearly distinct purpose with no overlap: format_fraction handles text formatting, read_recipe retrieves specific recipes, search_recipes finds recipes via queries, and update_recipe modifies recipes. The descriptions clearly differentiate between data retrieval (read/search) and operations (format/update).
All tools follow a consistent verb_noun pattern (format_fraction, read_recipe, search_recipes, update_recipe) with no deviations. The naming is predictable and readable, using snake_case uniformly across all tools.
Four tools are reasonable for a recipe management server, covering core operations like reading, searching, updating, and a utility for formatting. It might benefit from additional tools for creating or deleting recipes, but the current set is well-scoped for basic functionality.
The tools cover key operations (read, search, update) and include a useful formatting utility, but there are notable gaps: no create_recipe or delete_recipe tools, which limits full CRUD lifecycle coverage. Agents can work around this for read/update tasks but cannot handle recipe creation or removal.
Search, save, organize, cook, and share recipes with any AI assistant.
Scraps Kitchen gives any AI agent a persistent, household-aware kitchen memory. Unlike generic chatbot recall, Scraps maintains structured cooking data: what's in your fridge (with freshness tracking), who you cook for (with allergens, dietary restrictions, and preferences), your recipe collection (with cook notes and per-diner ratings), your shopping list, and your kitchen equipment. 27 tools across 6 domains let agents read kitchen context, suggest meals that respect dietary safety, update the pantry after cooking, and build a history of what works for your household. Every interaction makes the data richer. Cooking history, preference signals, kitchen awareness = better suggestions next time. All tools work via oAuth and a free scraps.kitchen account.
AI-powered kitchen management — pantry, recipes, meal plans, shopping lists
Household-aware cooking brain: pantry, meal suggestions, dietary safety, recipes, shopping lists.
