Skip to main content
Glama

get_wage_data

Read-only

Get wage data for an occupation by SOC code.

This is the primary tool for querying BLS OEWS wage statistics.

occ_code: 6-digit SOC code without dash (e.g., '151252' for Software
Developers, '131082' for Project Management Specialists). See
list_common_soc_codes() for common mappings.

scope + area_code:
- 'national': no area_code needed (all US)
- 'state': area_code = 2-digit state FIPS (e.g., '51' for VA, '11' for DC)
- 'metro': area_code = 5-digit MSA code (e.g., '47900' for DC metro,
  '42660' for Seattle). See list_common_metros() for codes.

industry: 6-digit industry code for national-only breakdowns.
'000000' = all industries (default). Common:
'541000' (Professional, Scientific, and Technical Services),
'541500' (Computer Systems Design and Related Services),
'999100' (Federal Executive Branch (OEWS Designation)).
Industry breakdowns only work with scope='national'. Federal IT staff mostly fall under 15-1299 (Computer Occupations, All
Other), so 999100 with 15-1252 rests on few employees.

datatypes: list of 2-digit codes. Default uses IGCE set:
- '04' = Annual Mean Wage
- '13' = Annual Median
- '11' = Annual 10th Percentile
- '15' = Annual 90th Percentile
Hourly percentiles: '03' (Mean), '06' (10th), '07' (25th), '08'
(Median), '09' (75th), '10' (90th). Annual percentiles: '11' (10th),
'12' (25th), '13' (Median), '14' (75th), '15' (90th). Other: '01'
(Employment); '16' (Employment per 1,000 Jobs) and '17' (Location
Quotient) exist at state/metro scope only.

'02' (Employment RSE) and '05' (Mean Wage RSE) are relative standard
errors in percent, a measure of each estimate's reliability.

Data year defaults to the OEWS release bundled with this server
(get_data_status reports it). Do NOT pass the current calendar year:
OEWS publishes about a year in arrears. Other years are rejected.

Special values ('-', '*', '#') mean BLS did not publish the cell; the
attached footnote says why (annual-only occupation, sample too small).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "occ_code": "<occ_code>"
    },
    "name": "get_wage_data"
  }
}

Input Schema

NameRequiredDescriptionDefault
yearNo
scopeNonational
industryNo000000
occ_codeYes
area_codeNo
datatypesNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already cover the read-only safety profile, and the description adds substantial beyond-schema behavior: data year defaults to the bundled release, passing the current calendar year is rejected (OEWS lags ~a year), and special values ('-', '*', '#') indicate unpublished cells with footnotes explaining why.

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?

Front-loaded with purpose then parameter guidance in a readable order, but the datatypes section is long and partially redundant — it lists '11'/'13'/'15' in the default set and then re-enumerates the same annual percentile codes later, adding bulk.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 6-parameter tool this covers every input comprehensively, and since an output schema exists, the omission of return-value detail is appropriate. Nothing needed to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With schema description coverage at 0%, the description carries the full burden and delivers: occ_code format with examples, scope+area_code pairings with FIPS/MSA examples, a list of common industry codes with the '000000' default, and a full datatypes code legend including IGCE defaults and RSE meanings.

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?

The description opens with a specific verb and resource ('Get wage data for an occupation by SOC code') and explicitly claims primacy ('the primary tool for querying BLS OEWS wage statistics'), which distinguishes it from compare_occupations, compare_metros, and igce_wage_benchmark siblings.

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

Usage Guidelines4/5

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

It gives concrete routing guidance — see list_common_soc_codes for codes and list_common_metros for metro codes — and spells out the scope/area_code combinations and the rule that industry breakdowns only work with scope='national'. It stops short of explicitly contrasting with compare_occupations/igce_wage_benchmark, so the sibling selection is only implied.

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.