Skip to main content
Glama
tushariitr-19

immigration-mcp

by tushariitr-19
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Remote

immigration-mcp

Go Version License: MIT tushariitr-19/immigration-mcp MCP server

⚠️ Disclaimer: This tool is for informational purposes only and does not constitute legal advice. Always consult a qualified immigration attorney for decisions about your specific case. Data is sourced from official government websites (USCIS, State Department) but may not reflect the most recent updates.

An MCP (Model Context Protocol) server for US immigration guidance — live Visa Bulletin, priority date checker, USCIS news, and immigration term explanations.

Built with the official Go MCP SDK.

Why immigration-mcp?

Navigating US immigration is complex and expensive. immigration-mcp gives AI agents access to live, structured immigration data from official government sources — so you can ask questions in plain English and get accurate, up-to-date answers.

  • Free — powered by public government data sources (USCIS, State Department)

  • Live data — fetches the latest Visa Bulletin monthly, USCIS news daily

  • Open source — MIT licensed

  • Production grade — structured logging, graceful shutdown, unit tested

Related MCP server: h1b-mcp

Available Tools

Tool

Description

get_visa_bulletin

Fetch the latest US Visa Bulletin with employment-based priority dates by country and category

check_priority_date

Check if your priority date is current for I-485 filing

explain_term

Plain English explanation of any immigration term

Example Prompts

Once connected to Claude Desktop:

  • "What are the current EB2 priority dates for India?"

  • "My priority date is March 2015, I'm from India EB2 — can I file I-485 this month?"

  • "Has EB2 India moved forward compared to last month?"

  • "What is the difference between Final Action Date and Date for Filing?"

  • "Are there any recent USCIS policy changes affecting H1B holders?"

  • "What documents do I need to file I-485?"

Prerequisites

  • Go 1.25+

  • No API keys required — powered by public government data

Setup

1. Install

git clone https://github.com/tushariitr-19/immigration-mcp
cd immigration-mcp
go build -o immigration-mcp-server ./cmd/server/

2. Configure Claude Desktop

Add to your Claude Desktop config (claude_desktop_config.json):

{
  "mcpServers": {
    "immigration-mcp": {
      "command": "/path/to/immigration-mcp-server",
      "env": {
        "DEBUG": "false"
      }
    }
  }
}

Optional:

export DEBUG=true   # enables debug logging

Screenshots

Available Tools

Available Tools

explain_term in action

Explain Term

Architecture

immigration-mcp/
├── cmd/server/main.go        ← entry point, env vars, graceful shutdown
├── server/server.go          ← MCP server setup, tool registration
├── tools/
│   ├── visa_bulletin.go      ← get_visa_bulletin tool
│   ├── priority_date.go      ← check_priority_date tool
│   └── explain_term.go       ← explain_term tool
├── util/
│   ├── util.go               ← shared helper functions
│   └── constants.go          ← shared constants
├── models/
│   └── models.go             ← shared data models
├── tests/
│   └── visa_bulletin_test.go ← unit tests
├── logger/
│   └── logger.go             ← structured logging via zap
└── Dockerfile

Each tool is self-contained — the server is agnostic of what tools do internally. Adding a new tool is a single line in server/server.go.

Running Tests

# Unit tests only
make test-unit

# Integration tests only
make test-integration

# All tests
make test

# Build binary
make build

Contributing

PRs welcome. To add a new tool:

  1. Create tools/<toolname>.go

  2. Define your input struct and tool definition

  3. Register it in server/server.go with one line

  4. Add unit tests in tests/<toolname>_test.go

License

MIT

Available Tools

3 tools
check_priority_dateB

Check if your priority date is current for I-485 filing based on the latest Visa Bulletin

ParametersJSON Schema
NameRequiredDescriptionDefault
countryYescountry of birth e.g. India, China, Mexico, Philippines, Worldwide
categoryYesemployment-based category e.g. EB1, EB2, EB3
priority_dateYesyour priority date in YYYY-MM-DD format e.g. 2015-03-10

TDQS

B3.4/5.0
Behavior2/5

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

