Skip to main content
Glama

Get Migrant Program Money Totals

migrant_programs_summary
Read-onlyIdempotent

Totals from the Migrant Program Money Register, built from USAspending award records, HHS's TAGGS terminated-grants list and the IRS Exempt Organizations Business Master File: federal obligations, FY2023 to FY2026, to the organisations and governments that shelter, care for, resettle, transport and give legal help to migrants and refugees, in eight programs keyed from the award ID (ORR unaccompanied-children grants and ORR contracts, ORR refugee formula, Matching Grant and discretionary grants, State Department Reception and Placement, FEMA's Shelter and Services Program and DOJ EOIR legal access). Returns the all-programs total with its basis; money by program and fiscal year, with net obligations, positive obligations and de-obligations labelled; the equal twelve-month windows either side of January 20, 2025; recipient-class shares by program and year, with state, local and tribal governments apart from organisations and organisations split by IRS match; FEMA's Shelter and Services de-obligations of February 10 to 12, 2025 (the record gives no reason), with the government share; termination records counted by agency and record type; withheld recipients and records as counts and amounts; the exclusions, the awards placed outside the United States listed with their amounts; and the register's headlines with their basis. Awards whose record places the work outside the United States are excluded from every figure, as are FEMA's Emergency Food and Shelter Program and ICE detention money. 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.

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.9/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, open-world behaviour, but the description goes far past them: it states which awards are excluded (non-US work, EFSP, ICE detention), that obligations are net of de-obligations by action date, that outlays are never summed across stages, that side columns (LDA, FEC, Pay-to-Play, Super PAC) are never added to program money, and that withheld recipients appear only as counts. That is unusually rich methodological context that no structured field carries.

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 core definition is front-loaded, but the whole thing is a single ~600-word paragraph with no sentence breaks, bullets or headings, mixing return contents, source provenance, exclusion rules, methodology and six regulatory caveats into one block. Much of it is substantive, but the absence of any structure makes it hard for an agent to extract the operative constraints under token pressure.

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?

For a no-parameter, no-output-schema aggregate tool, the description covers what is returned (all-programs total, program×year money, twelve-month windows around Jan 20 2025, recipient-class shares, FEMA de-obligations, termination counts, exclusions, headlines), what is deliberately omitted, and every mandatory caveat the answer must carry. Nothing needed to call it correctly or interpret its output 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?

The tool takes no parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The description correctly adds no parameter prose and instead spends its words on scope and caveats.

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 names a specific verb and resource — 'Totals from the Migrant Program Money Register' — and enumerates the eight programs (ORR, Matching Grant, R&P, FEMA SSP, EOIR) plus the data sources, so an agent knows exactly what the tool computes. It does not, however, name or contrast itself against the obvious siblings migrant_programs_program, migrant_programs_recipient and migrant_programs_terminations, leaving that differentiation implicit.

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?

Use is only implied: repeatedly calling itself the all-programs total and listing program-, recipient- and termination-level breakdowns signals that the per-entity work lives elsewhere. There is no explicit 'use this when you want the overall picture; use migrant_programs_recipient for a single entity' statement, so the agent must infer the 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