AI 에이전트 및 LLM을 위해 구축된 50,000개 이상의 음식 레시피에 대한 시맨틱 검색입니다. 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의 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(Reciprocal Rank Fusion)를 통해 융합, mmarco-mMiniLMv2-L12-H384-v1에 의해 리랭킹됨.
pingping(name="world")
# Returns: "Hello world! Recipe MCP server is running."출처: Food.com (약 50,000개 레시피)
범위: 다양한 요리, 식사 유형 및 조리 방식
영양 정보: 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 (자체 호스팅)
서버: 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.
