Pepesto API용 MCP 서버 — 에이전트가 모든 레시피(URL, 일반 텍스트 또는 사진)를 유럽 26개 슈퍼마켓의 실시간 가격이 포함된 실제 장바구니로 변환할 수 있는 기능을 제공합니다. 이 MCP는 워크플로우의 레시피 → 장바구니 매칭 단계(파싱 / 검색 / 재료를 SKU로 매핑 / 카탈로그 확인)를 담당하며, 실제 주문은 별도의 단계입니다. 결제가 실제로 이루어지는 곳을 참조하세요.
claude_desktop_config.json에 추가하세요:
{
"mcpServers": {
"pepesto": {
"command": "npx",
"args": ["-y", "@pepesto/pepesto-mcp"],
"env": { "PEPESTO_API_KEY": "pep_sk_…" }
}
}
}claude mcp add pepesto -e PEPESTO_API_KEY=pep_sk_… -- npx -y @pepesto/pepesto-mcpRelated MCP server: Swissgroceries MCP
종량제 크레딧 팩으로 시작하세요 — https://www.pepesto.com/pricing/를 참조하세요.
결제 시 사용한 이메일로 /link를 호출하여 API 키를 생성하세요. 키는 단 한 번만 제공되므로 즉시 저장해야 합니다.
curl -X POST https://s.pepesto.com/api/link \
-H "Content-Type: application/json" \
-d '{"email":"you@example.com"}'환경 변수에 키를 설정하세요:
export PEPESTO_API_KEY=pep_sk_…도구 | 엔드포인트 | 설명 |
|
| 레시피 → 장바구니 매칭(결제를 위한 |
|
| URL/텍스트/이미지 레시피를 구조화된 재료 + |
|
| Pepesto의 100만 개 이상의 레시피 그래프 검색. |
|
|
|
|
| 슈퍼마켓의 전체 SKU 덤프. 명시적으로 요청할 때만 사용하며, 결과를 캐싱하세요. |
|
| 남은 크레딧 확인. 무료. |
이 MCP는 "가격이 포함된 장바구니 매칭" 단계에서 멈춥니다. 사용자가 주문을 완료하는 방법은 결제가 실제로 이루어지는 곳을 참조하세요. /session, /checkout, /link는 의도적으로 포함되지 않았으며, 계획된 기능은 로드맵을 참조하세요.
가장 빠른 경로입니다. 도구 호출 한 번으로 장바구니 매칭과 결제 링크를 반환합니다.
사용자: BBC Good Food의 피자 마르게리타 레시피로 Tesco 장바구니를 만들고, 탄산수와 올리브 오일도 추가해 줘.
어시스턴트: [
content_urls,content_text,supermarket_domain: "tesco.com"과 함께pepesto_oneshot사용]어시스턴트: Tesco에서 장바구니가 매칭되었습니다. 결제 링크:
<redirect_url>.
"요리할 만한 것을 찾아줘"와 같은 프롬프트의 경우, 에이전트가 먼저 Pepesto의 레시피 그래프를 검색하고 가격이 포함된 매칭 상품을 반환합니다.
사용자: 2인용 비건 파스타 레시피를 찾아줘.
어시스턴트: [
query: "vegan pasta dinner for two"와 함께pepesto_suggest사용]어시스턴트: 세 가지 옵션이 있습니다: 크리미 캐슈 펜네, 레몬 갈릭 스파게티, 구운 채소 리가토니. 어떤 것을 원하시나요?
사용자: 첫 번째 걸로 할게. Coop(coop.ch)에서 장바구니에 담아줘.
어시스턴트: [선택한 레시피의
kg_token과supermarket_domain: "coop.ch"를 사용하여pepesto_products사용]어시스턴트: Coop에서 8개 재료가 매칭되었습니다 — 캐슈넛 CHF 4.20, 펜네 CHF 1.95 등 — 총 CHF 18.40입니다.
사용자가 이미 레시피 URL이나 텍스트를 염두에 두고 있을 때 사용합니다. MCP는 매칭된 상품 목록을 반환하며, 이를 어떻게 처리할지는 사용자의 선택입니다.
사용자: 이 레시피를 파싱해서 재료를 분류해 줘: https://www.bbcgoodfood.com/recipes/pizza-margherita-4-easy-steps
어시스턴트: [
recipe_url과 함께pepesto_parse사용]어시스턴트: 피자 마르게리타 4단계 레시피 — 8개 재료: 강력분, 인스턴트 이스트 등.
사용자: 이제 이것들을 Sainsbury's 상품으로 매칭해 줘.
어시스턴트: [반환된
kg_token과supermarket_domain: "sainsburys.co.uk"를 사용하여pepesto_products사용]어시스턴트: Sainsbury's에서 8개 재료가 매칭되었습니다 — 총 £6.40.
pepesto_products를 통해 여러 kg_token을 한 번에 호출하면 Pepesto가 레시피 간 중복 재료를 병합합니다.
사용자: 이번 주 5일치 키토 저녁 식단을 계획하고 Delhaize에서 매칭해 줘.
어시스턴트: [
query: "keto dinner low carb high protein", num_to_fetch: 5와 함께pepesto_suggest사용]어시스턴트: 다섯 가지 저녁 식단: 스테이크 & 케일, 연어 아보카도 볼, 주키니 라자냐, 콜리플라워 리조또, 치킨 시저.
사용자: 일주일 전체를 아우르는 하나의 쇼핑 리스트를 만들어 줘.
어시스턴트: [5개의
kg_tokens와supermarket_domain: "delhaize.be"를 사용하여pepesto_products사용]어시스턴트: 통합 매칭: 24개의 고유 재료(일부 레시피 간 공유), Delhaize 예상 총액 €68.40.
각 마켓에 대해 pepesto_products를 통해 동일한 레시피를 실행하고 합계를 비교합니다.
사용자: 이 일요일 점심 레시피를 파싱해 줘.
어시스턴트: [
pepesto_parse사용]어시스턴트: 확인했습니다: 이탈리안 일요일 점심, 12개 재료.
사용자: Esselunga와 Conad의 장바구니를 모두 보여줘서 비교할 수 있게 해 줘.
어시스턴트: [
supermarket_domain: "spesaonline.esselunga.it"와supermarket_domain: "spesaonline.conad.it"로pepesto_products를 두 번 사용]어시스턴트: Esselunga: €34.20. Conad: €31.50. Conad가 €2.70 더 저렴하며, 주로 파스타와 토마토에서 차이가 납니다.
명시적인 요청이 있을 때만 사용하며, 적극적으로 캐싱하세요 — 아래 가격 및 모범 사례를 참조하세요.
사용자: 가격 비교 대시보드를 만들고 있어. Plus NL 전체 카탈로그를 가져와 줘.
어시스턴트: 주의하세요 —
pepesto_catalog는 여기서 가장 비용이 많이 드는 호출입니다. 한 번만 실행할 예정이니, 결과를 최소 하루 동안 캐싱해야 합니다. 진행할까요?사용자: 응.
어시스턴트: [
supermarket_domain: "plus.nl"와 함께pepesto_catalog사용]어시스턴트: 카탈로그 덤프 완료: 23개 카테고리에 걸친 1,847개 SKU.
# | 국가 | 슈퍼마켓 | 도메인 / ID |
2 | 🇬🇧 GB | Sainsbury's | sainsburys.co.uk |
3 | 🇬🇧 GB | ASDA | asda.com |
4 | 🇬🇧 GB | Morrisons | groceries.morrisons.com |
5 | 🇬🇧 GB | Waitrose | waitrose.com |
1 | 🇬🇧 GB | Tesco | tesco.com |
6 | 🇳🇱 NL | Albert Heijn | ah.nl |
7 | 🇳🇱 NL | Jumbo | jumbo.com |
8 | 🇳🇱 NL | Plus NL | plus.nl |
9 | 🇩🇪 DE | Rewe | shop.rewe.de |
10 | 🇨🇭 CH | Coop CH | coop.ch |
11 | 🇨🇭 CH | Migros | migros.ch |
12 | 🇨🇭 CH | Farmy | farmy.ch |
13 | 🇨🇭 CH | Aldi CH | aldi-now.ch |
14 | 🇧🇪 BE | Colruyt | colruyt.be |
15 | 🇧🇪 BE | Delhaize | delhaize.be |
16 | 🇮🇪 IE | Tesco IE | tesco.ie |
17 | 🇮🇪 IE | SuperValu | shop.supervalu.ie |
18 | 🇮🇪 IE | Dunnes | dunnesstoresgrocery.com |
19 | 🇮🇹 IT | Esselunga | spesaonline.esselunga.it |
20 | 🇮🇹 IT | Conad | spesaonline.conad.it |
21 | 🇩🇰 DK | Nemlig | nemlig.com |
22 | 🇳🇴 NO | Meny | meny.no |
23 | 🇵🇱 PL | Frisco | frisco.pl |
24 | 🇵🇱 PL | Auchan PL | zakupy.auchan.pl |
25 | 🇧🇬 BG | Bulmag | bulmag.org |
26 | 🇧🇬 BG | eBag | ebag.bg |
이 목록에 없는 슈퍼마켓이 필요하신가요? Pepesto에 문의하세요.
이 MCP는 "가격이 포함된 장바구니 매칭" 단계에서 멈춥니다. 슈퍼마켓 웹사이트에서 주문을 자동으로 완료하지는 않습니다. 쇼핑을 마무리하는 두 가지 방법:
Pepesto 앱 (권장). pepesto_oneshot이 반환한 redirect_url을 브라우저에서 열거나, pepesto_products에서 받은 매칭 상품 목록을 사용자에게 전달하여 Pepesto 앱에서 다시 생성하도록 하세요. 로그인, 장바구니 검토 및 결제(일부 마켓)를 포함한 호스팅된 결제 흐름이 제공됩니다.
슈퍼마켓 자체 사이트. 사용자가 pepesto_products에서 받은 매칭 상품 목록을 가지고 tesco.com / coop.ch 등에서 직접 SKU를 추가할 수 있습니다. 더 느리지만 Pepesto 계정이 필요하지 않습니다.
Pepesto는 간단한 종량제 크레딧으로 운영됩니다. 에이전트가 실제로 사용하는 만큼만 지불하며, 크레딧은 만료되지 않으므로 충전한 크레딧은 소진할 때까지 유지됩니다. 학생 및 초기 단계 팀을 위한 할인도 제공하고 있으니 해당되는 경우 연락해 주세요. 전체 호출당 가격 및 볼륨 티어는 https://www.pepesto.com/pricing/에서 확인할 수 있습니다.
크레딧을 최대한 활용하기 위한 몇 가지 팁:
pepesto_credits는 무료입니다 — 언제든지 호출하여 잔액을 확인하세요.
pepesto_oneshot, pepesto_parse, pepesto_suggest, pepesto_products는 일상적인 호출(레시피 매칭, 주간 계획, 장바구니 비교)이며 일상적인 에이전트 사용에 적합한 가격으로 책정되어 있습니다.
pepesto_catalog는 슈퍼마켓의 전체 SKU 덤프를 수행하는 가장 무거운 호출입니다. 시장 분석이나 가격 비교 대시보드에 적합한 도구이며, 슈퍼마켓당 최소 하루 동안 결과를 캐싱하세요. 필요한지 확실하지 않으신가요? 사용 사례를 알려주시면 더 저렴한 경로를 안내해 드립니다.
다음 기능이 계획되어 있습니다:
pepesto_session — /session을 래핑하여 에이전트가 선택한 SKU로 Pepesto 측 결제 세션을 구축할 수 있도록 합니다.
pepesto_checkout — 슈퍼마켓 자체 사이트를 구동하는 브라우저 자동화 루프인 /checkout을 래핑합니다(로그인, 장바구니 추가, CAPTCHA 프롬프트 등). 이는 완전 자율 쇼핑을 위한 마지막 퍼즐 조각입니다.
호스팅된 결제 핸드오프 — Pepesto 앱 딥링크를 구조화된 도구 결과로 노출하여(일반 텍스트 대신), MCP 클라이언트가 이를 URL 대신 버튼으로 렌더링할 수 있도록 합니다.
이 기능들 중 필요한 것이 있다면 알려주세요 — 우선순위를 높이겠습니다.
git clone https://github.com/pepesto-solutions/pepesto-mcp.git
cd pepesto-mcp
npm install
npm run build
npm test
npm run test:coverage로컬 빌드에 대해 인스펙터를 실행하세요:
PEPESTO_API_KEY=pep_sk_… npm run inspector이 저장소의 Pepesto MCP 서버는 MIT 라이선스에 따라 라이선스가 부여됩니다.
Dump Pepesto's full indexed catalog for a supermarket (~1-2k SKUs of common cooking ingredients, with names, prices, images, IDs). Optionally pass a webhook_url to receive incremental updates on re-index. Use only when the user has explicitly asked for a catalog dump, market analysis, or storefront build; for normal recipe-to-cart flows use pepesto_oneshot or pepesto_products instead. Cache this query aggressively, no more than one call per day per supermarket is recommended. When presenting supermarket results the user, use the product key as (external) link to the supermarket product itself. Show image if available (json property image_url, don't search for external images, skip rendering the Pepesto image if the image has webp extesion)
| Name | Required | Description | Default |
|---|---|---|---|
| supermarket_domain | Yes | Supermarket domain or ID, e.g. 'coop.ch', 'tesco.com', 'ah.nl'. See README for the full list. | |
| webhook_url | No | URL to POST incremental catalog updates to. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the optional webhook for incremental updates, caching advice, and image handling. Does not explicitly mention read-only nature or auth requirements, but covers key behaviors.
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?
Description is dense with useful information, front-loaded with purpose and core details. Slightly long but every sentence adds value. Could be slightly more concise, but well structured.
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?
Covers return content (names, prices, images, IDs), caching, image handling, and presentation guidance. Lacks details on error handling or webhook format, but adequate for a dump 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 coverage is 100%, baseline 3. Description adds meaning: explains webhook_url is for incremental updates, and gives example for supermarket_domain. Adds value beyond schema.
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 dumps the full catalog for a supermarket with specific details (1-2k SKUs, names, prices, images, IDs). It distinguishes from siblings by mentioning alternative tools for normal recipe-to-cart flows.
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?
Explicitly states when to use (catalog dump, market analysis, storefront build) and when not (use pepesto_oneshot or pepesto_products for normal flows). Also provides caching recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the remaining API credits on the configured Pepesto API key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It clearly states the tool returns credits with no side effects, but lacks detail on error conditions (e.g., missing key). Still sufficient for simple read operation.
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?
Single sentence, no superfluous words. Every word contributes meaning. Perfectly concise.
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?
No output schema, so description should explain return value. It states returns remaining credits, but lacks format (e.g., number, string). Adequate for simple tool but could be more precise.
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?
Input schema has zero parameters, so schema coverage is 100%. Description adds no param info, which is appropriate. Baseline score of 4 applies as per guidelines.
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 that the tool returns the remaining API credits, distinguishing it from sibling tools like catalog or oneshot. The verb 'Return' and resource 'remaining API credits' are specific and unambiguous.
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?
No explicit guidance on when to use this tool versus alternatives. However, due to its specific function, usage is implied when checking API credits. Missing when-not-to-use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One-shot: turn recipe URLs, free-form text, and/or an image into a ready-to-checkout cart for a chosen European supermarket. Returns a redirect_url that opens the Pepesto checkout UI for the user to verify and pay. Internally runs parse + products + session (not exposed to agents) with Pepesto's heuristics. Use this when you want the simplest end-to-end flow; use pepesto_parse + pepesto_products + session (not exposed to agents) for finer control.
| Name | Required | Description | Default |
|---|---|---|---|
| content_urls | No | Recipe URLs to parse and shop. | |
| content_text | No | Free-form shopping list or extra items to include. | |
| content_image | No | Base64-encoded recipe image. | |
| supermarket_domain | No | Supermarket domain or ID, e.g. 'coop.ch', 'tesco.com', 'ah.nl'. See README for the full list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions internal steps (parse + products + session) and that it returns a redirect_url, but does not cover error handling, idempotency, authentication needs, or potential side effects beyond cart creation. While the core behavior is described, more detail would improve 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 four sentences, each serving a purpose: purpose, output, internal process, usage guidance. It is front-loaded with the main action and efficiently conveys all needed information without redundancy.
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 (multiple input types, single output) and the lack of output schema or annotations, the description provides adequate context: what it does, what it returns, and when to use alternatives. However, it could be more complete by mentioning possible failure modes or prerequisites, but overall it is sufficient for agent decision-making.
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?
All four parameters are described in the input schema (100% coverage). The description loosely maps inputs to parameters (recipe URLs, free-form text, image) and gives an example for supermarket_domain, but this adds only minor context beyond the schema. Baseline 3 is appropriate.
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: turning recipe URLs, free-form text, and/or an image into a ready-to-checkout cart for a European supermarket. It specifies the output (redirect_url) and distinguishes itself from siblings by noting it internally runs parse+products+session, and recommends pepesto_parse+pepesto_products for finer control.
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 tells when to use this tool ('simplest end-to-end flow') and when to use alternatives ('pepesto_parse + pepesto_products + session for finer control'). This provides clear guidance for the agent to choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse a recipe from a URL, free-form text, or image into a structured object: title, ingredients, nutrition, instructions, and a KgToken you can pass to pepesto_products to build a real cart. Once the response is returned, show recipe title, image if available (json property image_url, don't search for external images, skip rendering the Pepesto image if the image has webp extesion), ingredients, steps, nutrition summary, allergens clearly marked, and portions/servings if available. Don't show kg_token, but mark and save it for the next steps (e.g., /products call).
| Name | Required | Description | Default |
|---|---|---|---|
| recipe_url | No | Publicly crawlable recipe URL. | |
| recipe_text | No | Free-form recipe text. | |
| recipe_image | No | Base64-encoded recipe image. | |
| locale | No | BCP 47 locale, e.g. 'en-GB', 'de-CH'. | |
| generate_image | No | Whether to generate a shareable image of the recipe. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description gives response handling instructions but does not disclose behavioral traits like authorization, rate limits, or error scenarios.
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?
Description is verbose and includes agent instructions (show/hide fields) that could be separate; not concise.
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?
Explains output fields and KgToken but lacks detail on when to use each input type and does not cover return structure.
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 coverage is 100%; description adds context linking input types to output but does not detail each parameter's usage comprehensively.
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?
Clearly states verb 'Parse' and resource 'recipe', and enumerates output fields. However, no explicit differentiation from sibling tools.
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?
Describes what to do after parsing (show fields, save kg_token) but lacks guidance on when to use this tool vs alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn a free-form shopping list into a deferred deep link to the Pepesto mobile app, returned as a redirect_url. This is a PUBLIC endpoint: it is FREE to the API client, needs no API key, and returns instantly. Parsing and product matching happen lazily, only after the user opens the link — and the USER (not the API client) is charged when they proceed to checkout in the app. If the app isn't installed, the user is sent to the app store first and the shopping list is preserved until the app opens. This is an end-user / agent-facing handoff (e.g. a person chatting in Claude Desktop who wants to finish shopping on their phone), not a developer-integration endpoint. Choose pepesto_predirect when the cost should fall on the end user and a deferred deep link is acceptable. Choose pepesto_oneshot instead when the client wants the basket matched up front (with prices) and is willing to pay for the matching. PRESENTATION (important): the tool's text output is ready-to-show Markdown — a single tappable, labeled link plus a one-line caption. Surface it to the user exactly as returned; do NOT also paste the long raw URL as plain text. You may add one short sentence telling them to open it on their phone (on a computer, opening it shows a QR code to scan).
| Name | Required | Description | Default |
|---|---|---|---|
| shopping_list | Yes | Free-form shopping list. May contain multiple newline-separated lines, e.g. '2 avocados\n1 loaf of bread\n500 g tomatoes'. | |
| locale | No | User's locale, e.g. 'de-DE'. Optional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description comprehensively discloses behavioral traits: it is free, requires no API key, returns instantly, parsing occurs lazily after link opening, the user is charged (not the API client), and behavior when app is not installed (app store redirect with preserved list).
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 lengthy but well-structured, front-loading the core function and then adding usage guidance, behavioral details, and presentation instructions. Every sentence adds value, though it could be slightly more concise.
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?
Without an output schema, the description fully explains the return format (Markdown with a tappable link and caption) and instructs the agent on how to present it to the user. It also covers edge cases (app not installed) and provides a complete picture of the tool's behavior.
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 coverage is 100% with descriptions for both parameters. The description adds minimal extra semantic beyond schema, only noting that shopping_list can be multi-line and locale is optional. This is adequate given the high coverage, but does not significantly enhance parameter understanding.
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: converting a free-form shopping list into a deferred deep link to the Pepesto mobile app. It specifies the key characteristics (free, public, no API key, lazy parsing) and distinguishes it from the sibling pepesto_oneshot tool.
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 versus pepesto_oneshot, based on cost allocation and timing of basket matching. It also clarifies that this is an end-user/agent-facing handoff, not a developer-integration endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Map one or more recipe KgTokens (and an optional manual shopping list) to concrete supermarket products with prices, images, or currency. Items are merged across recipes to reduce waste; multiple matches per ingredient let you (or the user) pick. Show product title, image if available (json property image_url, don't search for external images, skip rendering the Pepesto image if the image has webp extesion)product_id when available linking to an (external) supermarket page (open in a new tab), price, ProductClassification (is_bio, is_frozen, is_substitution) tags. PricePromotion shows if the item is currently on promotion and what's current promo_percentage
| Name | Required | Description | Default |
|---|---|---|---|
| recipe_kg_tokens | Yes | KgTokens from pepesto_parse or pepesto_suggest. | |
| supermarket_domain | Yes | Supermarket domain or ID, e.g. 'coop.ch', 'tesco.com', 'ah.nl'. See README for the full list. | |
| manual_shopping_list | No | Free-text extra items to add (e.g. 'milk, bananas, kitchen towel'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behavioral traits: merging items across recipes, multiple matches per ingredient for user selection, output fields (title, image, price, classification, promotion), and specific rendering instructions (skip webp images). However, it does not mention idempotency, rate limits, or authorization requirements.
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 paragraph that covers all necessary details without excessive length. It could benefit from bullet points for output fields, but the information is front-loaded with the main purpose in the first sentence.
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 absence of an output schema, the description thoroughly explains the return values (title, image, product_id, price, classification, promotion) and the merging/user-picking behavior. It provides sufficient detail for an agent to understand the tool's function and 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?
Schema description coverage is 100%, so baseline is 3. The description adds only contextual behavior (merging, picking) but does not enhance parameter semantics beyond what the schema already provides (e.g., examples, source hints).
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 a specific verb 'Map' and clearly states the resource transformation: KgTokens to supermarket products. It distinguishes itself from sibling tools that handle parsing (pepesto_parse) or suggestion (pepesto_suggest) by focusing on product mapping.
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 the tool is used after obtaining KgTokens from pepesto_parse or pepesto_suggest, but it does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Pepesto's recipe graph (1M+ recipes) by free-text query and optional filters (cuisine, dietary tags, ingredients to include/avoid, time, servings). Each result includes a KgToken you can pass to pepesto_products. Returned images are licensed for display in your app or website without attribution. Show recipe title, image if available (json property image_url, don't search for external images, skip rendering the Pepesto image if the image has webp extesion), ingredients, steps, nutrition summary, allergens clearly marked, and portions/servings if available. Don't show kg_token, but mark and save it for the next steps (e.g., /products call).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Free-text query that may include cuisine, dietary tags, ingredients to include or avoid, time constraints, and servings, e.g. 'vegan keto dinner low on carb for two'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that images are licensed for display, that kg_token should be saved for the next step, and provides display instructions. However, it does not mention whether the operation is read-only, auth needs, or rate limits.
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 long and includes instructions for how to handle results, which could be more concise. It mixes tool functionality with behavioral instructions for the agent.
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 no output schema, the description explains what the output contains (title, image, ingredients, steps, nutrition, allergens, portions, kg_token) and provides instructions on not showing certain fields. It is fairly complete for a search tool but could be more structured.
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 only has one parameter 'query' with a description that already mentions free-text. The tool description adds some extra context about cuisine, dietary tags, etc., but does not add substantial meaning beyond the schema. Schema coverage is 100%, so baseline 3 is appropriate.
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 Pepesto's recipe graph by free-text query and optional filters, and mentions it returns results with various details. However, it does not differentiate from siblings like pepesto_catalog or pepesto_oneshot.
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 when to use (searching recipes with filters) and hints at a workflow using the returned KgToken for pepesto_products. But it lacks explicit guidance on when not to use or comparisons to sibling tools.
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.7.0pepesto_predirectv1.6.0pepesto_catalogpepesto_creditspepesto_oneshotpepesto_parsepepesto_productspepesto_suggestScored across 7 tools
Each tool has a distinct role in the recipe-to-cart workflow, but pepesto_oneshot and pepesto_predirect both produce redirect URLs from free-form lists, and pepesto_parse/pepesto_suggest both return KgTokens with similar recipe presentation. The descriptions differentiate them well enough, so this is only a minor ambiguity.
All tools share the pepesto_ prefix, which is helpful, but the naming convention is mixed: some are action verbs (parse, suggest), some are resource nouns (credits, products, catalog), and some are coined terms (oneshot, predirect). The names are readable but not predictable from a single pattern.
Seven tools is well-scoped for the server's purpose. Each tool covers a distinct step or entry point in the recipe-to-cart workflow, with no obvious bloat or thinness.
The surface covers recipe discovery, parsing, product mapping, catalog access, and end-to-end checkout flows. The main gap is that no separate session/checkout tool is exposed for fine-grained flows after pepesto_products, though pepesto_oneshot covers the common end-to-end path.
Hosted MCP for e-commerce: live product catalog, stock, and pricing for AI agents.
Unlock the power of food transparency with our Open Food Facts MCP server. Easily look up any food
Hosted MCP server to manage a restaurant menu from AI agents - 39 tools over the DuckHub API.
MCP Server for an Agent Task Marketplace
