Skip to main content
Glama

Find Migrant Program Award Recipients

migrant_programs_recipient
Read-onlyIdempotent

Look up a recipient in the Migrant Program Money Register by name substring as the award records name it, by the register's family name, or by its exact 12-character UEI, optionally limited to one program. Returns up to 5 published recipients, each with its UEI, states, reviewed class and the basis for it, and the IRS Exempt Organizations Business Master File record where one matches (EIN, the name and state the IRS lists, and the IRS's own codes); money by program and fiscal year; its 10 largest awards with obligations by fiscal year and award-level outlays as recorded, each labelled; its termination records in the agency's exact words with their dates; the subaward rows its prime awards report, as counts only (the register gives no subawardee total); and the register's side-by-side columns for its family: program money, LDA lobbying reports, connected PACs, ICE and CBP contracts and super PAC gifts, with the caption. An empty column is a search result, not a fact about the organisation. 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. Terminations appear only in the agency's exact words with their dates; where the record gives no words the answer says the record gives no reason, and an executive-order tag appears only as the record shows it. 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. A name that matches only a withheld string answers exactly like a name that matches nothing.

Input Schema

NameRequiredDescriptionDefault
nameYesRequired case-insensitive recipient name substring as filed, a family name or an exact 12-character UEI; at most 80 characters; published recipients only.
programNoOptional program key, for example orr_uc, state_rp or fema_ssp: only recipients with money in that program, with that program's figures.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.8/5.0
Behavior5/5

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

Beyond the annotations, the description discloses a wealth of behavioral context: it returns up to 5 published recipients, empty columns are search results not facts, amounts are obligations net of de-obligations by action date, stages are never added, IRS matching is conditional, terminations appear only in exact words, side columns are never combined with program money, and every answer carries a question note, caption, as-of/retrieval dates, source page, and licence. This is exactly the kind of context annotations do not carry.

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?

The purpose is front-loaded, but the description is an extremely long run-on paragraph that repeats caveats about amounts, IRS matching, and side columns. For a two-parameter lookup tool, much of this could be compressed or moved to structured documentation without losing meaning.

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?

Given the tool's complexity, rich input schema, and absence of an output schema, the description is complete. It explains return values, edge cases, institutional-scope restrictions, and the handling of withheld names, so an agent has enough context to call the tool correctly.

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%, so the schema already documents both parameters in detail. The description adds only marginal clarification ('as the award records name it', 'published recipients only') beyond the schema's own descriptions, so it sits at the baseline for full schema coverage.

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 description states a specific verb and resource: 'Look up a recipient in the Migrant Program Money Register by name substring... by family name, or by exact 12-character UEI, optionally limited to one program.' This clearly distinguishes a recipient-level lookup from program-level siblings, though it never names those siblings explicitly.

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?

Usage is implied by the description ('Look up a recipient... optionally limited to one program') and by the detail about what is returned, but there is no explicit when-to-use/when-not-to-use guidance. The nearest siblings (migrant_programs_program, migrant_programs_summary, migrant_programs_terminations) are not mentioned as alternatives, leaving the agent to infer routing.

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