No annotations provided, so description fully responsible. It only states the core behavior (check if date is current) but omits side effects, error handling, caching, or what the output looks like.

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?

Single, front-loaded sentence with no extraneous words. Every word adds value.

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

Completeness2/5

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

Lacks output schema, so description should hint at return format, but it does not. Missing information on validation, errors, and how the result is presented (e.g., boolean or message).

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% with inline examples, so the description adds no extra meaning beyond what is already in the schema. Baseline score of 3 is appropriate.

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?

States specific verb ('Check') and resource ('priority date current for I-485 filing'), clearly differentiating from sibling tools get_visa_bulletin (retrieves bulletin) and explain_term (explains terms).

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?

Implies usage context (have a priority date, country, category) but does not explicitly state when to use this tool versus siblings or provide conditions for not using it.

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

explain_termA

Get a plain English explanation of any US immigration term, form, or concept

ParametersJSON Schema
NameRequiredDescriptionDefault
termYesthe immigration term to explain e.g. 'priority date', 'H1B', 'EAD', 'AC21'

TDQS

A3.6/5.0
Behavior2/5

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

No annotations are provided, so the description bears full burden for behavioral transparency. It only states that the tool returns a 'plain English explanation' but does not disclose output format, length, source, or any side effects. Given the absence of annotations, this is insufficient.

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 concise sentence that immediately conveys the tool's purpose. No superfluous information, and it is front-loaded for quick scanning.

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 tool's simplicity (one required string parameter, no output schema), the description covers the core purpose and parameter adequately. However, missing details about the return value (e.g., format, length) slightly reduce completeness.

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 coverage is 100%, so the parameter 'term' is already well-documented with description and examples. The tool description adds marginal value by indicating the explanation is in 'plain English', but does not enhance understanding of the parameter beyond what the schema provides.

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?

Description clearly states the verb 'Get a plain English explanation' and the resource 'any US immigration term, form, or concept'. It distinguishes from sibling tools 'check_priority_date' and 'get_visa_bulletin' which are specific to particular artifacts, while this tool covers all terms.

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 description does not provide explicit guidance on when to use this tool versus alternatives. It implies usage for general immigration terminology, but fails to mention when to use siblings (e.g., for priority date or visa bulletin specific queries). No exclusions or prerequisites are given.

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

get_visa_bulletinB

Fetch the latest US Visa Bulletin with employment-based priority dates by country and category

ParametersJSON Schema
NameRequiredDescriptionDefault
monthNothe month to fetch e.g. 'may', defaults to current month
yearNothe year to fetch e.g. '2026', defaults to current year

TDQS

B3.3/5.0
Behavior2/5

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

No annotations provided, so description carries full burden. It only says 'Fetch' implying read-only, but lacks details on rate limits, authentication, error handling, or response format.

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?

Single sentence, efficient, front-loaded with key information, no unnecessary words.

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?

Covers core purpose but misses details like whether family-based categories are included, response format, or handling of unavailable bulletins. Adequate for simple tool with optional params.

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 has 100% description coverage for both parameters, so baseline 3. Description adds context about employment-based data but does not significantly enhance parameter meaning beyond schema.

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?

Description clearly states verb 'Fetch', resource 'US Visa Bulletin', and specifies 'employment-based priority dates by country and category', distinguishing it from siblings check_priority_date and explain_term.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. Does not mention context or exclusions like bulletins not available for certain periods.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv1.0.0
    • First observedcheck_priority_date
    • First observedexplain_term
    • First observedget_visa_bulletin
Deploy Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a distinct and unambiguous purpose: checking priority dates, explaining terms, and fetching the visa bulletin. There is no overlap.

Naming Consistency5/5

All tool names follow the consistent verb_noun pattern in snake_case, making them predictable and easy to parse.

Tool Count4/5

With 3 tools, the set is slightly small but covers core functionalities for immigration information. It is reasonable for a specialized server.

Completeness4/5

The tools address key aspects of US immigration (priority dates, visa bulletin, term explanations) but could benefit from additional features like form lookup or fee calculators.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers