h1b-sponsor-mcp

Ask Claude "is this company still sponsoring H-1Bs?" and get a straight answer in tables, built from 1.28 million public government filings plus USCIS approval records.

An MCP server for job seekers who'll need visa sponsorship. It combines all three public sponsorship signals for each employer, shows how they've moved over the last six months against the same months a year earlier, and runs locally on a database that updates each quarter.

You:     Compare Microsoft, Amazon, Google, Meta, Apple, Nvidia and TCS for data scientist sponsorship.
Claude:  (calls compare_companies)

_{Real output, data through Jun 30, 2026. LCA and PERM columns are filtered to data-scientist roles; the USCIS columns are company-wide.}

That one table answers three questions most sponsorship sites can't. Is the company still filing this year, and in which direction? And will it take you through to a green card? Amazon and Google are filing plenty of H-1Bs for data scientists, but certified almost no green-card (PERM) cases for them in the last 12 months. And how often does USCIS turn this employer down? TCS's 6.1% denial rate is more than twice the national 2.5%, so it's flagged.

What it can answer

Every answer is a markdown table that names its date window ("Jan–Jun 2026", never just "last 6 months") and says what the numbers do and don't mean.

Every verdict and flag starts with a signal, so a table reads at a glance: 🟢 good · 🟡 caution · 🔴 warning · ⚪ not enough data. The word after the signal says the same thing, for anyone reading without emoji.

Install

You need uv. The package is on PyPI. The first run downloads the database (about 61 MB compressed) and caches it; after that everything is local and offline.

Claude Desktop: add to claude_desktop_config.json:

{
  "mcpServers": {
    "h1b-sponsor": {
      "command": "uvx",
      "args": ["h1b-sponsor-mcp"]
    }
  }
}

Claude Code:

claude mcp add h1b-sponsor -- uvx h1b-sponsor-mcp

Any other MCP client works the same way: run uvx h1b-sponsor-mcp over stdio. To run the newest code from GitHub instead of the PyPI release, use uvx --from git+https://github.com/janishkumar/h1b-sponsor-mcp h1b-sponsor-mcp.

Where the numbers come from

How current is it? DOL publishes each quarter about 5–6 weeks after it ends, so the data is between 1.5 and 5 months old at any time. Every H-1B site uses these same files, so none can be fresher. Windows are anchored on the newest decision in the data, not today, so "last 6 months" is always a fully covered window.

What an LCA is not. An LCA is a filing an employer makes before an H-1B petition. It covers new hires, renewals and transfers, and some never become petitions. Treat LCA counts as an upper bound on sponsorship activity. The USCIS columns are the confirmed side.

Denial-rate flags. Each employer's USCIS denial rate over the last full fiscal year plus the current one is compared with the national rate over the same years (2.5% for FY2025–FY2026 Q3):

Both flags need at least 20 decisions and 3 denials, so a single denial at a small firm doesn't produce a scary flag. New-employment petitions (the F-1/OPT → H-1B route) get their own rate in company_sponsorship. USCIS doesn't publish job titles, so denial rates are company-wide even when you filter by role.

"Still sponsoring?" is a rule, not a model. It looks at certified LCAs in the last 6 months against the same months a year earlier:

How it's built

flowchart LR
    A[DOL LCA xlsx<br/>5 files, 1 GB] --> C[Standardise<br/>de-duplicate by case number<br/>drop contact details]
    B[DOL PERM xlsx] --> C
    U[USCIS crosstab<br/>UTF-16 export] --> C
    C --> E[Employer resolution<br/>names + federal tax IDs]
    E --> D[(sponsors.duckdb<br/>111 MB)]
    D -->|gzip, GitHub release| R[Release asset]
    R -->|downloaded once,<br/>update check daily| S[MCP server<br/>stdio, read-only]

