Flexreport Finance

get_13f_cik_allocation

Read-only

One 13F filer's portfolio weights by sector or industry per quarter, compared with all institutions — the direct read for "how is this fund positioned" and where it tilts.

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

Returns {"cik", "group_by", "limit", "count", "rows"}, newest quarter first. A row is
{date, cik, manager_name, sector OR industry, positions, value, weight_pct,
previous_quarter_weight_pct, weight_chg_pts, all_institution_weight_pct, covered_value,
reported_portfolio_value, coverage_pct}.

READING THE NUMBERS:
- `weight_pct` IS A SHARE OF `covered_value`, NOT OF THE WHOLE PORTFOLIO. It covers long
  stock positions mapped to a symbol; ETFs, unmapped CUSIPs and options are excluded.
  Median coverage for Registered Investment Advisors is 41.5% of the reported portfolio.
  ALWAYS report `coverage_pct` alongside a weight.
- `coverage_pct` and `reported_portfolio_value` are null except for the filer's latest
  profiled quarter. Citadel reads 15.94% because its reported $875B is mostly options.
- `previous_quarter_weight_pct` is 0 if the filer held nothing in that group in a quarter
  it filed, and null if it did not file that quarter.
- `all_institution_weight_pct` is null for a partial quarter. Tilt is `weight_pct` minus
  this value; compute it, since it is not returned.
- A fully exited group has no row, so a quarter's `weight_chg_pts` won't sum to 0.
- Sector and industry labels are current, not historical.

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

A large filer's first call can take several seconds; repeats are far faster. An empty
result means no rows for that CIK (`note` is set only then). A 422 means a bad CIK or
limit. 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_cik_allocation"
  }
}

Input Schema

Name	Required	Description	Default
`cik`	Yes	The filer's SEC CIK, up to 10 digits. Get it from list_options("institutional_managers", q=...).
`limit`	No	The filer's most recent quarters (1-8). Defaults to 8 for sector and 2 for industry (industry at 8 quarters is about 300 KB).
`group_by`	No	Group by sector (default) or industry. Rows label the group under this field name.	sector

Output Schema

Name	Required	Description
`cik`	Yes
`note`	No	Set only when no rows came back: what an empty result can mean.
`rows`	Yes	Newest quarter first, largest value first within it. Each row also carries `sector` or `industry`, per group_by.
`count`	Yes	Rows returned: one per group per quarter.
`limit`	Yes	Quarters requested, after the tool's default.
`group_by`	Yes	"sector" or "industry": the field each row labels its group with.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 7, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations supply only readOnlyHint, but the description goes far beyond: OAuth bearer requirement, 100/min rate limit, plan quota consumption, multi-second first-call latency with faster repeats, 422 and empty-result semantics, a data-quality caveat about uncorrected filing/parse errors, and null-vs-zero rules for previous_quarter_weight_pct and all_institution_weight_pct. This is exactly the behavioral context the thin annotation set does not convey.

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?

It is long, but the structure is deliberate: purpose first, then FLOW, then return shape, then a labeled READING THE NUMBERS section for the traps. Nearly every sentence carries actionable information, though the return-field enumeration is partially redundant with the existing output schema and could be trimmed.

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 read tool with three parameters whose numbers are easy to misread, the description covers the path to the CIK, the response envelope, the coverage caveat, null-vs-zero semantics, the derived tilt calculation, and the fact that an exited group produces no row. Nothing an agent needs to interpret or invoke this correctly appears to be missing.

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 coverage is 100%, so cik, limit and group_by are already fully documented, and the description's CIK guidance largely restates the schema text. It adds only marginal value beyond the schema — the note that industry at 8 quarters is roughly 300 KB, plus the observation that the group label is emitted under the field name from group_by. Baseline 3 is appropriate here.

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 opening sentence names a specific verb and resource (portfolio weights by sector or industry, per quarter, for one 13F filer) and scopes it against an aggregate baseline ('compared with all institutions'), which separates it from sibling tools like get_13f_position_changes and get_13f_ownership_by_manager_type. It even supplies the user-intent phrasing ('how is this fund positioned') that maps a natural question to this tool.

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 FLOW line gives an explicit prerequisite path for obtaining the required CIK via list_options("institutional_managers", q=...). It also states error and empty-result conditions (422 = bad CIK or limit; empty = no rows). What is missing is explicit routing away from the sibling 13F tools — nothing says when to prefer position-changes or ownership-by-manager-type over this one.

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

All Flexreport Finance tools Inspect

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

Need Help?