This server provides semantic recipe search over ~50,000 Food.com recipes, plus a basic connectivity test.
Search recipes using natural language queries in any language (auto-translated to English), supporting search by cuisine, cooking style, ingredient, occasion, or mood (e.g. "quick Italian pasta", "healthy high-protein chicken bowl")
Filter by dietary requirements: vegetarian, vegan, gluten-free, dairy-free, low-carb, keto, or paleo
Filter by difficulty level: easy, medium, or hard
Filter by maximum cooking time in minutes
Control the number of results (default 5, up to 20)
Results include nutritional info, difficulty ratings, and user ratings
Ping / connectivity test to confirm the server is running
Provides semantic search capabilities for food recipes through LangChain integration, enabling AI agents to query recipes by natural language with filtering by diet, difficulty, time, and servings.
Semantic search over 50,000+ food recipes — built for AI agents and LLMs. Two-stage hybrid retrieval (dense + sparse BM25, fused via RRF) with cross-encoder reranking. Supports natural language queries in Norwegian and English.
Live endpoint: https://recipes.aidatanorge.no/mcp
Transport: streamable-http
Demo: https://recipes.aidatanorge.no/
Add to your MCP client config:
{
"mcpServers": {
"food-recipe": {
"type": "streamable-http",
"url": "https://recipes.aidatanorge.no/mcp"
}
}
}Or with Claude Code:
claude mcp add --transport http food-recipe https://recipes.aidatanorge.no/mcpRelated MCP server: Food MCP Server
Try the live demo in your browser:
https://recipes.aidatanorge.no/
No installation or configuration needed.
search_recipesSemantic search over 50,000+ recipes from Food.com with hybrid retrieval and reranking.
search_recipes(
query="quick Italian pasta for weeknight dinner",
diet="vegetarian", # vegetarian | vegan | gluten-free | dairy-free | low-carb | keto | paleo
max_minutes=30, # maximum total cooking time in minutes
difficulty="easy", # easy | medium | hard
limit=5 # default 5, max 20
)
# Returns: rerank_score, rrf_score, title, description, total_time, difficulty,
# diet, main_ingredient, servings, ingredients, instructions, nutrition,
# rating, rating_count, source, recipe_idQuery examples:
"Swedish meatballs with gravy"
"healthy high-protein chicken bowl"
"easy chocolate cake for beginners"
"traditional Norwegian kjøttkaker"
"hurtig pasta med kylling"
Search pipeline: Dense embedding (intfloat/e5-large-v2, 1024d) + sparse BM25, fused via Reciprocal Rank Fusion (RRF), reranked by mmarco-mMiniLMv2-L12-H384-v1.
pingping(name="world")
# Returns: "Hello world! Recipe MCP server is running."Source: Food.com (~50,000 recipes)
Coverage: Wide range of cuisines, meal types, and cooking styles
Nutritional data: calories, fat, protein, carbohydrates, sodium, fiber, sugar per serving
Ratings: user rating + rating count per recipe
Languages: English and Norwegian supported natively in queries
Food.com recipes → Python ingest → Qdrant (recipe_data_v2 collection)
↓
Hybrid search (dense e5-large-v2 + sparse BM25)
↓
RRF fusion + cross-encoder reranking
↓
FastMCP 3.2 → MCP clients / AI agentsEmbeddings: intfloat/e5-large-v2 (1024d dense) + Qdrant/bm25 (sparse)
Reranker: cross-encoder/mmarco-mMiniLMv2-L12-H384-v1
Vector DB: Qdrant (self-hosted)
Server: FastMCP 3.2 over HTTP
Infrastructure: Ubuntu Server 24 LTS, Cloudflare Tunnel
MIT
Simple connectivity test. Returns a greeting to confirm the server is running.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | world |
| 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 that the tool returns a greeting to confirm server running, which is helpful behavioral context. However, it doesn't mention potential side effects, error conditions, or performance aspects like response time, leaving some gaps in transparency.
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 that are front-loaded with the main purpose. Every sentence adds value: the first states what it does, and the second explains the outcome. There is no wasted verbiage, making it highly efficient.
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 low complexity (1 optional parameter) and the presence of an output schema, the description is reasonably complete. It explains the tool's purpose and expected behavior adequately, though it could benefit from mentioning the parameter's role or typical use cases for better 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?
The input schema has 1 parameter with 0% description coverage, so the description must compensate. It doesn't explicitly mention the 'name' parameter, but implies a greeting response that likely incorporates it. Since there's only one optional parameter with a default, the description's focus on the tool's purpose provides adequate context, though not detailed param semantics.
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 as a 'connectivity test' that 'returns a greeting to confirm the server is running.' It specifies the verb ('test'), resource ('server connectivity'), and outcome ('greeting'), though it doesn't explicitly differentiate from the sibling 'search_recipes' tool, which serves a completely different function.
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 for testing server connectivity, but doesn't provide explicit guidance on when to use it versus alternatives or any prerequisites. It suggests a context of verifying server status, which is useful but lacks detailed exclusions or comparisons to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search a database of recipes using hybrid semantic search (dense + sparse) with reranking.
The database contains ~50,000 recipes from Food.com covering a wide range of cuisines, meal types, and cooking styles. Recipes include nutritional information, difficulty ratings, and user ratings.
Use natural language in the query to describe what you are looking for — cuisine, style, main ingredient, occasion, or mood all work well. Queries in any language are supported and will be automatically translated to English before search. Examples: 'quick Italian pasta for weeknight dinner' 'Swedish meatballs with gravy' 'healthy high-protein chicken bowl' 'easy chocolate cake for beginners' 'something with salmon and lemon' 'Indian curry chicken' 'traditional Norwegian kjøttkaker' 'hurtig pasta med kylling' 'enkel sjokoladekake'
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | What you are looking for — describe the dish, cuisine, main ingredient, cooking style or mood freely. Any language is supported. | |
| diet | No | Optional — filter by dietary requirement: 'vegetarian', 'vegan', 'gluten-free', 'dairy-free', 'low-carb', 'keto', 'paleo' | |
| max_minutes | No | Optional — maximum total time in minutes, e.g. 30 | |
| difficulty | No | Optional — 'easy', 'medium' or 'hard' | |
| servings | No | Optional — not used for filtering (servings vary), but include in query for scaling context, e.g. 'pasta dish for 6 people' | |
| limit | No | Number of results to return after reranking (default 5, max 20) |
| 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 of behavioral disclosure. It effectively describes key behavioral traits: the search method (hybrid semantic search with reranking), database characteristics, multilingual support with auto-translation, and the types of information included in recipes. It doesn't mention rate limits, authentication needs, or pagination behavior, but provides substantial operational context.
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 the core functionality. The first sentence establishes the purpose, followed by database context and usage guidance. The query examples are valuable but slightly lengthy. Overall, most sentences earn their place, though some trimming of examples might improve conciseness.
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 complexity (semantic search with multiple filters), the description provides comprehensive context about the database, search methodology, and usage patterns. With 100% schema coverage and an output schema present, the description doesn't need to explain parameters or return values. It effectively complements the structured data with operational guidance.
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 all 6 parameters thoroughly. The description adds some context about the database content and query examples, but doesn't provide additional parameter semantics beyond what's in the schema. The baseline of 3 is appropriate when 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 searches a recipe database using hybrid semantic search with reranking. It specifies the database size (~50,000 recipes), source (Food.com), and content coverage (cuisines, meal types, cooking styles, nutritional info, difficulty ratings, user ratings). This distinguishes it from the only sibling tool 'ping' and provides specific verb+resource details.
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 explicit guidance on when to use this tool: for searching recipes with natural language queries covering cuisine, style, main ingredient, occasion, or mood. It includes multiple concrete examples of appropriate queries and notes that queries in any language are supported. Since the only sibling is 'ping', the distinction is clear.
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.2pingsearch_recipesScored across 2 tools
The two tools have completely distinct purposes: ping is a connectivity test with no domain functionality, while search_recipes is the core recipe search operation. There is no overlap or ambiguity between them.
Both tools use snake_case naming, which is consistent. However, ping uses a generic network term while search_recipes follows a verb_noun pattern, creating a minor deviation in naming style.
With only 2 tools, this server feels severely under-equipped for a recipe domain. A recipe server should typically include tools for retrieving recipe details, filtering by criteria, saving favorites, or managing collections, not just search and ping.
The server lacks basic CRUD operations for recipes. While search_recipes is well-described, there are no tools to get full recipe details, create/modify recipes, or manage user interactions. This creates significant gaps for agent workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Multi-engine search for AI agents. Trust scoring, local corpus, MCP-native. Self-hostable, BYOK.
Reddit & X data for AI agents over MCP. Semantic search, hosted, no Reddit API.
Capability registry for the agentic economy. Semantic search over verified MCP server listings.
