Skip to main content
Glama

Find Public Pension Holdings by List

what_your_pension_owns
Read-onlyIdempotent

What public pension funds reported holding in companies on US government lists or in MORVS's registers, from What Your Pension Owns, a MORVS register built from the SEC's quarterly Form 13F data sets (Q3 2025 to Q2 2026 at launch) and five funds' own holdings reports, matched issuer by reviewed issuer to the Pentagon's Section 1260H list, Treasury's NS-CMIC list, DHS's UFLPA Entity List and two MORVS registers (the Detention Ledger's publicly traded operators, and the listed parents of vendors counted in Who Gets Your Data's government lane). Optional filters: fund (a reviewed fund's name, a two-letter state or a 10-digit SEC CIK), issuer (a company name, a ticker the register carries, or a 9-character CUSIP), list (a list ID the register carries, or its title), source (13f or report) and quarter (a quarter-end date the register carries, YYYY-MM-DD). With filters: for each list, the matched holdings by source, date and security kind, Form 13F rows and the funds' own report rows kept apart and debt apart from shares, each group's value split into holdings on the list at the holding date and holdings designated later. When the matches are one fund's: up to 25 of its positions, the two sources kept apart, latest holding date leading (holding date, issuer, shares or debt, the value as filed or printed, each list's names as printed with its designation or register date and the designation-after-holding flag, the register's claim sentence, and the filing or report rows behind it). When they span funds: each fund with its count of positions and the arguments that return its positions (for_positions). With no filters: the register's headlines with their basis, each list's latest-quarter Form 13F figures, and the counter-findings (how many funds' filings hold no reviewed match to each list). The two sources are never added together, and no total adds two lists, two dates, two reports, or shares and debt; a company on two lists appears under each. A holding is a position a fund reported on a stated date: it does not show why the fund held it, whether it followed an index, or what the fund holds today. A designation dated after a holding is flagged on that position (designation_postdates_holding) and its value is kept apart from holdings on the list at the holding date. The MORVS registers are not government designations. No state divestment law is applied. Answers are kept under about 25 KB. The answer carries as_of, retrieved, the file dates, the question, list, index, coverage and law notes, the claim rules, the licence and the source page on morvs.ai; an empty result carries the register's absence note (no reviewed match in that fund's filing or report for that date, which is not a statement about other dates, other accounts or holdings through outside funds). Pension funds are institutions; no person is named.

Input Schema

NameRequiredDescriptionDefault
fundNoOptional reviewed fund name (as printed or as filed), a two-letter state, or a 10-digit SEC CIK, for example CalPERS, NY or 0000810265.
listNoOptional list ID the register carries, or its title, for example dod_1260h or morvs_detention_operators.
issuerNoOptional company name, a ticker the register carries, or a 9-character CUSIP with a valid check digit, for example Alibaba, GEO or 01609W102.
sourceNoOptional source: 13f (the SEC Form 13F filings) or report (the funds' own holdings reports); both, kept apart, when omitted.
quarterNoOptional holding date (YYYY-MM-DD), a quarter-end the register carries, for example 2026-06-30.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already cover readOnly/idempotent/openWorld/destructive=false, and the description adds substantial beyond that: additive prohibitions (never summing sources or lists), the designation_postdates_holding flag, the ~25 KB answer cap, the empty-result absence note, and the 'MORVS registers are not government designations / no state divestment law' caveats. No contradictions with annotations.

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 body is one massive run-on paragraph with heavily nested clauses that is difficult to parse. Much of the content is valuable, but the packing and lack of structure (no segmentation of filters vs returns vs caveats) hurts readability.

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 5-param, no-output-schema tool it is remarkably complete: it explains return shapes with and without filters, per-scope behavior, caveats, sourcing/licence, and edge-case absence notes. There is no output schema, and the description compensates fully.

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 baseline is 3. The description restates each filter (fund, issuer, list, source, quarter) with accepted value forms and adds behavioral nuance—source kept apart when omitted, quarter must be a quarter-end the register carries. This adds some value but largely mirrors the already-rich schema examples.

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?

Opens with a specific verb+resource: 'What public pension funds reported holding in companies on US government lists.' It names the data sources (SEC Form 13F, funds' own reports) and the matching registers, so an agent can tell it apart from the singleton sibling what_your_pension_owns_fund and from fund_holdings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Extensively describes how behavior varies by input: with filters, no filters, one-fund vs multi-fund matches, and it explicitly routes multi-fund results via the for_positions argument. It stops short of naming sibling alternatives (e.g., what_your_pension_owns_fund) or stating when NOT to use it, so not a 5.

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