• Employer names are messy. Names that file under a shared federal tax ID are merged: "Amazon.com Services LLC", "AMAZON.COM SERVICES LLC", "Amazon Web Services, Inc." and "Amazon Development Center U.S., Inc." count as one employer. Two guards stop bad merges. A tax ID shared by more than 12 names is almost always a payroll provider, so it's ignored. And a name only joins a tax ID's cluster if its first word matches the main filer's. 1.28M filings resolve to 156,896 employers.
• Search matches whole leading words. "Amazon" finds Amazon.com Services, Amazon Web Services and Amazon Data Services, and lists them, so you can see exactly what was counted. If a name catches something unrelated ("Apple" also matches Apple Tree Dental), find_employer gives you the exact name to pass instead.
• No personal data ships. The source files include employer contact names, emails and phone numbers, plus attorneys and preparers. The build drops all of it, and a test checks that the published database contains none of those columns.
• Lean runtime. The server installs only mcp, duckdb and platformdirs. Answers take under a second.

What didn't work (and what replaced it)

• Tax IDs alone over-merge. The first build merged everything that ever shared a tax ID, and "Amazon" came back with TechCorp Solutions Inc. in it: a small firm whose 21 filings list one of Amazon's tax IDs, almost certainly a keying error. A name now joins a tax ID's cluster only if its first word matches the main filer's. A regression test covers it.
• "Last 6 months" was off by a day. Subtracting six months from June 30 lands on December 30, so the first window read "Dec 2025–Jun 2026". Windows are now whole calendar months (Jan–Jun 2026 vs Jan–Jun 2025), with tests for month-end and mid-month anchors.
• Prefix search catches neighbours. "Apple" also matches Apple Tree Dental. Fuzzy brand matching would hide that rather than fix it, so every answer lists the entities it counted, and find_employer gives you the exact name to narrow it.
• The government sites block scripts. The plan was a scheduled GitHub Action that refreshed the data every quarter. DOL and USCIS both return 403 to automated downloads, and DOL's official data API (45 datasets) doesn't carry LCA or PERM. So the download stays a two-minute browser step, and everything around it is automated: a watcher that says when and what to download, a gated make refresh, and a weekly health check of the published release.

Compared with other H-1B MCP servers

I checked what already existed before building this. As of October 2026:

Keeping the data fresh

DOL publishes a new quarter about six weeks after it ends. DOL and USCIS refuse scripted downloads, and DOL's data API doesn't include these datasets, so one step stays human: about two minutes in a browser each quarter. Everything else is automated:

flowchart LR
    W[Watcher<br/>1st and 15th of release months] -->|new data found| N[Notification with<br/>exact files to get]
    N --> H[You: download 2-3 files<br/>into ~/Downloads]
    H --> R[make refresh]
    R --> C[collect, retire old years]
    C --> B[rebuild]
    B --> G{quality gates}
    G -->|fail| X[stop, nothing published]
    G -->|pass| D[before/after diff, confirm]
    D --> P[GitHub release]
    P --> U[users' servers update within a day]
    P --> HC[weekly health check in CI]

Manual steps, if you'd rather not wait for the watcher:

1. From the DOL performance data page, download the newest LCA_Disclosure_Data_FY… and PERM_Disclosure_Data_FY… files.
2. From the USCIS H-1B Employer Data Hub, use Crosstab View → the last four fiscal years → Download → CSV.
3. Run make refresh and enter the USCIS quarter when asked (e.g. FY2026 Q4).

Development

make setup && make test

59 tests run on a synthetic fixture with one planted example of each case: a company that's slowing, one that's steady, one that's stopped, a payroll-provider tax ID, a duplicate case number, a non-H-1B visa class, and a contact-email column that must not survive the build. They also start the real server over stdio and call it as an MCP client would, and they run the refresh pipeline end to end with the gates both passing and failing. CI runs on Python 3.11–3.13, checks that the wheel installs without the build extras, and runs a dependency audit and secret scan.

Code and data are released separately. Data releases are GitHub releases tagged data-YYYY-MM-DD, and the server downloads the newest one. Code releases are version tags: bump the version in pyproject.toml and server.json, then push a tag like v0.1.1, and release.yml publishes to PyPI and the MCP registry through trusted publishing, with no stored tokens.

Not legal advice

This is public filing data. It can't tell you whether a particular team will sponsor a particular role, and policies change. Ask the employer.