ImmigrationLayer

List form changes

list_form_changes

Read-only

Lists the form edition changes and the USCIS newsroom and Federal Register alerts ImmigrationLayer has recorded on or after a date, newest first. Edition changes cover the forms check_form_edition lists. Use it to catch up on what changed since a last check. For one form's current edition, use check_form_edition. To find alerts by keyword, use search_alerts. Returns at most 100 form edition changes and 100 alerts per page. Pass next_cursor as cursor, with the same since, to continue until next_cursor is null. Empty lists on the first page mean nothing was recorded since that date. Free, no sign-in required. Limit: 20 calls per minute per IP, then rate_limited. Not legal advice. Sources: uscis.gov form pages or dated web.archive.org captures of them, USCIS newsroom alerts, and Federal Register notices. The top-level source URL identifies the exact aggregate query, including the page cursor. Each alert and form change keeps its own source URL and content hash.

Input Schema

Name	Required	Description	Default
`since`	Yes	ISO 8601 date or date-time, e.g. "2026-08-01" or "2026-08-01T09:30:00Z"; returns changes on or after this instant. A date means midnight UTC; a date-time without an offset is UTC.
`cursor`	No	Opaque navigation cursor from the preceding page's next_cursor. Omit for the first page.

Output Schema

Name	Required	Description	Default
`data`	Yes
`as_of`	Yes
`source_url`	Yes
`content_hash`	Yes
`not_legal_advice`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 17, 2026

addedInput schema / properties / cursor

Added value: +{
+  "description": "Opaque navigation cursor from the preceding page's next_cursor. Omit for the first page.",
+  "maxLength": 4096,
+  "type": "string"
+}

addedOutput schema / properties / data / properties / next_cursor

Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 4096,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Pass this cursor with the same since to read the next page. Null means no more changes."
+}

changedOutput schema / properties / data / required

Previous value: -[
-  "form_editions",
-  "alerts"
-]New value: +[
+  "form_editions",
+  "alerts",
+  "next_cursor"
+]

First observedOct 15, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations cover the safety profile (readOnly, non-destructive, closed-world), and the description adds substantial context beyond them: 100-item-per-resource page caps, cursor continuation rules, the meaning of empty first-page lists, free/no-sign-in access, and a concrete 20-calls-per-minute-per-IP limit with the rate_limited failure mode. Source provenance and the per-item source URL/content hash round it out.

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?

Front-loaded with purpose and alternatives, and nearly every sentence carries operative information. The trailing provenance sentences about source URLs and content hashes are useful for verification but push the length near the limit for a two-parameter read tool.

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?

With an output schema present, return shape need not be explained. The description still covers pagination, rate limits, access cost, empty-result semantics, and data provenance — nothing an agent needs to call this correctly is missing.

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 baseline would be 3, but the description adds real semantics: cursor must be passed as next_cursor with the same since value and paginated until next_cursor is null. That is a non-obvious usage constraint not visible in the 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?

The first sentence names a specific verb and two concrete resources (form edition changes plus USCIS newsroom and Federal Register alerts), states the ordering (newest first) and the scope (edition changes are exactly those check_form_edition covers). This distinguishes it clearly from check_form_edition and search_alerts without opening either schema.

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

Usage Guidelines5/5

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

Explicitly states the use case ("catch up on what changed since a last check") and routes to both alternatives with their selecting conditions: check_form_edition for one form's current edition, search_alerts for keyword lookup. Both when-to-use and when-not-to-use are present.

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

All ImmigrationLayer tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?