Skip to main content
Glama

Find Media Award Recipient Families

media_money_family
Read-onlyIdempotent

Look up a reviewed recipient family in the Media Money Register by a substring of its name, of a parent company the register names, or of a name its award records carry, optionally limited to one block (A1 news publishers and wires, A2 information and data companies, A3 broadcasters and studios, B public broadcasting, C the U.S. Agency for Global Media's grantees, C2 media-development grantees). Returns up to 5 families, each with its block, reviewed UEIs and DUNS numbers, the names its award records carry, contract and grant obligations by fiscal year and by agency, its largest product codes, the split by what the awards are for (news families) or what the awards are for in the register's words (information companies, never counted as news), its termination actions by window with FPDS's reason codes, and the side columns: its connected PAC's contributions to candidates' committees and to all committees by FEC cycle (no committee it gave to, candidate or party is named), its 2025 lobbying reports (in-house expenses and outside firms' income are each the report's total for all issues and are never added together), the 2025 inaugural committee's report and the reviewed super PAC donors, with the caption. Families come from a reviewed table of identifiers, never a name search; an empty column is a search result, not a fact about the company. Recipients whose award records name a family's identifier as parent but which are not reviewed members are listed with their amounts and not counted in the family. Each figure is named in its record's own words: contract obligations (a subscription is a purchase order, delivery order or definitive contract), grant obligations by assistance listing, Treasury account obligations, termination actions with FPDS's reason code as printed, and the laws' own text; fiscal year 2026 is as reported through the as-of date, as Defense Department contract records reach USAspending about 90 days late. The blocks (news publishers and wires; information and data companies, never counted as news; broadcasters and studios; public broadcasting; the U.S. Agency for Global Media's grantees, described in the law's words; media-development grantees; federal advertising and public relations) are never added together, and a contract, a grant and a Treasury account are never added to one another. The side columns (connected-PAC money from the FEC bulk files, 2025 lobbying reports from lda.gov, the 2025 inaugural committee's report and the reviewed super PAC donors) are separate records shown side by side: never added to award money or to each other, and never put in date sequence with an award or a termination. Every answer carries the register's question note: these records show federal award and account obligations and the agencies' own termination records; they do not show what any outlet published, why an award was made or ended, or whether any payment affected coverage. Every answer also carries the side-by-side caption, the as-of date, each file's date, the source page on morvs.ai and the licence. Where FEC figures appear, the answer quotes the FEC's restriction on the sale or use of individual contributor information (52 U.S.C. 30111(a)(4)). Institutions only: no official, consultant, journalist, treasurer or candidate is named; withheld recipients and the advertising firms whose name is a person's full name appear only as counts. A name that matches only a withheld string answers exactly like a name that matches nothing. No party label is given and no outlet's content is characterised.

Input Schema

NameRequiredDescriptionDefault
nameYesRequired case-insensitive substring of a reviewed family name, a parent company or a name its award records carry, for example Politico; at most 80 characters.
blockNoOptional block: A1 news publishers and wires, A2 information companies, A3 broadcasters, B public broadcasting, C USAGM grantees, C2 media development.

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?

Annotations already declare readOnly=true, openWorld=true, idempotent=true, destructive=false. The description adds extensive behavioral context: what is returned (up to 5 families with blocks, UEIs, obligations, side columns), crucial caveats ('empty column is a search result, not a fact'), data provenance, the FEC restriction quote, and the caption requirement. This far exceeds what annotations alone provide.

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 description is a single, extremely dense paragraph packed with caveats, legal citations, and data-model rules. While nearly every sentence carries substantive information, the lack of structure (bullets, paragraphs) makes it hard to parse and front-load the essential call guidance. It is over-long for practical consumption.

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, the absence of an output schema, and the rich annotation set, the description is exceptionally complete. It covers return values, data provenance, non-additivity rules, as-of dates, source attribution, and institutional-use restrictions—leaving no major gap for correct invocation.

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 both parameters are already fully documented in the input schema. The description reinforces the meaning of 'name' (substring of family name, parent company, or award record name) and the block enum, but adds little beyond what the schema already states. Baseline 3 is appropriate.

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?

States a specific verb ('Look up'), resource ('reviewed recipient family in the Media Money Register'), and scope ('by a substring of its name, of a parent company... optionally limited to one block'). The detailed return-field list differentiates it from summary or terminations siblings, though it never names those alternatives 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?

Provides context such as 'Families come from a reviewed table of identifiers, never a name search' and explains withheld-name matching, but never explicitly states when to use this tool versus media_money_summary, media_money_advertising, or media_money_terminations. Usage is implied rather than routed.

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