BLS OEWS

igce_wage_benchmark

Read-only

Get wage benchmarks formatted for IGCE development.

Returns annual and hourly wages at the mean and the 10th, 25th, median,
75th, and 90th percentiles (25th/75th are the usual junior/senior
anchors), plus estimated burdened hourly rates using the specified
burden multiplier range. Hourly figures are BLS's published hourly
wages (annual / 2080 only where BLS publishes no hourly wage). Also
returns the cell's employment and relative standard errors
(reliability) and flags thin estimates.

Wages are point-in-time estimates for the OEWS reference month
(wage_period in the response), not current rates: escalate them to the
period of performance before pricing.

BLS wages are BASE wages (no fringe, overhead, G&A, or profit).
Multiply by a burden factor to estimate fully-loaded rates:
- 1.5x-1.7x: lean contractor
- 1.8x-2.2x: mid-range professional services (default)
- 2.0x-2.5x: large contractor with clearance overhead
- 2.5x-3.0x: high-overhead (SCIF, deployed)

The burdened range should roughly align with GSA CALC+ ceiling rates
for comparable labor categories. If CALC+ >> burdened BLS, the role
may require specialized skills or clearance overhead. Document the gap.

Burden multipliers must be positive and burden_low <= burden_high.
Reasonable range: 1.3 (lean) to 4.0 (high-overhead/clearance).

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": "igce_wage_benchmark"
  }
}

Input Schema

Name	Required	Default
`year`	No
`scope`	No	national
`occ_code`	Yes
`area_code`	No
`burden_low`	No
`burden_high`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 21, 2026

TDQS

A4/5.0

Behavior5/5

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

Goes well beyond the readOnly/non-destructive annotations: discloses that wages are point-in-time OEWS estimates needing escalation, that figures are base wages without fringe/overhead/G&A/profit, that thin estimates are flagged, and that RSEs are returned as a reliability signal. It also states validation constraints (multipliers positive, burden_low <= burden_high, 1.3-4.0 reasonable range) that prevent malformed calls.

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 what the tool returns, followed by interpretation guidance; every section is task-relevant. It is long and slightly redundant (base-wage caveat restated around the burden table), but no sentence is pure filler.

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 an IGCE benchmark tool this covers the loop an agent needs: what is returned, why escalation is required, how burden factors map to contract types, and how to sanity-check against CALC+. Missed area/scope parameter coupling is the only real gap, and the return-value contract is already carried by the output schema.

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

Parameters3/5

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

Schema description coverage is 0%, so the description must carry all parameter meaning. It handles burden_low/burden_high thoroughly (defaults implied by the 1.8x-2.2x 'mid-range' tier, bounds, monotonicity) but says nothing about occ_code format, area_code, the national/state/metro scope enum, or year semantics, leaving four of six parameters undocumented anywhere.

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?

States a specific verb and resource ('Get wage benchmarks') scoped to a concrete use case (IGCE development), and enumerates exactly what comes back (percentiles, burdened rates, employment/RSE). It does not explicitly distinguish itself from the sibling get_wage_data, so an agent must infer that this is the IGCE-formatted variant rather than the raw feed.

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

Usage Guidelines3/5

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

Strong domain guidance on how to apply results (escalate point-in-time wages, pick a burden tier, cross-check against GSA CALC+ ceilings), which implies the tool's role in a pricing workflow. However, no sentence tells the agent when to call this versus get_wage_data or compare_occupations, and no prerequisites for scope/area_code combinations are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All BLS OEWS tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.