Skip to main content
Glama

Get One Migrant Program by Fiscal Year

migrant_programs_program
Read-onlyIdempotent

One program of the Migrant Program Money Register by key: its label, agency and award-ID rule (the FAIN prefix pattern and the listings it is booked under, or the reviewed award list for contracts) with the register's evidence; the listing note where the program's money moved between assistance listings (the unaccompanied-children program booked under 93.566 from December 2024 and re-booked older obligations in September 2026, so a series by listing alone moves with that booking), and money by listing or by kind where the register gives it; by fiscal year, net obligations, positive obligations, de-obligations, transactions, recipients and new awards, each labelled with its fiscal year and the as-of date; the 10 largest recipients each fiscal year as the register ranks them, with their class; new awards in FY2025 and FY2026 by funding opportunity; the equal twelve-month windows; class shares by year; and, for State Reception and Placement, the awards placed outside the United States that are excluded. Every amount is an obligation from the award records (the government's commitment to pay), net of de-obligations, by action date; net obligations, positive obligations and de-obligations are separate stages, each labelled with its fiscal year and the as-of date, award-level outlays (only where the record carries them) are the record's cumulative figure to the as-of date, and they are never added across stages. Governments are kept apart from organisations: every amount names its recipient class from the register's reviewed table, never a single NGO total. A recipient is called an IRS-listed exempt organisation only where the register's IRS EO BMF match stands (by the reviewed EIN, or by exact name and state where the register marks the match by rule), shown with that record; other organisations read organisation, IRS status not matched. The tools never call a recipient nonprofit or faith-based, and no recipient is classified by religion. Lobbying reports (LDA), connected PACs (FEC), ICE and CBP contracts (the Pay-to-Play Register, where ICE detention sits) and super PAC gifts (the Super PAC Donors Register) are side columns: shown side by side, never added to program money and never put in date sequence with an award or a termination. Every answer carries the register's question note: these records show federal awards and the agencies' own termination records; they do not show how any recipient used the money or why an award was made or ended beyond what the record says. Every answer also carries the side-by-side caption, the as-of and retrieval dates, each file's date, the source page on morvs.ai and the licence. Institutions only: no beneficiary, staff member, executive or sole proprietor is named; withheld recipients and records appear only as counts and amounts.

Input Schema

NameRequiredDescriptionDefault
programYesRequired program key: orr_uc, orr_refugee_formula, orr_refugee_matching, orr_refugee_discretionary, orr_contracts, state_rp, fema_ssp or eoir_legal_access.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

B3.2/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the bar is lower, yet the description still adds substantial behavioral context: amounts are obligations net of de-obligations by action date, stages are never summed across, side columns (LDA, FEC, ICE/CBP, super PAC) are never added to program money, recipient classes always come from a reviewed table, and a question note about what the records do and do not show. These are real usage-relevant constraints beyond the structured fields; the only shortfall is that this value is delivered as an undifferentiated wall of text rather than prioritized.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

This is a single paragraph of roughly 300 words in which the actual purpose occupies the first clause and everything after is a dense content inventory plus methodology caveats. Sentences run long and chain multiple clauses with semicolons, so key constraints (side columns are never added, no individual is named) are hard to extract. The front-loading of the purpose is the only structural virtue.

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?

With no output schema, the description must convey what comes back, and it does so at length: fiscal-year-labelled stages, top-10 recipients with class, FY2025/26 new awards by funding opportunity, twelve-month windows, class shares, and the exclusion note for State R&P. It also discloses the register's provenance and caveats, making the tool callable without surprises; the omission is any hint about ordering, pagination, or response size.

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?

There is one required enum parameter with 100% schema description coverage, so the baseline is 3 and the schema already carries the full key list. The description adds partial meaning for a couple of keys — it explains the unaccompanied-children program is booked under 93.566 and that state_rp excludes awards placed outside the United States — but leaves the other six enum values (orr_refugee_formula, fema_ssp, eoir_legal_access, etc.) unexplained, so the added value is marginal rather than decisive.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening clause states a specific verb and resource: 'One program of the Migrant Program Money Register by key,' which tells an agent it is fetching a single program record rather than an aggregate. However, the description never names its siblings (migrant_programs_summary, migrant_programs_recipient, migrant_programs_terminations) or explains what makes this tool different from them, and the core purpose is buried under a long content inventory.

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?

There is no explicit when-to-use or when-not-to-use guidance, and no alternative tool is named despite three closely related migrant_programs_* siblings existing. An agent can infer from 'by key' that this is the single-program lookup, but it must infer it, and nothing prevents it from picking this tool when a summary or recipient-level tool is the better fit.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources