AIエージェントおよびLLM向けに構築された、5万件以上の料理レシピを対象としたセマンティック検索サーバーです。2段階のハイブリッド検索（密ベクトル検索 + 疎ベクトル検索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の5万件以上のレシピをセマンティック検索します。
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。Reciprocal Rank Fusion (RRF) で融合し、mmarco-mMiniLMv2-L12-H384-v1 でリランクします。
pingping(name="world")
# Returns: "Hello world! Recipe MCP server is running."ソース: Food.com (約5万件のレシピ)
カバレッジ: 幅広い料理、食事タイプ、調理スタイル
栄養データ: 1食あたりのカロリー、脂質、タンパク質、炭水化物、ナトリウム、食物繊維、糖質
評価: ユーザー評価 + レシピごとの評価数
言語: クエリにおいて英語とノルウェー語をネイティブサポート
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
ベクトルDB: Qdrant (セルフホスト)
サーバー: FastMCP 3.2 over HTTP
インフラ: 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.
