Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@h1b-sponsor-mcp Show top H-1B sponsors in Texas"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that lets an AI assistant query USCIS H-1B Employer Data Hub records: search a company's sponsorship history, rank the largest sponsors in a given US state, and read a summary of the dataset.
Built with the MCP Python SDK
(mcp >= 2.0) and the Python standard library — no pandas, no fuzzy-matching
dependency.
Kind | Name | Purpose |
Tool |
| Find employers by full or partial name. Case- and punctuation-insensitive, so |
Tool |
| Rank the largest sponsors in one state by approved petitions, counting only petitions filed from offices in that state. |
Resource |
| Dataset coverage, unique employer count, national approval/denial totals and approval rate. |
Related MCP server: h1b-mcp
Python 3.13+
Node.js 18+ — only if you want to run the MCP Inspector
git clone https://github.com/calvinlee326/h1b-sponsor-mcp.git
cd h1b-sponsor-mcp
uv syncuv sync creates .venv and installs the exact versions pinned in uv.lock.
The USCIS export is not redistributed in this repository. Download it yourself:
Open the H-1B Employer Data Hub.
Run a query (leave the filters empty for the full dataset) and export the
results. You will get a file named Employer Information.csv.
Move it into place:
mv ~/Downloads/"Employer Information.csv" data/h1b_employers.csvuscis.gov blocks non-browser clients. curl, wget and scripted fetches
return HTTP 403 regardless of User-Agent, so this step has to be done in a real
browser.
Despite the .csv extension, the export is UTF-16 encoded and tab-delimited.
Opening it with open(path) or parsing it with a comma delimiter will not work.
The loader in server.py handles both.
Expected columns:
Line by line, Fiscal Year, Employer (Petitioner) Name, Tax ID,
Industry (NAICS) Code, Petitioner City, Petitioner State, Petitioner Zip Code,
New Employment Approval, New Employment Denial,
Continuation Approval, Continuation Denial,
Change with Same Employer Approval, Change with Same Employer Denial,
New Concurrent Approval, New Concurrent Denial,
Change of Employer Approval, Change of Employer Denial,
Amended Approval, Amended DenialUSCIS splits petitions into six approval/denial categories. This differs from
the annual bulk export also published by USCIS, which uses Employer,
State, Initial Approval and Continuing Approval instead — that file is
not compatible with this server without editing the column constants at the
top of server.py.
A 40-row sample in the identical format is committed at
data/h1b_employers.sample.csv, so the repository is inspectable without the
41 MB download.
Add the server to claude_desktop_config.json:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"h1b-sponsor": {
"command": "/absolute/path/to/uv",
"args": [
"run",
"--directory",
"/absolute/path/to/h1b-sponsor-mcp",
"h1b-sponsor-mcp"
]
}
}
}Then fully quit Claude Desktop and reopen it (Cmd-Q on macOS — closing the window is not enough).
Both paths must be absolute; find your uv with which uv. --directory is
required because Claude Desktop launches servers with the working directory set
to /, so uv would otherwise never find this project. h1b-sponsor-mcp is
the console script declared in pyproject.toml, which survives moves better
than a hardcoded file path.
Once connected, ask things like:
How many H-1B petitions has Amazon sponsored?
Who are the top 5 H-1B sponsors in Washington state?
What's the overall H-1B approval rate in this dataset?
Test the server directly, bypassing Claude Desktop:
cd / && echo '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"t","version":"1"}}}' \
| /absolute/path/to/uv run --directory /absolute/path/to/h1b-sponsor-mcp h1b-sponsor-mcpA JSON-RPC response means the server is fine and the problem is in the client
config. A traceback means the problem is in the server. Run it from / — testing
from inside the project directory can succeed even when the config is wrong,
because uv finds pyproject.toml by walking up from the working directory.
Client logs are at ~/Library/Logs/Claude/mcp-server-h1b-sponsor.log.
Because the transport is stdio, anything written to stdout corrupts the
protocol stream. Use logging (stderr) when debugging, never print().
uv run mcp dev src/h1b_sponsor_mcp/server.py --with-editable .This opens a browser UI where you can list tools, inspect the JSON schemas
generated from the Python type hints, and call tools interactively. The URL
printed in the terminal includes an auth token and will not connect without it.
--with-editable . installs this project into the Inspector's environment.
mcp dev currently pulls Inspector v1, which is deprecated. For the current
version, skip mcp dev and point Inspector at the same command Claude Desktop
uses:
npx @modelcontextprotocol/inspector@latest \
uv run --directory "$PWD" h1b-sponsor-mcpuv run pytestTests run against the real USCIS export and skip automatically if
data/h1b_employers.csv is absent.
server.py builds two cached indexes on first use, both derived from a single
parse of the export:
employer_index() — one entry per employer, summed across every office and
fiscal year. Answers "how many people does Google sponsor" (3,629).
state_index() — one entry per (employer, state), grouped by state and
pre-sorted by approvals. Answers "who sponsors most in Texas" without
crediting a national employer's company-wide total to every state it appears
in (Google is 3,613 in CA and 16 in TX).
Both use functools.lru_cache, so the parse and aggregation happen on the first
tool call rather than at import. This keeps the MCP initialize handshake
instant, which matters because clients can time out during startup. A test
asserts the two indexes agree: per-state figures must sum to the national total.
Employer names are matched on a normalized key (lowercased, non-alphanumeric
characters removed). This also merges duplicate spellings in the source data —
AMAZON COM SERVICES LLC and AMAZON.COM SERVICES LLC are separate USCIS rows
for one company. Roughly 6,000 such duplicates collapse this way, and any merged
spellings are reported in an also_filed_as field.
Legal suffixes are not stripped. COGNIZANT ... US CORP and
COGNIZANT ... US remain separate entries, so some rankings understate a
company. Stripping CORP/INC/LLC would fix it but would also merge
genuinely distinct subsidiaries. Tax ID cannot disambiguate them because the
export masks it to four digits.
Data is loaded once per process. After replacing the CSV, restart the client to pick up the new file.
The config uses absolute paths. Moving or renaming the project directory breaks the Claude Desktop entry until the config is updated.
USCIS H-1B Employer Data Hub — public US government data. Approval and denial counts reflect petitions processed by USCIS, not individual workers; one employer may file several petitions for the same person across categories.
Rank the largest H-1B sponsors in one US state by approved petitions.
Counts only petitions filed from offices in that state, so a national employer appears with its local figures rather than its company-wide total. Covers fiscal years 2024-2026.
Args: state: Two-letter USPS code, e.g. "CA", "TX", "NY". Territories such as "PR" and "GU" are also present. limit: Maximum employers to return (1-50).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| state | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: it counts only petitions from offices in the given state (local figures, not company-wide), and covers fiscal years 2024-2026. This adds critical context beyond what the schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by behavioral nuances, then clear arg explanations. Every sentence is informative and no fluff, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, 0% schema coverage, output schema present), the description is complete: it explains what the tool does, its behavioral scope, and parameter details. The agent has sufficient information to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It thoroughly explains the state parameter with examples of USPS codes and territories, and the limit parameter with the allowed range (1-50). This adds substantial meaning beyond the bare schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool ranks the largest H-1B sponsors in a US state by approved petitions, with specific verb (rank) and resource (sponsors by state), distinguishing it from the sibling tool search_sponsors which likely searches sponsors without state-specific ranking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that the tool is for state-specific rankings counting local petitions, implicitly differentiating from search_sponsors which would cover broader searches. However, it lacks explicit guidance on when to use this tool versus the sibling, and does not state any prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find H-1B sponsoring employers whose name contains the given text.
Matching ignores case and punctuation, so "amazon.com" matches "AMAZON COM SERVICES LLC". Results cover fiscal years 2024-2026 and are aggregated across all of an employer's offices, ranked by total approvals.
Args: company_name: Full or partial company name, e.g. "google" or "infosys". limit: Maximum employers to return (1-50).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| company_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behaviors: case/punctuation insensitivity, fiscal year coverage, aggregation across offices, and ranking by total approvals. This is sufficient for understanding the tool's operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with two paragraphs. Each sentence adds value, and no extraneous information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a moderate complexity and an output schema (not shown), so return values are covered. The description explains matching behavior, aggregation, ranking, and parameters, making it complete for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by describing 'company_name' as a full or partial name with examples, and 'limit' with a default (10) and range (1-50), which are not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds H-1B sponsoring employers by name, specifying the data range (2024-2026) and aggregation across offices. It distinguishes from the sibling tool 'get_top_sponsors_by_state' by focusing on name-based search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (searching by company name) with examples. It does not explicitly state when not to use or list alternative tools, but the sibling tool name hints at a different use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_top_sponsors_by_statesearch_sponsorsScored across 2 tools
The two tools have clearly distinct purposes: one searches by company name, the other ranks sponsors by state. There is no overlap or ambiguity.
Both tool names follow a consistent verb_noun snake_case pattern (search_sponsors, get_top_sponsors_by_state), which is predictable and clear.
With only 2 tools, the server feels thin for the stated purpose of H-1B sponsor data. While the tools are focused, a more complete service would typically have 5-10 tools.
The surface lacks essential operations such as fetching detailed sponsor records, filtering by industry or year, or listing all sponsors. Only basic search and state ranking are provided, leaving significant gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
US H-1B visa sponsorship, LCA wages & top sponsors by role — recruiting/talent data
Access US federal award, recipient, agency, and spending analytics data from USAspending.gov.
Pay-per-call US government data: carrier safety, visa sponsors, contracts, employer risk.
Query US Census Bureau data: demographics, economics, and housing statistics.