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
The three tools have clear, non-overlapping purposes: search for jobs, get details of a specific job, and get salary benchmark data. There is no ambiguity between them.
All tool names follow a consistent verb_noun pattern: get_job, get_salary_benchmark, search_jobs. The verbs (get, search) and nouns are clear and uniformly formatted.
With only three tools, the server is somewhat minimal, but the tools cover the core job search and salary information needs. It is on the lower end of the acceptable range but not too thin given the focused domain.
The server provides search, detail retrieval, and salary benchmarks, but lacks CRUD operations like applying, saving, or updating job postings. It covers the primary read-only workflow, but additional features like filtering or applying would improve completeness.
search_jobs 로 찾은 공고 id 의 상세(자격요건·근무조건·급여·마감일)를 가져옵니다. Get details of a job posting by id.
| 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 and destructiveHint=false, so the safety profile is covered. The description adds value by naming what details are returned, which annotations do not specify. It does not discuss not-found behavior or auth, but this is a simple read with annotation coverage.
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 short sentences, one in Korean and one in English, with no filler. The key source constraint (id from search_jobs) is front-loaded, and every phrase contributes to understanding the tool's purpose.
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 only one parameter, clear annotations, and a simple read operation, the description is nearly complete. It lists the main returned fields but not the full response shape (no output schema exists), so a small gap remains regarding exact response structure and error cases.
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 schema already states the id is 'search_jobs 결과의 공고 id'. The description repeats the same relationship without adding new format, source, or edge-case guidance, so it earns the baseline score for schema-covered parameters.
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 ('가져옵니다' / 'Get details') and resource ('job posting by id'), and enumerates the detail fields (qualifications, working conditions, salary, deadline). It explicitly ties the id to search_jobs, which distinguishes it from the search sibling without needing to open the schema.
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 gives clear context: use this tool with an id obtained from search_jobs. It does not explicitly exclude alternatives like get_salary_benchmark, but the id-origin constraint makes the intended workflow obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
한국 럭셔리 리테일 매장직 연봉 벤치마크(만원, 연봉 기준)를 업종·경력별로 조회합니다. Salary benchmarks for Korean luxury/department store/duty-free retail staff 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 communicate readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context like the unit (만원, annual salary), but it does not disclose the exact return format, aggregation behavior, or any other operational quirks.
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 main sentence is front-loaded and the enum mappings are presented as compact lists, making the content scannable. The bilingual main sentence is somewhat redundant, and the enum lists partially repeat the schema, so it is not maximally tight.
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 read-only lookup with two enum parameters and no output schema, the description covers the subject, currency/unit, category meanings, experience levels, and includes English-language clarification. It would be more complete if it stated the expected return shape, but the scope is well-defined enough for an agent to call it correctly.
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 the baseline is 3, but the description adds real semantic value by mapping each enum code to a human-readable category or experience range (e.g., luxury=럭셔리 패션, entry=신입(0년)). This goes beyond the schema's bare '업종 코드' and '경력 코드' descriptions.
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 a specific verb ('조회합니다'), the resource (salary benchmark for Korean luxury retail staff), and the query dimensions (category/experience). It is unambiguous, though it does not explicitly distinguish itself from the sibling tools get_job and search_jobs; the benchmark scope makes that distinction fairly obvious.
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 explains what dimensions can be used but gives no guidance about when to choose this tool over get_job or search_jobs, and no exclusions or alternative conditions. Usage context is only implied by the tool's topic, not stated.
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 등). Search active retail job postings at luxury brand boutiques, department stores and duty-free shops in Korea (e.g. Chanel, Louis Vuitton, Rolex, Lotte Duty Free). 모든 인자는 선택입니다.
| 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 readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds a useful scoping behavior that only active/ongoing postings are returned, but it does not describe return shape, pagination, or failure behavior.
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 concise and front-loaded with the resource and intent before stating argument optionality. The bilingual phrasing is somewhat repetitive, but the English sentence adds distinct brand examples, so every clause still earns its place.
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 broad search tool with four fully documented optional parameters and read-only annotations, the description covers scope, job categories, example brands, and argument optionality. It is adequate for correct invocation, though explicit routing to get_job for individual posting details would strengthen it further.
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 have schema descriptions, so the schema carries the semantic load. The description's examples and role categories add search context but do not materially clarify parameter behavior beyond what the input schema already states, making baseline 3 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 states a specific verb and resource: searching active retail job postings at luxury brand boutiques, department stores, and duty-free shops in Korea. It also names concrete job roles (CA/SA/BA, beauty advisor, store manager, VMD) and brand examples, which clearly separates it from siblings like get_job and get_salary_benchmark.
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 clearly identifies when to use the tool: to search ongoing job postings in Korea, and it explicitly notes that all arguments are optional. It does not explicitly contrast with get_job or get_salary_benchmark, but the search-versus-get framing gives adequate context.
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.