Skip to main content
Glama
TradestarV5

Insider Signals MCP Server

by TradestarV5
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Fund position changes (SEC 13F quarter-over-quarter)

fund_position_changes

Track quarter-over-quarter SEC 13F-HR position changes by large institutional filers—opened, added, trimmed, or exited—with filing dates, values, CUSIPs, and source links.

Instructions

What large institutional filers CHANGED quarter-over-quarter in their SEC 13F-HR holdings (opened / added / trimmed / exited a position) — the delta is the product; the raw snapshot is only the input. Every row carries as_of_quarter_end, filed_date and lag_days (values are up to ~45 days stale), value_usd in whole dollars, cusip + issuer_name, and its source filing_url. ticker is null (no authoritative free CUSIP->ticker source; never guessed). A missing prior quarter is the explicit state 'first_filing_on_record', not 'everything new'. Covers LONG US 13(f)-listed positions only — no shorts, non-US, or options. UNIVERSE: the fifty largest 13F filers by reported value as of the latest quarter, re-ranked quarterly. Because it is ranked BY REPORTED VALUE, the head is the biggest asset managers (BlackRock, Vanguard, State Street, Fidelity, ...) whose quarter-over-quarter changes largely reflect index rebalancing, not conviction; the feed reports WHAT WAS FILED, not what it means, and does not tag any manager active or passive (that would be inference). Coverage is PER SEC CIK, not per brand: a firm filing under several CIKs appears as several entries, and when a filer's 13F moves to a new CIK, historical coverage stays attached to the CIK that filed it. This is a convenience/completeness view of public data, NOT a trading edge. Returns the newest 25 by default (set limit; page with offset); total_matched reports the full count. Optional filer, change_type, min_value_usd, and days (last-N-days window).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
daysNoOnly changes filed within the last N days.
filerNoFilter to one fund by name substring (case-insensitive, e.g. 'Berkshire') or exact filer CIK
limitNoMax rows to return (default 25, newest first). Page with offset; the response's total_matched shows the full count. limit<=0 = no cap.
offsetNoRows to skip before this page (pagination). Default 0.
change_typeNoOnly this kind of quarter-over-quarter change
min_value_usdNoOnly positions at or above this current value in WHOLE US dollars

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations, the description carries full burden and excels: it discloses data staleness (~45 days), ticker null policy, 'first_filing_on_record' state, CIK vs brand coverage, re-ranking, active/passive non-tagging, and the nature as a convenience view. This is exemplary transparency beyond what any schema could encode.

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

Conciseness4/5

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

The description is long but every sentence carries substantive information—no filler. It front-loads the core purpose and then layers caveats logically. While a bit dense, the structure is efficient for the tool's complexity, earning a 4 rather than 5.

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 tool with no output schema, the description enumerates all returned fields (as_of_quarter_end, filed_date, lag_days, value_usd, cusip, issuer_name, filing_url, ticker) and covers pagination, defaults, filtering, and edge cases. An agent has everything needed to call it correctly and interpret results.

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% and each parameter already has a descriptive schema entry (e.g., 'filer' substring/CIK, 'change_type' enum, 'min_value_usd' in whole dollars). The description adds marginal semantic value, mostly reinforcing pagination defaults. It meets the baseline 3 without adding new meaning.

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 clear verb+resource: 'What large institutional filers CHANGED quarter-over-quarter in their SEC 13F-HR holdings'. It explicitly contrasts the delta product vs raw snapshot, and distinguishes from siblings like verify_13f_holding by focusing on changes, not static 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?

The description implies usage by clarifying what it covers (LONG US 13(f)-listed positions, top 50 filers) and what it doesn't (shorts, non-US, options). It also warns 'NOT a trading edge' and explains that changes reflect index rebalancing, guiding an agent on interpretation. It does not name specific sibling tools, but the context is sufficient.

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

Deploy Server

Other Tools