MORVS

Find Inaugural Committee Donors

inaugural_donors_donor

Read-onlyIdempotent

Look up an organisation donor in the Inaugural Donors Register by name substring, matched against the reviewed public name and every name as filed on the committees' Form 13 reports, optionally for one inaugural year (2025 or 2021; both when omitted, never added across years). Returns up to 5 named organisation donors, each with its reviewed type and, by year, donations accepted, refunded and net (each labelled), every donation row with its date, amount, memo and filing as filed, refunds kept apart (the filing gives no reason for any refund) and the latest filing date. For 2025 donors: the organisation's own LD-203 figure where an item was found and matched, with both amounts and, where they differ, the line that neither record explains the difference; and, for the donors in the register's side-by-side table, three more federal records beside the donation: contract obligations by fiscal year under reviewed parent records (USAspending), the connected PAC's status and its contributions to federal candidates' committees by cycle with its all-committees summary line, two measures never added (FEC), and 2025 lobbying report counts and amounts (LDA). Inaugural donations, contract obligations, connected-PAC contributions and lobbying reports are separate federal records, shown side by side and never added or put in sequence. A missing PAC, contract or lobbying record is a search result, not a fact about the organisation. Committees are named exactly as the FEC lists them, with their ids. Every answer carries the register's question note: the records describe donations reported to the FEC; they do not show what any donor received or intended, and they do not show cause and effect. Individual donors are counted, never named; withheld organisations (personal trusts, holding vehicles, businesses named for a person, names resting on initials) appear only as counts and amounts. A name that matches only a withheld string answers exactly like a name that matches nothing. Every answer quotes the FEC's restriction on the sale or use of individual contributor information (52 U.S.C. 30111(a)(4)).

Input Schema

Name	Required	Description	Default
`name`	Yes	Required case-insensitive organisation name substring, at most 80 characters; searched among named organisation donors only.
`year`	No	Optional inaugural year, 2025 (Trump Vance Inaugural Committee) or 2021 (PIC 2021); both when omitted, never added.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 26, 2026
- removedInput schema / properties / year / enum
```
Removed value: -[
-  2025,
-  2021
-]
```
- addedInput schema / properties / year / maximum
```
Added value: +2100
```
- addedInput schema / properties / year / minimum
```
Added value: +1900
```
AddedOct 25, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the readOnly/openWorld/idempotent annotations, the description discloses matching against reviewed and as-filed names, a five-result cap, year-by-year donation/refund/net breakdowns, side-by-side federal records that are never added, and the rule that missing PAC/contract/lobbying records are search results rather than facts. It also explains withheld-organisation behavior and the mandatory FEC restriction, which is unusually rich behavioral context without contradicting the annotations.

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

Conciseness3/5

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

The purpose is front-loaded, and the length is partly justified because there is no output schema. However, the description is a dense single block with long compound sentences and repeated caveats, so it is adequate but not concise or well structured.

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 a complex, annotation-heavy lookup with no output schema, the description is complete enough: it explains what is returned, how years are handled, which records are separate, what missing data means, and the legal/contextual caveats. An agent can call the tool correctly without needing more documentation.

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 schema already defines both parameters. The description still adds useful semantics by saying the name substring is matched against the reviewed public name and every name as filed on Form 13 reports, and it reinforces the year omission rule even though the year schema also states it.

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 description opens with a specific verb and resource: 'Look up an organisation donor in the Inaugural Donors Register by name substring.' It scopes the result to named organisation donors and an optional inaugural year, which clearly separates it from the aggregate sibling inaugural_donors_summary even without naming that sibling.

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?

The usage context is implied by 'by name substring' and the optional year, and the description explains year omission behavior. However, it never explicitly says when to use this donor-level lookup instead of siblings such as inaugural_donors_summary or super_pac_donors_donor, so the agent must infer the boundary.

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

All MORVS 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?