Skip to main content
Glama

LiveDataLink

by io.github.blackboxfoundry

talent_market_brief

Read-onlyIdempotent

One-call 'can I hire this role here, and at what cost' read for an occupation in a US geography. Joins two independent federal sources: BLS OEWS (Occupational Employment and Wage Statistics, keyless) for the occupation's employment LEVEL and wage distribution (mean plus 10th / 50th-median / 90th annual percentiles) in the area, and US Census ACS labor-force context (civilian labor force and local unemployment rate - needs a Census API key) to band how TIGHT / BALANCED / SLACK the local hiring market is. Pass an 'occupation' (e.g. 'registered nurses', 'software developers') or an explicit 'soc_code' (e.g. '29-1141'), and an optional 'state' or 'metro' (defaults to national). Returns a readable brief with a headline (employment, median/mean wage, market tightness), the wage percentiles, and per-source evidence. The BLS OEWS leg is the core signal and is keyless; the Census leg degrades gracefully if no key is set. Informational, NOT a guarantee that a role can be filled at any given wage.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
metroNoOptional 5-digit CBSA/metro code (e.g. '12420' Austin, TX). OEWS metro coverage varies; an unmatched metro is noted, not fatal.
stateNoOptional 2-letter state code or 2-digit FIPS (e.g. 'TX', '48'). Omit for a national read.
soc_codeNoExplicit 6-digit SOC occupation code, with or without a dash (e.g. '29-1141' registered nurses, '15-1252' software developers). Overrides 'occupation'.
occupationYesFree-text occupation to map to a SOC code (e.g. 'registered nurses', 'software developers', 'electricians'). Provide this or 'soc_code'.

TDQS

A4.6/5.0
Behavior5/5

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

The description adds substantial behavioral context beyond the read-only/idempotent annotations: it explains the keyless BLS OEWS leg, the Census key requirement, graceful degradation when no key is set, the exact output components, and the explicit 'NOT a guarantee' caveat. This gives an agent an accurate picture of data dependencies and limitations.

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 description is front-loaded with the core purpose and compactly covers sources, inputs, output, failure behavior, and caveats. It is somewhat dense with parenthetical detail, but every sentence contributes practical information and none is redundant with the schema.

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 read-only tool without an output schema, the description is remarkably complete: it states what inputs are needed, what the caller will receive, how the two data sources behave under key presence/absence, and how to interpret the result. An agent has enough to select and invoke this tool 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 schema already documents all four parameters well. The description still adds useful semantics: the either-or relationship between 'occupation' and 'soc_code', the override precedence of 'soc_code', and the national default when geography is omitted.

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, plain-language objective ('can I hire this role here, and at what cost') and names the exact resource: an occupation in a US geography. It further differentiates from siblings by describing the two-source BLS OEWS + Census ACS join, which clearly marks this as a labor-market brief rather than a generic BLS or Census query.

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?

The description clearly establishes the intended use case: a one-call read on occupation-level hiring feasibility and wage cost in a US area. It stops short of naming exclusion criteria or explicit alternatives among the many BLS/Census sibling tools, but the use context is unambiguous.

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

All LiveDataLink toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.2/5.0
Disambiguation2/5

Many tools overlap heavily across domains: caselaw_search vs court_case_search vs court_opinion_search, caselaw_citation_lookup vs court_citation_resolver, and a cluster of company due-diligence tools (company_trust_check, counterparty_risk_score, entity_dossier, issuer_diligence_dossier, kyb_aml_evidence_case_file) that all screen a company for sanctions/risk/standing. With 290 tools, an agent will frequently face multiple equally plausible choices for the same user intent.

Naming Consistency3/5

The vast majority of tools follow a clean domain-prefix + snake_case pattern (census_, eia_, fmcsa_, npi_, cfpb_, etc.), but there are notable exceptions: entity_resolve and resolve_entity are reversed duplicates, reg_search (Federal Register) sits next to reg_cfr_search (CFR) with confusingly similar names, and carrier_monitor_recheck deviates from the carrier_vetting_* family.

Tool Count1/5

290 tools is an extreme count under any rubric, far exceeding even the 50+ threshold for the lowest score. While the group-filtering mechanism and meta-tools like list_tool_groups and search_available_datasets mitigate the practical burden, the raw surface is still massively oversized for an agent to select from accurately and efficiently.

Completeness4/5

For a read-only data-aggregation server, coverage is remarkably comprehensive across 59 domains, and generic fallbacks like cdc_dataset_query, eia_series_lookup, fred_observations, and bls_series prevent most dead ends. Minor gaps exist (a single GitHub tool, demo-only property_lookup coverage, no write/update operations anywhere), but the stated data-access purpose is well served.

Resources