Skip to main content
Glama

get_13f_position_changes

Read-only

What one 13F filer bought, sold or held in its latest filed quarter, one row per position — the direct read for "what did this fund buy or exit".

FLOW: list_options("institutional_managers", q="blackrock") gives the CIK.

`position_filter` DEFAULTS TO NEW AND CLOSED to keep the payload down. BlackRock with
all five statuses is 2,680 rows and 1.16 MB, so widen it only when the question needs
the adds, trims or unchanged holdings.

Returns {"cik", "position_filter", "count", "rows"}, largest value first. A row is
{date, symbol, manager_name, status, shares, value, prev_shares, prev_value, share_chg,
share_chg_pct, value_chg, value_chg_pct, accessions, sec_urls}. `accessions` and
`sec_urls` are lists because a position can come from more than one filing; a CLOSED row
cites the last filing that reported the position.

DATA QUALITY: a small share of values are wrong as filed or parsed, and they are not
corrected. An implausible value or jump may be a filer error: check `sec_urls`.

An empty result means no rows, not necessarily no activity: `note` says so. A 422 means
a bad CIK. Requires auth (your MCP client attaches the OAuth bearer automatically).
Rate-limited 100/min; counts toward plan quota.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "cik": "<cik>"
    },
    "name": "get_13f_position_changes"
  }
}

Input Schema

NameRequiredDescriptionDefault
cikYesThe filer's SEC CIK, up to 10 digits. Get it from list_options("institutional_managers", q=...).
position_filterNoStatuses to return (default NEW and CLOSED). Add INCREASED, DECREASED or UNCHANGED for the rest of the book: a large filer's full book is thousands of rows.

Output Schema

NameRequiredDescriptionDefault
cikYes
noteNoSet only when no rows came back: what an empty result can mean.
rowsYesOne row per position in the latest filed quarter, largest value first.
countYesRows returned.
position_filterYesThe statuses requested.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.1/5.0
Behavior3/5

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

Annotations only declare readOnlyHint=true; the description goes well beyond that with auth requirements (OAuth bearer auto-attached), a 100/min rate limit, plan-quota cost, the 422 error meaning a bad CIK, and empty-result semantics ('note' field). It also discloses data-quality caveats about uncorrected filing/parsing errors and the multi-filing nature of accessions/sec_urls. This is rich behavioral context; the remaining gap is that it does not say whether a filer with no 13F filings yields empty rows or an error.

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-loaded with the purpose sentence, then clearly sectioned FLOW and DATA QUALITY blocks, and every statement carries information. It is longer than strictly necessary (the row-shape enumeration partially duplicates the output schema) but nothing is 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?

Given a two-parameter read tool with a full output schema, the description covers purpose, prerequisite lookup, default behavior and cost, response shape, error semantics, data-quality caveats, auth, rate limits and empty results. An agent can call this correctly and interpret edge cases without further information.

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 documents both parameters; the description nonetheless adds meaning with a concrete payload figure (BlackRock with all five statuses is 2,680 rows and 1.16 MB) that justifies the default, and reinforces the CIK lookup path. It also explains the CLOSED row semantics ('cites the last filing that reported the position'), which the schema does not.

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?

States a specific verb+resource: 'what one 13F filer bought, sold or held in its latest filed quarter, one row per position', plus a plain-language use case. It does not explicitly differentiate itself from the sibling tools get_13f_cik_allocation or get_13f_ownership_by_manager_type, so an agent must infer the boundary from names alone.

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

Usage Guidelines5/5

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

Explicitly gives the prerequisite flow (list_options("institutional_managers", q="blackrock") for the CIK) and states the default filter plus the exact condition for widening it ('only when the question needs the adds, trims or unchanged holdings'). It also flags the size cost of widening, which is a concrete when-not-to-act signal.

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