Skip to main content
Glama

Wage: what a job pays, by place

check_wage
Read-only

Returns what a job pays. In the US, for a metro area, a state or the whole country, from the Bureau of Labor Statistics Occupational Employment and Wage Statistics (May 2025, all industries): median yearly pay, the 10th to 90th percentile range and how many people do the job. In Canada, from Statistics Canada: median and average hourly pay for the job group, by province. Elsewhere, average monthly pay of employees by broad job group (managers, professionals, technicians, trades and more) in local currency, from the International Labour Organization's ILOSTAT. Eligible European countries also include the published national minimum wage in euros, where available. Inputs are a job title and, in the US, an optional city or state. Applies to questions about what a job pays. The change in purchasing power of old dollars is outside this result.

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": {
      "job": "<job>"
    },
    "name": "check_wage"
  }
}

Input Schema

NameRequiredDescriptionDefault
jobYesJob title, e.g. 'registered nurse', 'electrician', 'software developer'
placeNoUS only: city ('Seattle', 'Austin, TX'), state ('WA' or 'Washington'), or leave out for national
countryNoCountry name or two-letter code; defaults to the United States

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / country
      Added value: +{
      +  "description": "Country name or two-letter code; defaults to the United States",
      +  "maxLength": 60,
      +  "type": "string"
      +}
    • changedInput schema / properties / place / description
      Previous value: -"City ('Seattle', 'Austin, TX'), state ('WA' or 'Washington'), or leave out for national"New value: +"US only: city ('Seattle', 'Austin, TX'), state ('WA' or 'Washington'), or leave out for national"
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare readOnly/openWorld; the description adds substantial context the agent could not otherwise know: data vintage (May 2025, all industries), which statistics are returned per region (median yearly, 10th-90th percentile, employment count in the US; median and average hourly by province in Canada; average monthly by broad job group in local currency elsewhere), and that minimum wage in EUR is only available for eligible European countries. It also flags a known limitation (inflation adjustment is out of scope).

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?

Structure is front-loaded and purposeful: what it returns, then US, Canada, elsewhere, then an extra field, then inputs, then scope. It is long, but nearly every clause carries information the agent needs to interpret the result. The geographic breakdown could be tightened slightly, but nothing is redundant 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?

There is no output schema, so the description carries the burden of explaining return values, and it does so per region, including units, currency and available measures. It also covers defaults (country defaults to US per schema) and the one out-of-scope case, leaving no significant gap for a read-only lookup tool.

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 meaning: it clarifies that 'place' only applies in the US while country determines which data source, cadence and output measures apply (yearly vs hourly vs monthly, EUR minimum wage only in some countries). It does not add syntax details beyond the schema, which already provides examples.

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?

Opens with a precise verb+resource statement ('Returns what a job pays'), then scopes it by geography and names the exact statistical sources (BLS OEWS, Statistics Canada, ILOSTAT). It also explicitly rules out the adjacent concept of purchasing power of old dollars, separating it from check_inflation without needing to open either schema.

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?

States the domain of applicability ('Applies to questions about what a job pays') and gives an explicit exclusion (inflation/purchasing-power questions). It stops short of naming the sibling tool to use instead, so the agent must infer that check_inflation or check_rates handles the excluded case.

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