Skip to main content
Glama

Cheapest eSIM Korea (최저가e심)

Travel eSIM prices by country & days (나라·일수별 eSIM·유심 가격)

find_esim_prices
Read-onlyIdempotent

Verified daily prices of travel eSIMs (and physical SIMs) sold to Korean travelers on Naver SmartStore, for a destination country or major city (54 countries, e.g., japan/일본/오사카/tokyo, vietnam/베트남/다낭) and trip length (1-30 days, or Korean trip phrases like "3박 4일", "일주일", "한 달"). Returns sellers ranked by reviews (or price) and the cheapest price under the same rules as the website (pagePrice), plus cheapest daily-cap, total-cap, USIM/eSIM, and adjacent-day (N-1 / N+1 days) alternatives. Plan types: unlimited, daily (N GB/day), total (N GB total). 해외여행 eSIM(또는 실물 유심) 판매처 가격을 나라(또는 주요 도시)·이용 일수별로 조회합니다. 네이버 스마트스토어 판매처의 옵션가를 매일 수집·검증한 값이며, 판매처는 리뷰 많은 순(또는 싼 순), 화면 최저가(pagePrice)는 웹·앱 화면과 같은 규칙입니다.

Input Schema

NameRequiredDescriptionDefault
gbNodaily: 하루 용량 0.5·1·2·3·5 / total: 총 용량 3·5·10·20·30·50
daysNo이용 일수 1~30 (기본 3, 예: 3박 4일 여행이면 4)
formNoesim(기본) 또는 usim(배송비 포함가)
sortNo무제한 목록 정렬: reviews(리뷰 많은 순, 기본) 또는 price(싼 순)
typeNo요금제 종류: unlimited(완전 무제한, 기본), daily(하루 용량제), total(기간 총량제)
limitNo판매처 수 (기본 10)
countryYes나라 또는 주요 도시 (예: japan, 일본, 오사카, tokyo, vietnam, 베트남, 다낭, 방콕, 발리)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / country / description
      Previous value: -"나라 (예: japan, 일본, vietnam, 베트남)"New value: +"나라 또는 주요 도시 (예: japan, 일본, 오사카, tokyo, vietnam, 베트남, 다낭, 방콕, 발리)"
    • changedInput schema / properties / days / description
      Previous value: -"이용 일수 (기본 3)"New value: +"이용 일수 1~30 (기본 3, 예: 3박 4일 여행이면 4)"
    • addedInput schema / properties / sort
      Added value: +{
      +  "description": "무제한 목록 정렬: reviews(리뷰 많은 순, 기본) 또는 price(싼 순)",
      +  "enum": [
      +    "reviews",
      +    "price"
      +  ],
      +  "type": "string"
      +}
    • changedInput schema / properties / type / description
      Previous value: -"요금제 종류 (기본 unlimited)"New value: +"요금제 종류: unlimited(완전 무제한, 기본), daily(하루 용량제), total(기간 총량제)"
  2. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the description earns credit for adding provenance and freshness context: data is 'collected and verified daily' from Naver SmartStore, and pagePrice follows the same rules as the website/app. It still omits auth needs, rate limits, and failure behavior for unknown countries.

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

Conciseness3/5

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

Core purpose is front-loaded in the first clause, which is good, but the body is a near-verbatim bilingual duplication (Korean and English say the same thing), effectively doubling length without adding information for the agent.

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 7 parameters, no output schema, and no nested objects, the description does the needed work of explaining the return shape: sellers ranked by reviews or price, cheapest pagePrice, and cheapest daily-cap/total-cap/USIM/adjacent-day alternatives. Missing edge-case behavior (unknown country/city, no results) keeps it short of full completeness.

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 description coverage is 100%, so the schema already documents every parameter including plan types, day ranges, and the '3박 4일 → days=4' convention. The description largely restates plan types (unlimited/daily/total) and ranking rules already in the enum descriptions, adding little parameter-level meaning beyond the schema baseline.

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?

States a specific verb+resource with full scope: verified daily eSIM/SIM prices from Naver SmartStore, keyed by destination country or major city (54 countries) and trip length. The single-destination framing plus the explicit 'for a destination country or major city' qualifier implicitly separates it from siblings like compare_countries and get_price_trend.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: the description makes clear this is the per-country/per-duration price lookup, but it never names an alternative or gives a when-not-to-use condition, despite siblings (compare_countries, get_price_trend, get_seller_profile) that clearly overlap in domain.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.