Skip to main content
Glama
jeonghwanko

coffee-price-mcp

by jeonghwanko
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
TypeScript
Remote

☕ coffee-price-mcp

License: MIT Node MCP Works with

"오늘 커피 가장 싸게 먹는 법" — read-only MCP 서버.

An MCP server that ranks today's cheapest coffee in Korea by real out-of-pocket price (list price − telecom/card/coupon perks). Plugs into Claude Code, OpenAI Codex, and Gemini CLI in one line.

coffee.pryzm.gg 의 공개 브랜드 혜택 API(/coffeecong/brand-benefits/*)를 감싸고, 브랜드별 메뉴 정가 상수로 체감가(정가 − 할인) 를 계산해 랭킹합니다. DB·시크릿 없음 — 공개 API만 호출하는 얇은 래퍼라서 그대로 가져다 쓰면 됩니다.

🔗 소개 페이지: coffee.pryzm.gg/coffee/mcp.html · 데모: AI에 연결하고 "오늘 제일 싼 커피는?" 한마디면 끝.

🚀 빠른 연결 (설치 불필요)

세 도구 모두 아래 한 가지 실행 명령을 공유합니다:

npx -y github:jeonghwanko/coffee-price-mcp

Node.js 18+ 만 있으면 됩니다. 최초 실행 시 GitHub에서 받아 자동 빌드하므로 몇 초 걸리고, 이후 캐시됩니다.

Claude Code

가장 간단 — 터미널에서:

claude mcp add coffee-price -- npx -y github:jeonghwanko/coffee-price-mcp

또는 .mcp.json(프로젝트) / ~/.claude.json(전역)에 직접:

{
  "mcpServers": {
    "coffee-price": {
      "command": "npx",
      "args": ["-y", "github:jeonghwanko/coffee-price-mcp"]
    }
  }
}

OpenAI Codex CLI

~/.codex/config.toml 에 추가:

[mcp_servers.coffee-price]
command = "npx"
args = ["-y", "github:jeonghwanko/coffee-price-mcp"]

Gemini CLI

~/.gemini/settings.json 에 추가:

{
  "mcpServers": {
    "coffee-price": {
      "command": "npx",
      "args": ["-y", "github:jeonghwanko/coffee-price-mcp"]
    }
  }
}

연결 후 "오늘 제일 싼 커피는?" 이라고 물어보면 됩니다.

Related MCP server: cafe-mcp-server

📋 예시

AI에게 평소 말투로 물어보면, AI가 get_cheapest_coffee 를 호출해 이렇게 답합니다:

🙋 오늘 제일 싼 커피는?

🤖 오늘 기준 아메리카노 체감가 TOP 3예요.

   🥇 할리스커피   0원      (정가 4,100) — KT VVIP, 아메리카노 2잔 무료
   🥈 스타벅스     0원      (정가 4,500) — LG U+ VVIP/VIP, 1잔 무료
   🥉 컴포즈커피   1,000원  (정가 1,500) — 조건 없음, 누구나

   👉 멤버십이 없다면 컴포즈 1,000원이 사실상 최저가예요.

멤버십/카드를 알려주면 본인이 받을 수 있는 혜택만 골라 다시 랭킹합니다:

🙋 나 SKT랑 현대카드 있어. 오늘 라떼 싸게 마시려면?

🛠 Tools (모두 read-only)

tool

설명

주요 인자

get_cheapest_coffee

오늘 가장 싸게 먹을 수 있는 커피 TOP N. 체감가 오름차순.

memberships, menu, brands, limit

search_coffee_deals

혜택 검색/필터. 각 혜택에 체감가 주석.

query, brand, provider, benefitType, todayOnly

verify_receipt_price

내가 낸 가격 적정성 점검 → great/fair/overpaid + 더 나은 혜택 제시.

brand, paidPrice, menu

get_card_benefits

카드사·통신사·페이별 혜택 모아보기. 즉시 할인은 체감가로, 캐시백·적립은 정보성으로 노출.

card, brand, limit

지원 브랜드: starbucks, mega, compose, twosome, coffeebean, bluebottle, hollys, ediya, paik, theventi, gongcha

🧮 체감가 엔진 (src/pricing.ts)

실데이터상 discountPct가 거의 항상 null이라 제목 텍스트 파싱이 핵심입니다:

  1. 명시적 discountPct → 정가 × (1 − pct/100) (신뢰도 high)

  2. 무료 음료 ('음료' 인접 '무료/증정') → 0원

  3. 퍼센트 ("최대 20%")

  4. BOGO ("1+1", "2+1") → 음료당 환산

  5. 정액 ("500원 할인")

  6. 산정 불가 → 랭킹 제외

원두·MD·굿즈 등 음료가 아닌 대상의 할인은 제외합니다(제목 가드). 마케팅 요약은 오탐이 잦아 파싱에서 제외.

⚠️ 체감가는 정가(코드 상수) − 혜택(제목 파싱) 추정치입니다. 등급·선착순·중복 불가 등 실제 적용 조건은 각 혜택의 sourceUrl 을 확인하세요. 정가는 2026 기준 근사값입니다.

⚙️ 환경변수

변수

기본값

설명

COFFEE_API_BASE

https://coffee.pryzm.gg/api

혜택 API 베이스. 로컬 개발 시 http://localhost:4000

config의 env 블록으로 덮어쓸 수 있습니다:

{
  "command": "npx",
  "args": ["-y", "github:jeonghwanko/coffee-price-mcp"],
  "env": { "COFFEE_API_BASE": "https://coffee.pryzm.gg/api" }
}

🧑‍💻 로컬 개발

git clone https://github.com/jeonghwanko/coffee-price-mcp.git
cd coffee-price-mcp
npm install
npm run build      # tsc → dist/
npm test           # vitest (pricing/engine 테스트)
npm start          # node dist/index.js (stdio)

소스에서 직접 실행하도록 config를 바꾸려면:

{ "command": "node", "args": ["/절대/경로/coffee-price-mcp/dist/index.js"] }

📦 npm 게시 (선택)

npx github: 방식은 매 실행마다 GitHub에서 받아 빌드합니다. 더 빠른 시작을 원하면 npm에 게시하세요:

npm publish --access public

게시 후에는 모든 config에서 github:jeonghwanko/coffee-price-mcp 를 coffee-price-mcp 로 바꾸면 됩니다.

라이선스

MIT · 데이터 출처: coffee.pryzm.gg 공개 혜택 API

Available Tools

3 tools
get_cheapest_coffeeA

오늘 가장 싸게 먹을 수 있는 커피 TOP N. 보유 멤버십/카드를 주면 받을 수 있는 혜택만 골라 체감가(정가-할인) 오름차순으로 랭킹한다.

ParametersJSON Schema
NameRequiredDescriptionDefault
membershipsNo보유 멤버십/카드 (예: ["SKT","현대카드"]). 지정 시 보유하지 않은 제휴 혜택은 제외.
menuNo메뉴명 (기본: 아메리카노)
brandsNo브랜드 slug 필터 (예: ["starbucks","mega"]). 가능: starbucks, mega, compose, twosome, coffeebean, bluebottle, hollys, ediya, paik, theventi, gongcha
limitNo반환 개수 (기본 10)

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. Details ranking logic (net price ascending, only applicable benefits). Does not address authentication or output format, but these are minimal risks.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with clear structure. Every word adds value. Front-loaded with purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 4 parameters and no output schema, description covers core behavior (ranking, filtering). Lacks output format details but sufficient for simple query. Complete enough for agent to understand.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage 100% with good descriptions. Description adds ranking context but does not significantly expand beyond schema. Baseline score of 3 appropriate as description adds moderate value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool ranks coffee options by cheapest net price given memberships. Verb is implied but specific (rank by cheapest). Differentiates from siblings (search_coffee_deals for broad search, verify_receipt_price for verification).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description implies usage context: when user wants cheapest coffee with available benefits. Does not explicitly state when-not-to-use or compare to alternatives, but sibling names provide contrast. Guideline is clear but lacks explicit exclusion.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_coffee_dealsB

커피 혜택 검색/필터 (브랜드·통신사/카드사·유형·키워드·오늘만). 각 혜택의 체감가를 함께 반환한다.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryNo제목/요약 텍스트 검색어
brandNo브랜드 slug (예: starbucks)
providerNo통신사/카드사 (예: SKT, 현대카드) — 해당 제휴 혜택만
benefitTypeNo혜택 유형
todayOnlyNotrue면 오늘 받을 수 있는 통신사·카드사 할인만
limitNo반환 개수 (기본 20)

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries full burden. It does not disclose read-only behavior, rate limits, or any side effects. The description only states what the tool does, not behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences that front-load the purpose and key filtering dimensions. No unnecessary words. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (6 optional parameters, no output schema, no annotations), the description covers filtering scope and return value but omits details on pagination, response format, or behavior when multiple filters are combined. It is adequate but leaves gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers all 6 parameters with descriptions (100% coverage). The description adds the context that effective price is returned, which is not in the schema. However, it doesn't explain parameter interdependencies or constraints beyond what the schema already provides, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it searches/filters coffee deals by brand, carrier/credit card, type, keyword, and today-only. It specifies the return includes effective price. However, it doesn't explicitly differentiate from sibling tools (get_cheapest_coffee, verify_receipt_price), leaving room for confusion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives. No prerequisites, exclusions, or context about appropriate use cases are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

verify_receipt_priceA

내가 낸 커피 가격이 적정한지 점검. 정가와 오늘 최저 체감가를 비교해 great/fair/overpaid 판정 + 더 나은 혜택을 제시한다. (영수증 제출이 아니라 가격 점검용 read-only)

ParametersJSON Schema
NameRequiredDescriptionDefault
brandYes브랜드 slug (예: starbucks, mega)
paidPriceYes실제 결제 금액 (원)
menuNo메뉴명 (기본: 아메리카노)

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It discloses that the tool is read-only (non-destructive) and provides a judgment and suggestions. However, it does not detail the exact output structure or potential limits, but it is sufficient for a simple check tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise: two sentences clearly stating the purpose and key behavioral notes. The parenthetical read-only note is efficiently placed. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Although there is no output schema, the description gives a high-level overview of the return (judgment and better deals). For a simple tool with 3 parameters and a clear function, this is mostly adequate, though more structured output details could help the agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for all parameters. The tool description adds context by explaining how parameters are used in the analysis (comparing paid price to regular and lowest). It does not repeat schema details but enhances understanding of the tool's logic.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: checking if a paid coffee price is appropriate by comparing against regular and lowest prices, and providing a judgment (great/fair/overpaid) along with better deal suggestions. It distinguishes from sibling tools by explicitly stating it is for price checking, not receipt submission, and is read-only.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use this tool (when you have a specific paid price to verify) and what to expect (judgment and suggestions). However, it does not explicitly compare to sibling tools like `get_cheapest_coffee` or `search_coffee_deals`, leaving the agent to infer the differentiation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv0.1.0
    • First observedget_cheapest_coffee
    • First observedsearch_coffee_deals
    • First observedverify_receipt_price
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: get_cheapest_coffee ranks top deals based on user memberships, search_coffee_deals provides flexible filtering, and verify_receipt_price checks a given price against current deals. No overlap or ambiguity.

Naming Consistency5/5

All tools use the verb_noun pattern in snake_case: get_cheapest_coffee, search_coffee_deals, verify_receipt_price. The convention is perfectly consistent.

Tool Count4/5

With 3 tools, the count is slightly low but appropriate for a focused price-checking domain. Each tool earns its place, and expanding to 4-5 would not harm, but the current count is reasonable.

Completeness4/5

The tools cover key operations: retrieving cheapest options, searching/filtering deals, and verifying a receipt price. Minor gaps exist, such as lacking a tool to list all brands or deals without filtering, but the core workflows are well-supported.

Maintenance

ActivityStale
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • espresso-mcp

    mattgierhart
    A
    license
    A
    quality
    D
    maintenance
    An MCP server that finds great espresso cafes using a curated database of specialty coffee shops and a transparent scoring algorithm, with a strong bias against flavored syrups and mass-market chains.
    6
    60
    MIT

  • cafe-mcp-server

    hanluOMH
    F
    license
    A
    quality
    B
    maintenance
    MCP server that recommends coffee based on preferences (mood, milk, caffeine, temperature) from a static menu; includes tools for listing menu, recommending, and explaining recommendations.
    3
    -

  • roastify-mcp

    lonniev
    A
    license
    Not graded
    quality
    A
    maintenance
    MCP server for the Roastify Developer API, letting AI agents browse the coffee catalog and generate packaging artwork, with paid tools settled in Bitcoin Lightning.
    Apache 2.0