Skip to main content
Glama

Maison de Talents

명품·백화점·면세점 판매직 연봉 벤치마크

get_salary_benchmark
Read-only

한국 럭셔리 리테일 매장직 연봉 벤치마크(만원, 연봉 기준)를 업종·경력별로 조회합니다. 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년+).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
categoryYes업종 코드
experienceNo경력 코드(생략 시 전 구간)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.4/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources