Skip to main content
Glama

bls_employment

US employment data direct from Bureau of Labor Statistics: unemployment rate, nonfarm payrolls, labor participation, hourly earnings, labor force.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / additionalProperties
      Added value: +false
  2. First observed

TDQS

A3.7/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral transparency. It states that the data comes directly from BLS and lists topics, but it does not disclose the output format, whether it returns a time series or point-in-time values, or any operational behaviors like update frequency or access restrictions. This is minimal and leaves room for surprises beyond the obvious read-only implication.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that front-loads the key resource ('US employment data direct from Bureau of Labor Statistics') and follows with a compact bullet-like list of the exact series included. There is no filler or redundancy; every word adds informational value.

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

Completeness3/5

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

The tool is simple (no parameters, no output schema), but the description does not clarify the return structure—whether it provides a monthly snapshot, historical series, or individual values, nor the units or seasonal adjustments. With no output schema to fill this gap, the description is incomplete for a caller to predict the response format confidently.

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?

The input schema has zero parameters, so there is nothing to explain. The description appropriately omits parameter details, and the 100% schema coverage means no information gap exists. According to the rubric, a zero-parameter tool gets a baseline of 4.

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 clearly identifies the tool's output as US employment data sourced from BLS and enumerates five specific indicators (unemployment rate, nonfarm payrolls, labor participation, hourly earnings, labor force). This specificity distinguishes it from sibling tools like bls_inflation, which cover a different domain, and bls_series, which is generic.

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?

The implied usage is when a caller needs US employment metrics, but there is no explicit guidance on when to choose this tool over alternatives such as labor_market or bls_series. It does not mention exclusions or provide comparison with siblings, scoring at the implied level rather than a fully guided one.

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.