针对 50,000 多条食谱的语义搜索——专为 AI 智能体和 LLM 构建。采用两阶段混合检索（密集 + 稀疏 BM25，通过 RRF 融合）并结合交叉编码器重排序。支持挪威语和英语的自然语言查询。
实时端点： https://recipes.aidatanorge.no/mcp
传输方式： streamable-http
演示： https://recipes.aidatanorge.no/
添加到您的 MCP 客户端配置中：
{
"mcpServers": {
"food-recipe": {
"type": "streamable-http",
"url": "https://recipes.aidatanorge.no/mcp"
}
}
}或者使用 Claude Code：
claude mcp add --transport http food-recipe https://recipes.aidatanorge.no/mcpRelated MCP server: Food MCP Server
在浏览器中尝试实时演示：
https://recipes.aidatanorge.no/
无需安装或配置。
search_recipes通过混合检索和重排序，对来自 Food.com 的 50,000 多条食谱进行语义搜索。
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_id查询示例：
"Swedish meatballs with gravy"
"healthy high-protein chicken bowl"
"easy chocolate cake for beginners"
"traditional Norwegian kjøttkaker"
"hurtig pasta med kylling"
搜索流水线： 密集嵌入 (intfloat/e5-large-v2, 1024d) + 稀疏 BM25，通过倒数排名融合 (RRF) 进行融合，并由 mmarco-mMiniLMv2-L12-H384-v1 进行重排序。
pingping(name="world")
# Returns: "Hello world! Recipe MCP server is running."来源： Food.com（约 50,000 条食谱）
覆盖范围： 广泛的菜系、餐点类型和烹饪风格
营养数据： 每份的热量、脂肪、蛋白质、碳水化合物、钠、纤维、糖分
评分： 每条食谱的用户评分 + 评分数量
语言： 查询原生支持英语和挪威语
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 agents嵌入： intfloat/e5-large-v2 (1024d 密集) + Qdrant/bm25 (稀疏)
重排序器： cross-encoder/mmarco-mMiniLMv2-L12-H384-v1
向量数据库： Qdrant (自托管)
服务器： 基于 HTTP 的 FastMCP 3.2
基础设施： 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.
Cloud or self-hosted knowledge for AI agents: hybrid search, reranking, GraphRAG, scoped MCP tools.
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.
