Skip to main content
Glama

Insider Buy Signals

by com.tradestarinsider
OverviewDiscussionsAdmin

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

fund_position_changes
Read-onlyIdempotent

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. Changed3 schema fields changed
    • addedInput schema / properties / days
      Added value: +{
+  "description": "Only changes filed within the last N days.",
+  "type": "integer"
+}
    • changedInput schema / properties / limit / description
      Previous value: -"Max changes to return (default 50)"New value: +"Max rows to return (default 25, newest first). Page with offset; the response's total_matched shows the full count. limit<=0 = no cap."
    • addedInput schema / properties / offset
      Added value: +{
+  "description": "Rows to skip before this page (pagination). Default 0.",
+  "type": "integer"
+}
  2. Added

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, yet the description adds substantial new context: data is up to ~45 days stale (lag_days), ticker is always null, missing prior quarter is the explicit 'first_filing_on_record' state, coverage is per CIK not per brand, and the universe is re-ranked quarterly. These are non-obvious behavioral traits an agent cannot derive from structured fields.

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?

Front-loads the core concept in the first sentence, and most sentences (staleness, null ticker, CIK coverage, universe caveat) earn their place. It is dense and long, but the caveats are genuinely load-bearing for correct interpretation rather than padding.

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?

Despite no output schema, the description enumerates the returned fields (as_of_quarter_end, filed_date, lag_days, value_usd, cusip, issuer_name, filing_url) and the pagination/limit model. An agent has everything needed to call and interpret it correctly.

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 the schema already documents every parameter. The description restates defaults (25 rows, offset paging, days window) but adds little syntax or semantics beyond total_matched, so the baseline 3 applies.

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?

States a specific verb+resource ('what large institutional filers CHANGED quarter-over-quarter in their SEC 13F-HR holdings') and immediately frames the delta as the product with the raw snapshot as input. This distinguishes it from siblings like verify_13f_holding without the agent opening any schema.

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?

Gives clear context for when this is appropriate: it covers only long US 13(f)-listed positions (no shorts/non-US/options), it reports filings not interpretation, and it is 'NOT a trading edge'. It stops short of explicitly naming an alternative sibling or stating when-not-to-use in favor of another tool.

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

All Insider Buy Signals toolsInspect
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