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., "@mela-mcp What can I make with chicken and kale?"
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 read-only MCP server that lets an MCP-compatible assistant (Claude Code, Claude Desktop, etc.) search and read recipes stored by the Mela macOS app.
Unofficial, third-party project. Not affiliated with, endorsed by, or supported by Mela or Mela's developers. It reads Mela's local database directly; it does not use any official Mela API.
macOS, with the Mela app installed and at least one recipe saved locally.
Python 3.10+.
Related MCP server: mealie-mcp
Three model-facing tools, all read-only:
search_recipes — full-text search across title, ingredients, instructions,
notes, description, nutrition, and link. All words in the query must match.
Optional filters: tag, favorite, want_to_cook. Text only, no photos.
get_recipe — full detail for one recipe, by the numeric id returned from
search_recipes (ingredients, instructions, notes, times, tags). On hosts that
support MCP Apps (Claude Desktop), it also renders a Mela-styled card with your
real photos inline — your own photos, downscaled, never stock images. The
photos display in that card; they are not sent to the model as text.
list_tags — every tag/category in your library with its recipe count.
That's it — no writing, no shopping lists, no meal planning. The server opens Mela's SQLite database read-only and never modifies it.
Example things you could ask an assistant connected to this server:
"What can I make with chicken and kale?"
"Show me my prime rib recipe."
"What tags do I have, and which one has the most recipes?"
Install it from a local checkout of the source:
git clone https://github.com/krumme/mela-mcp.git
cd mela-mcp
python3 -m venv .venv
source .venv/bin/activate
pip install -e .Then register it with your MCP host, pointing at the venv's Python you just created.
Claude Code:
claude mcp add mela -- /absolute/path/to/mela-mcp/.venv/bin/python -m mela_mcp.serverSubstitute the actual path to the venv you created above.
Claude Desktop (claude_desktop_config.json):
{
"mcpServers": {
"mela": {
"command": "/absolute/path/to/mela-mcp/.venv/bin/python",
"args": ["-m", "mela_mcp.server"]
}
}
}MELA_DB_PATH (optional) — overrides the path to Mela's database. Leave it
unset (or blank) to auto-detect the default location:
~/Library/Group Containers/66JC38RDUD.recipes.mela/Data/Curcuma.sqlite
macOS only — Mela's database lives in a macOS app container.
macOS privacy prompt. macOS shows a dialog like "python… would like to access data from other apps." the first time (and, for an unsigned Python interpreter, often on every launch) the server reads Mela's app container. Clicking Allow works but usually won't persist for a bare interpreter. The durable fix is to grant Full Disk Access to your MCP host: System Settings → Privacy & Security → Full Disk Access, then add the Claude app (for Claude Desktop) or your terminal app (for Claude Code) — its child Python process inherits the access. The access is read-only, to your own recipes.
If the server still can't find your database, set MELA_DB_PATH explicitly.
Read-only by design: the server only ever opens the database in read-only mode and never writes to it.
Photos render only in the inline card on hosts that support MCP Apps (Claude Desktop). On other clients you get the recipe text; the model isn't handed the photos, so it can't display them itself. Whether the card renders is up to the host — this server can't force it.
python -m pytestThe live tests (tests/test_live.py) read your real Mela library, so they are
opt-in — otherwise they'd trigger a macOS privacy prompt on every run. Enable
them explicitly:
MELA_LIVE_TEST=1 python -m pytestPlain python -m pytest skips them (and they also skip when Mela isn't installed).
Get one recipe's full detail (ingredients, instructions, notes, times, tags) by its numeric id from search_recipes.
On hosts that support MCP Apps (e.g. Claude Desktop) a Mela-styled card with the user's real photos renders inline automatically. Present the recipe text; the photos appear only in that card and are not provided to you as content, so do not describe or substitute images. Never use stock or web photos.
| Name | Required | Description | Default |
|---|---|---|---|
| recipe_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly discloses that real photos are not provided as content to the agent, only rendered in a card, and instructs not to describe or substitute photos. It also lists what fields will be returned. It lacks error/edge-case behavior, but for a read-only get operation, this is a meaningful disclosure that goes beyond obvious behavior.
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 concise and front-loaded with the core purpose. The additional sentences about MCP Apps and photo handling are useful and directly inform agent behavior, though the MCP Apps detail could be seen as slightly verbose. Overall each sentence earns 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?
For a simple single-parameter tool, the description covers the input source, return content, and a critical behavioral caveat (photos not available). It doesn't mention not-found errors or permissions, but those are less critical given the simple read-only nature and no output schema. It is complete enough for effective use.
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 is sparse (one integer `recipe_id`, 0% coverage), but the description compensates by specifying 'by its numeric id from search_recipes'. This tells the agent the id is numeric and comes from the search tool's results, which is valuable beyond the schema's bare type definition.
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 states a precise action: 'Get one recipe's full detail' with a specific resource (recipe by numeric id) and lists the included content (ingredients, instructions, notes, times, tags). It clearly distinguishes from siblings like search_recipes (which lists) and get_recipe_widget_data (which returns widget data, not full detail).
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 phrase 'from search_recipes' clearly instructs the agent to obtain the recipe_id from the search tool, establishing a sequencing guideline. It does not explicitly exclude get_recipe_widget_data, but the context of needing full detail vs. widget data is implied. The photo guidance also tells the agent how to handle the response, adding practical usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
App-only data feed for the Mela recipe card. The widget iframe calls this itself (Krea's get_job pattern) via a host-relayed tools/call after Claude Desktop strips structuredContent from the pushed tool-result. Never surfaced to the model, so the base64 photo data URIs stay out of model context.
| Name | Required | Description | Default |
|---|---|---|---|
| recipe_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It mentions that base64 photo data URIs stay out of model context and describes a call pattern, but does not clarify whether this is a read-only operation, what side effects exist, or what the output structure is. The information provided is more about internal plumbing than tool behavior.
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 run-on sentence filled with jargon (e.g., 'Krea's get_job pattern', 'host-relayed tools/call') without being front-loaded with the core purpose. It is not concise or well-organized for an agent to quickly understand the tool.
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?
Despite having only one parameter and no output schema, the description fails to explain what data the tool returns, what the recipe_id refers to, or how the tool fits into the agent's workflow. It is written for developers maintaining the system, not for an AI agent selecting and invoking the tool.
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 0%, and the description does not explain the recipe_id parameter at all. The parameter only has a type and title, so the agent has no idea what value to pass or how it relates to the tool's function.
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 mentions 'app-only data feed for the Mela recipe card' but lacks a clear verb+resource structure. It doesn't state what the tool actually returns or does in a way an agent can act on. It does not distinguish itself from siblings like get_recipe or search_recipes beyond saying it is app-only.
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 says the widget iframe calls the tool itself and it is 'never surfaced to the model,' implying the agent should not use it. No alternatives or conditions are provided. This gives no actionable guidance for when an agent should invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all recipe tags/categories with how many recipes carry each.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description is the sole source of behavioral info. It discloses that it lists all tags with counts, indicating a read-only aggregate operation. It doesn't mention potential quirks like pagination, but for this simple listing the behavior is adequately conveyed.
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 sentence, front-loaded with the verb and object, and contains no unnecessary words. Every word earns 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 the tool has no parameters and an output schema exists, the description fully covers what the tool does. It explicitly mentions the aggregate count detail, which is the core output.
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?
There are zero parameters, so no parameter documentation is needed. The baseline of 4 applies as the schema imposes no burden and the description adds no confusion.
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 uses the specific verb 'List' and clearly identifies the resource as 'all recipe tags/categories' with a distinct output detail (counts). It differentiates from sibling tools like get_recipe and search_recipes, which focus on individual recipes or searching.
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 tool's purpose is self-evident for listing tags/categories, and the context of sibling tools implies this is the correct tool for a tag overview. However, it does not explicitly state exclusions or alternative selection guidance, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search the Mela recipe library. All words must match. Optional filters: tag name, favorite, want_to_cook. Returns id/title/tags/snippet (text only, no photos). Call get_recipe with a result's id to show the full recipe together with the user's real photos.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | ||
| limit | No | ||
| query | Yes | ||
| favorite | No | ||
| want_to_cook | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behaviors: 'All words must match' for query semantics, return fields (id/title/tags/snippet), and that results are text only with no photos, requiring get_recipe for photos. This goes well beyond the schema.
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?
Three concise sentences, each earning its place: purpose/filter overview, return summary, and cross-reference to get_recipe. It is front-loaded with the main action and contains no filler.
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 an output schema exists and parameters are simple, the description covers the essential aspects: search semantics, filters, return severity, and how to get full recipes. Missing a mention of the limit parameter is a minor gap, but overall it is complete enough 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for the query parameter ('All words must match') and lists tag, favorite, and want_to_cook as optional filters. However, it does not describe the limit parameter or clarify the meaning of boolean filters beyond their names. Since schema descriptions are absent (0% coverage), this is a partial compensation.
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 opens with a specific verb+resource: 'Full-text search the Mela recipe library.' It clearly distinguishes from siblings by stating that results are summaries (id/title/tags/snippet) and directing users to get_recipe for full details, including photos.
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?
It provides a clear workflow: first use search_recipes, then call get_recipe with a result id to see the full recipe with photos. This implies when to use this tool vs get_recipe, though it does not explicitly discuss other siblings like list_tags or state exclusions.
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.
v0.1.0get_recipeget_recipe_widget_datalist_tagssearch_recipesScored across 4 tools
get_recipe and get_recipe_widget_data both involve recipe data, but the latter is explicitly described as an internal widget feed never surfaced to the model, so an agent should not confuse them. search_recipes and list_tags have clear distinct purposes.
All tool names follow a consistent verb_noun pattern: get_recipe, get_recipe_widget_data, search_recipes, list_tags. Naming is uniform and predictable.
Four tools is a reasonable count for a recipe lookup server, covering search, retrieval, tag listing, and an internal widget feed. It is slightly lean but not under-scoped.
The server provides core read-only functionality for a recipe library: search, get details, list tags. It lacks create/update/delete operations, but the domain appears to be a read-only assistant integration, so these are not glaring gaps.
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
MCP server for Russian books search, details, and recommendation candidates.
Unlock the power of food transparency with our Open Food Facts MCP server. Easily look up any food
