Skip to main content
Glama

Get a Pension Fund's Reviewed Holdings

what_your_pension_owns_fund
Read-onlyIdempotent

One reviewed public pension fund in 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), found by fund (its name as the register prints it or as filed, a two-letter state, or a 10-digit SEC CIK; when several match, each in short form with the arguments that return its full profile). Returns the fund's profile (state, type and its label, the basis for counting it as a public pension fund, CIK, legal name as filed and SEC filer link, and its own holdings report where the register reads one, with its as-of date, unit and scope), its Form 13F filing for each quarter (accession, amendments, table entries and value as filed), its figures by list, source and date and up to 25 matched positions (shares and debt apart, with each list's date and the designation-after-holding flag), the register's quarter-to-quarter changes for the fund (positions added and exited per list between quarters it filed, with the values on each date side by side, never subtracted), and, for each list where it holds no reviewed match, the counter-finding with the quarters and report read. 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
fundYesRequired reviewed fund name (as printed or as filed), a two-letter state, or a 10-digit SEC CIK, for example CalSTRS, TX or 0000810265.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.7/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description goes far beyond them: aggregation rules (sources and lists never summed, shares and debt kept apart), the ~25 KB answer cap, designation_postdates_holding flagging, empty-result absence semantics, the no-divestment-law and non-government-register caveats, and the coverage/law notes carried in the response. That is exactly the behavioral context an agent cannot get from 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?

Roughly 450 words delivered as two enormous sentences, with the core purpose and the return shape entangled with caveats, licence text and register provenance. Information is dense and mostly relevant, but it is badly front-loaded and hard to parse, which undercuts the structure requirement.

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?

With one parameter, no output schema and no nested objects, the description carries the full burden of explaining the response, and it does: profile fields, per-quarter filings, figures by list/source/date, capped positions, quarter deltas, counter-findings and the metadata envelope. Nothing an agent needs in order to interpret a result 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?

Schema coverage is 100% and the schema already gives the three accepted forms with examples, so the baseline is 3. The description earns an extra point by describing the ambiguity-resolution behavior -- multiple matches returned in short form with the arguments needed to fetch each full profile -- which is not in the schema.

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 tool returns one reviewed public pension fund with its profile, quarterly 13F filings, matched positions by list, quarter-to-quarter changes and counter-findings -- a specific verb+resource. It is clearly distinct from a list-style tool, but the sibling what_your_pension_owns and fund_holdings are never named, so the agent must infer the split rather than being routed. The purpose only emerges after a very long opening run-on, which weakens first-glance clarity.

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

Usage Guidelines2/5

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

There is no explicit statement of when to use this rather than what_your_pension_owns or fund_holdings, and no exclusions or prerequisites. The only usage-adjacent content is how to address a fund (name, state, CIK) and what happens when several match, which is lookup mechanics rather than tool selection guidance.

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