Korean local-currency (지역화폐) discounts: fuel rates, effective prices, merchant search, deep links.
Scored across 5 tools
The five tools have largely distinct purposes: region listing, local-currency metadata, price calculation, link generation, and merchant search. The only mild friction is between effective_fuel_price (compute one price from a price the user supplies) and oilpicker_link (delegate finding the cheapest station to a UI), but the descriptions explicitly disambiguate these and even warn that local_currency_for_region does not return prices.
All names use consistent snake_case with clear, descriptive wording. However, the verb_noun pattern is only followed by list_regions and search_merchants, while effective_fuel_price, local_currency_for_region, and oilpicker_link are bare noun phrases, so the predictable pattern breaks down slightly.
Five tools is a compact, well-scoped set for a narrow domain (Korean oil prices plus local-currency discounts), and each tool maps to a distinct capability without filler. It sits at the lean end of the acceptable range, so it is slightly thin but justified.
The core user goal — finding the cheapest station for a region and fuel type — has no tool that returns station prices or a ranking; effective_fuel_price requires the caller to already know a price, and oilpicker_link pushes the actual lookup to a link the user must open. Region and merchant coverage are also limited to regions with published lists, which is disclosed but leaves agents unable to complete the main task end-to-end.
주유소 표시 가격(원/L)과 지역을 받아 그 지역 지역화폐로 결제할 때의 실질 가격을 계산합니다. 선할인형은 가격×(1−할인율), 추가 충전형은 가격÷(1+적립률)입니다.
| Name | Required | Description | Default |
|---|---|---|---|
| region | Yes | 지역 이름. 예: '수원', '경기 수원시', '대전', '춘천시', '제주'. 도 단위 지역은 시·군까지 적어야 합니다. | |
| pump_price | Yes | 주유소 표시 가격(원/L). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does well to disclose the two calculation modes and their exact formulas, signalling a pure computation. It omits what happens when the region is unrecognized or has no local currency, and says nothing about the response shape, which matters for an unannotated tool.
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?
Two tight sentences: the first front-loads inputs and output, the second supplies the two formulas. Nothing is repeated and nothing is padded.
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?
There is no output schema and no annotations, so the description should sketch what comes back (real price, implied discount amount, matched region/currency). It explains the math but not the return payload or error behavior, leaving a real gap for a compute 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%, so both parameters are already fully documented in the schema, including the region-format guidance and the 500–5000 price bound. The description adds no format or constraint detail beyond what the schema provides; baseline 3 applies.
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?
Names a specific verb (계산합니다) and a specific computed quantity (실질 주유가), and states both inputs it consumes (표시 가격, 지역). It does not distinguish itself from siblings like local_currency_for_region, which also concerns regional discount data, so the agent gets no explicit routing help.
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?
Usage is only implied: an agent can infer it should call this when it has a pump price and a region and wants the post-benefit price. There is no statement of when not to use it, no prerequisite that the region must be a recognized local-currency region, and no pointer to list_regions for resolving region strings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
OilPicker가 지역화폐를 아는 시·도 목록, 또는 sido를 주면 그 시·도의 시·군 목록을 돌려줍니다.
| Name | Required | Description | Default |
|---|---|---|---|
| sido | No | 예: '경기도', '강원특별자치도'. 비우면 시·도 목록. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It clearly implies a read-only listing operation and describes the conditional return content, but it does not cover error behavior, return format details, or any rate/auth considerations.
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 definition is a single efficient sentence with no wasted wording. The default behavior is front-loaded and the conditional sido behavior follows naturally.
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?
For a simple one-parameter listing tool with full schema coverage and no output schema, the description provides enough information to invoke it correctly. It reasonably explains both output modes, though it could be slightly more explicit about the returned 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?
The input schema already has 100% description coverage for the single optional sido parameter. The tool description adds meaning by clarifying that supplying sido switches the output from a sido list to that sido's si/gun list, which goes slightly beyond the schema text.
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 states a clear verb and resource: it returns a list of supported sido regions, or si/gun regions when a sido is supplied. This makes the tool's scope easy to distinguish from siblings, though it does not explicitly name or contrast those siblings.
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?
It explains the two operational modes: omit sido to get the top-level region list, or provide sido to get its subregions. However, it does not state when to choose this tool over alternatives such as local_currency_for_region, so usage guidance is mostly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
한국의 지역(시·군 또는 광역시)에서 쓰는 지역화폐와 이번 달 주유 할인율, 월 한도, 출처, 기준일을 알려 줍니다. 주유소별 가격은 주지 않습니다. 가격은 함께 돌려주는 OilPicker 링크에서 확인하도록 안내하세요.
| Name | Required | Description | Default |
|---|---|---|---|
| region | Yes | 지역 이름. 예: '수원', '경기 수원시', '대전', '춘천시', '제주'. 도 단위 지역은 시·군까지 적어야 합니다. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does reasonably well: it discloses the returned data set including source and 기준일 (base date), plus the side effect that an OilPicker link comes back with the result. It does not state error behavior for unknown or non-normalized regions, or how current the monthly rate is beyond the base date field.
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?
Three short sentences: what it returns, what it does not return, and what the agent should do instead. The most decision-relevant facts are front-loaded with zero padding.
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?
With one parameter, no annotations, and no output schema, the description usefully enumerates the return fields an agent would otherwise not know. It would be fully complete if it said what happens when the region is unknown or ambiguous (e.g., return an error vs. suggestions).
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% and the region parameter already documents naming conventions with concrete examples ('수원', '경기 수원시', '제주') and the province-level caveat. The description adds no additional meaning about the parameter, so baseline 3 applies.
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 states a specific verb and resource in Korean and enumerates exactly what is returned: local currency type, this month's fuel discount rate, monthly limit, source, and base date. It also rules out per-station pricing. It does not name the sibling effective_fuel_price, which is the tool an agent might reasonably confuse it with given both are fuel-price-adjacent.
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 what this tool will not do, and the description instructs the agent to redirect price inquiries to the returned OilPicker link — that is a clear when-not and a handoff. The gap is that it never tells the agent to use list_regions to resolve a valid region name, nor contrasts with effective_fuel_price for actual pump prices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
지역과 유종을 미리 고른 OilPicker 링크를 만듭니다. 링크를 열면 그 지역 지도와 지역화폐 실질가 순위가 바로 보입니다. 사용자에게 가장 싼 주유소를 찾아 주려면 이 링크를 전달하세요.
| Name | Required | Description | Default |
|---|---|---|---|
| fuel | No | 유종. 기본값은 휘발유. | |
| region | No | 지역 이름. 예: '수원', '경기 수원시', '대전', '춘천시', '제주'. 도 단위 지역은 시·군까지 적어야 합니다. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It helpfully explains that opening the link shows the regional map and local-currency real-price ranking, but it does not clarify the return format (e.g., a URL string), whether the link is persistent, or any side effects or permissions involved.
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 three short sentences and front-loads the core action before explaining the outcome and usage. It is efficient, though slightly repetitive around the concept of the link.
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?
For a simple two-parameter link generator with complete schema coverage and no output schema, the description gives enough context to call it correctly. The main remaining gap is explicit return type, but the behavior after opening the link is described.
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 both parameters, including enum values for fuel and region examples. The description reinforces that region and fuel are preselected into the link but adds no syntax or format details beyond the 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 states a specific action and resource: creating a preconfigured OilPicker link for a selected region and fuel type. It distinguishes the tool implicitly from siblings like effective_fuel_price and list_regions by focusing on link generation, though it does not name those alternatives.
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?
It gives a clear usage context: pass this link to a user who needs to find the cheapest gas station. However, it does not explain when to use effective_fuel_price or list_regions instead, so exclusions and alternatives are left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
지역화폐를 받는 가맹점(음식점, 마트, 병원, 주유소 등 모든 업종)을 지역과 검색어로 찾습니다. 시·군과 대전시가 공개한 가맹점 목록을 씁니다. 목록이 있는 지역만 답하며, 없는 지역이면 목록이 있는 지역을 알려 줍니다.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 최대 결과 수. 기본 20. | |
| query | No | 상호·주소·업종 검색어. 여러 단어는 모두 포함. 예: '국밥', '중앙로 약국'. 비우면 앞에서부터. | |
| region | Yes | 지역 이름. 예: '수원', '경기 수원시', '대전', '춘천시', '제주'. 도 단위 지역은 시·군까지 적어야 합니다. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does real work: it names the data source (시·군 및 대전시 공개 가맹점 목록), discloses the coverage limitation (only regions with lists), and describes the fallback behavior for unsupported regions. It stops short of describing the shape or ordering of returned results.
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?
Three short sentences, front-loaded with the core purpose, then data source, then coverage caveat. No filler, though the coverage caveat could be folded tighter.
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?
For a 3-parameter read tool with no annotations and no output schema, the description covers purpose, source, and the important limitation that some regions will not return results. Only the returned fields/ordering are unaddressed, a minor gap given the schema carries the parameters.
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 region, query, and limit are already fully documented with examples and semantics. The description only restates that lookup is by region and search term, adding no syntax or edge-case detail beyond the 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?
States a specific verb and resource ('지역화폐를 받는 가맹점 ... 찾습니다') plus the scope of business types and the two lookup keys (region, query). The mention that it only answers regions with published lists, and redirects otherwise, clearly separates it from list_regions.
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?
Usage context is clear: use it to find local-currency merchants given a region and optional search term. The fallback sentence ('목록이 있는 지역을 알려 줍니다') implicitly hands off discovery to list_regions, but no sibling is named explicitly and there are no stated exclusions.
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.
search_merchantseffective_fuel_pricelist_regionslocal_currency_for_regionoilpicker_linkSearch KR/US products, dated options and unit prices; original merchant affiliate purchase links.
Real-time fuel prices, alerts, and cheapest gas stations across 38+ countries.
Korean MVNO(알뜰폰) plans checked 5x daily on carriers' official sites: search, cheapest, price history
Korea-native MCP gateway: Korean commerce, payments, messaging, gov & finance APIs for AI agents.
Add one secure layer between your agents and this server.
