Search live retail job postings at luxury boutiques, department stores and duty-free shops in Korea, and check salary benchmarks by category and experience.
Scored across 3 tools
search_jobs (query a list) and get_job (fetch one by id) share the job domain but are clearly separated by input type and output shape in the descriptions; get_salary_benchmark is a wholly distinct reference lookup. Minor residual risk that an agent jumps straight to get_job without an id, but descriptions make the search→get flow obvious.
All three names follow a strict verb_noun snake_case pattern (search_jobs, get_job, get_salary_benchmark) with predictable get_/search_ prefixes. No style mixing.
Three tools is on the lean side, but for a niche Korean luxury-retail job board the set (search, detail, salary reference) is coherent and every tool earns its place. Slightly under-scoped rather than padded.
Covers the core browse→detail→compensation loop, but there are notable gaps: no brand/company listing or filtering tool, no application/saved-job or alert operation, and the descriptions imply filters exist yet no dedicated facet-listing tool is exposed. Agents can work around most of this via search_jobs arguments, but coverage of the domain lifecycle is partial.
[메종 드 탤런트 명품 매장 채용] search_jobs 로 찾은 한국 백화점·면세점·명품 매장 판매직 채용공고 한 건의 상세(자격요건·근무조건·급여·마감일)를 가져옵니다. Gets the details (requirements, working conditions, salary, deadline) of one Korean luxury retail sales job posting by id. 결과 url 은 메종 드 탤런트 공고 상세 페이지이며, 지원은 그 페이지에서 원문 공고로 가거나 메종 드 탤런트에서 바로 합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | search_jobs 결과의 공고 id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered; the description adds genuine beyond-schema context: what the returned url represents (the Maison de Talent detail page) and how the application flow works from that page. It stops short of describing not-found/error behavior or pagination, which is why it is not a 5.
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 purpose is front-loaded and the sentences are purposeful, but the definition repeats the same content in Korean and English, and the bracketed campaign title adds little for an agent. Appropriately sized overall, yet with avoidable duplication.
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 read tool with no output schema and fully covered annotations, the description is complete: it says where the id comes from, what fields are returned, and what the url means. Only error/missing-record behavior is left unaddressed.
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 single id parameter is already documented with format and pattern. The description reinforces that the id comes from search_jobs results, which is mildly useful, but adds no syntax or format detail beyond the schema. 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?
States a specific verb and resource (fetch the details of a single Korean luxury retail sales job posting by id) and enumerates the returned fields (requirements, working conditions, salary, deadline). This clearly distinguishes it from the sibling search_jobs (list) and get_salary_benchmark without requiring the schema to be opened.
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 ties invocation to a prior search_jobs call ("search_jobs 로 찾은 ... 한 건"), which gives an agent a clear triggering context. It does not spell out exclusions (e.g. what to do when an id is unknown) or contrast against get_salary_benchmark, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[메종 드 탤런트 명품 매장 채용] 한국 백화점·면세점·명품 매장 판매직 연봉 벤치마크 추정치(만원, 연봉 기준)를 업종·경력별로 조회합니다. Estimated salary benchmarks (annual, in 10,000 KRW) for retail sales staff at luxury brands, department stores and duty-free shops in Korea, by category and experience. 업종: luxury=럭셔리 패션, cosmetics=뷰티/화장품, jewelry=시계/주얼리, fashion=패션/의류, food=프리미엄 F&B, department=백화점, dutyfree=면세점, lifestyle=라이프스타일. 경력: entry=신입(0년), junior=주니어(13년), mid=미들(35년), senior=시니어(5~10년), lead=리드(10년+).
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | 업종 코드 | |
| experience | No | 경력 코드(생략 시 전 구간) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish read-only, idempotent, closed-world behavior, so the description adds context beyond that structured data: the values are estimates, not authoritative figures; the unit is 10,000 KRW per year; and omitting 'experience' returns all ranges. Those details matter to an agent interpreting or citing the results. It does not cover data freshness or the granularity of the estimate (for example, a range versus a point value), which prevents a 5.
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 front-loaded with the core purpose in both Korean and English, then moves into a compact parameter legend. The Korean/English duplication of the purpose sentence is somewhat redundant, and only the Korean line carries the enum legend, leaving the English reader without it. It stays tight overall with no filler.
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 the description compensates by specifying that the return value is an annual estimate in units of 10,000 KRW. Combined with full enum semantics and the default behavior for the optional parameter, this is enough for correct invocation. It does not explain the shape of the response (a single figure versus a table by experience) or the data source and date, so it is not quite complete.
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%, but the schema only labels the parameters '업종 코드' and '경력 코드' with bare enum codes. The description maps every enum value to its Korean business meaning (luxury=럭셔리 패션, cosmetics=뷰티/화장품, etc.) and, crucially, gives the year bands behind each experience code (entry=0년, junior=1~3년 ... lead=10년+). This is real semantic value the schema does not contain.
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: retrieve annual salary benchmark estimates for retail sales staff at luxury brands, department stores and duty-free shops in Korea, broken down by category and experience. It is unmistakable what the tool returns. It does not mention the sibling tools (get_job, search_jobs), so it stops short of explicitly saying how it differs from them, but the subject matter (benchmarks rather than job postings) is inherently distinct.
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's usage: the output is '추정치/Estimated,' not a live posting, which hints that the tool is useful for reference rather than for finding a job. However, it never says when to call this instead of get_job or search_jobs, and it gives no prerequisites or exclusions. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[메종 드 탤런트 명품 매장 채용] 한국 백화점·면세점·명품 브랜드 매장 판매직의 진행 중인 채용공고(구인·채용 중인 일자리)를 검색합니다 — 판매직 CA/SA/BA, 뷰티 어드바이저, 매장 매니저, VMD 등. Searches open retail sales jobs and hiring posts at luxury brand boutiques, department stores and duty-free shops in Korea, Seoul and nationwide (e.g. Chanel, Louis Vuitton, Rolex, Lotte Duty Free). 결과 url 은 메종 드 탤런트 공고 상세 페이지이며, 그 페이지에서 원문 공고로 가거나 바로 지원할 수 있습니다. 모든 인자는 선택입니다.
| Name | Required | Description | Default |
|---|---|---|---|
| brand | No | 브랜드명 한글/영문 (예: 샤넬, Rolex, 루이비통) | |
| limit | No | 최대 결과 수(기본 5, 최대 10) | |
| query | No | 직무·키워드 (예: 판매, 뷰티 어드바이저, 매니저, 면세점) | |
| region | No | 근무 지역 (예: 서울, 강남구, 부산, 인천공항) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds genuine context beyond that: only currently-open/in-progress postings are returned, results are URLs to 메종 드 탤런트 detail pages from which the original posting or direct application is reachable, and the geographic scope is Korea/Seoul/nationwide.
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 front-loaded with the core action and scope, and each sentence carries content. It is somewhat longer than necessary because the Korean sentence is effectively restated in English, which adds length without new information.
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 no output schema, the description compensates by explaining that results are detail-page URLs usable for viewing the original posting or applying directly, plus the open-postings-only scope. What is missing is a pointer to get_job for retrieving a single posting's full detail, but for a filtered search tool the essentials are present.
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% with all four parameters individually documented, so the baseline is 3. The description mirrors the schema's themes (job categories map to query, brands map to brand) but adds no filtering semantics such as AND/OR behavior across brand+region+query or how matching is performed.
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 gives a concrete verb (검색합니다 / searches) and a precisely bounded resource: open retail sales postings at luxury boutiques, department stores and duty-free shops in Korea, with named job categories (CA/SA/BA, beauty advisor, store manager, VMD) and example brands. It does not explicitly distinguish itself from the sibling get_job, though 'open postings' vs. detail-fetch is reasonably inferable from the URL sentence.
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?
'모든 인자는 선택입니다' usefully tells the agent it can call this with zero filters, and the note that result URLs lead to detail pages where one can apply implies where to go next. However, no sibling is named (get_job for a single posting, get_salary_benchmark for pay data) and there is no explicit when-not guidance.
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.
get_jobget_salary_benchmarksearch_jobs
Add one secure layer between your agents and this server.