Skip to main content
Glama

Govparse Government Data Gateway

by io.govparse

oflc_feed_workforce

Which employers filed U.S. work-visa cases — H-1B LCA, PERM, and the seasonal-labor programs H-2A, H-2B, and CW-1 — for what roles, wages, worksites, and how many seasonal workers over what period of need? Employer-level bulk feed over DOL OFLC disclosure files: one flat row per case decided since a date, cursor-paginated up to 1000/page, filterable by program, worksite state, SOC, or employer name. Rows add employer FEIN where filed, SEC CIK/ticker where public, and as_published_date. [price: $0.05/row]

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
socNoSOC occupation code. Example: 15-1252 (software developers).
limitNoRows per page (default 500, cap 1000).
sinceYesInclude cases with a decision date on or after this date (YYYY-MM-DD). Required.
stateNoWorksite state code(s), CSV.
cursorNoOpaque page cursor — pass the previous page's next_cursor unchanged.
programNoWhich OFLC programs to include (CSV): lca | perm (default; professional workers) or the seasonal-labor programs h2a (agricultural) | h2b (non-ag seasonal) | cw1 (CNMI). Seasonal rows add workers_requested/certified, the period-of-need window, and nature_of_temporary_need.
employerNoEmployer name, punctuation-insensitive exact match ('Amazon.com Services LLC' matches 'AMAZON COM SERVICES LLC').

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • addedInput schema / properties / program
      Added value: +{
+  "description": "Which OFLC programs to include (CSV): lca | perm (default; professional workers) or the seasonal-labor programs h2a (agricultural) | h2b (non-ag seasonal) | cw1 (CNMI). Seasonal rows add workers_requested/certified, the period-of-need window, and nature_of_temporary_need.",
+  "examples": [
+    "h2a,h2b"
+  ],
+  "type": "string"
+}
  2. First observed

TDQS

A4.2/5.0
Behavior4/5

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

No annotations exist, so the description carries full burden. It discloses pagination (cursor-based, up to 1000/page), filtering capabilities, and output fields (FEIN, SEC CIK/ticker, as_published_date). It also notes extra fields for seasonal programs and pricing ($0.05/row). No contradictions. Missing details on rate limits or response structure beyond what's mentioned.

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 focused paragraph front-loaded with a question. Every sentence adds value: purpose, filtering, pagination, pricing, and special behavior for seasonal programs. No redundant or filler sentences.

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

Completeness4/5

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

Given the complexity (7 params, no output schema, no annotations), the description covers purpose, filtering, pagination, output fields, and pricing. It explains key differences for seasonal programs. While an explicit list of all output fields would improve completeness, it is sufficient for effective tool selection and invocation.

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 100%, so the baseline is 3. The description adds overall context (cursor pagination, seasonal extra fields, pricing) but does not enhance per-parameter semantics beyond what the schema already provides. It provides enough to understand parameter usage but not exceptional added value.

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 starts with a clear question summarizing the tool's purpose: which employers filed which visa cases for what roles, wages, worksites, and seasonal workers. It then explicitly states 'Employer-level bulk feed over DOL OFLC disclosure files,' distinguishing it from sibling tools like oflc_sponsor_dossier (single employer detail) and oflc_sponsor_search (search).

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 states this is a 'bulk feed' for employer-level data, implying use when needing many cases rather than a single employer. It lists filterable dimensions (program, state, SOC, employer) but does not explicitly say when not to use or mention alternatives by name. The context is clear enough for appropriate selection.

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

All Govparse Government Data Gateway 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

A4.2/5.0
Disambiguation5/5

Each tool targets a distinct domain and specific action (e.g., FDA approvals vs clearances vs recalls; firmstanding business360 dossier vs search vs screen). Even overlapping concepts like 'business360' vs 'business360_lookup' are distinguished by input (UUID vs name+state). No two tools appear to do the same thing.

Naming Consistency5/5

All tools use a consistent lowercase snake_case pattern with domain prefix (e.g., fda_*, firmstanding_*, fmcsa_*, govcon_*). Action words (search, lookup, screen, feed, stats) follow predictable usage. The naming is uniform and easy to parse.

Tool Count4/5

38 tools is on the higher end but appropriate for a comprehensive government data gateway spanning multiple agencies and datasets. Each domain has a reasonable number of tools (e.g., FMCSA: 7, OFLC: 6). Could potentially be trimmed slightly, but overall well-scoped for the stated purpose.

Completeness5/5

The tool surface covers the major government data sources comprehensively: FDA (approvals, clearances, recalls), FMCSA (carrier census, safety, insurance, etc.), FSIS, DOJ/OFLC, OSHA/EPA/DOL enforcement, SEC insider filings, clinical trials, VA facilities/opportunities/vendors, and federal contracting. No obvious gaps for the stated gateway purpose.

Resources