Skip to main content
Glama

SEC EDGAR Fundamentals

One Insider's Profile and Realized Ledger

insider_profile

Everything the corpus holds about one person, identified by the owner CIK the SEC assigns them: every name spelling they have filed under, every issuer and role they hold or have held as director, officer or ten-percent owner, their position series per security, and a realized-proceeds ledger counting open-market sales only — with every excluded transaction code itemised and the reason it was left out, because counting a tax withholding as a sale is how a total ends up wrong in the flattering direction. Returns one person, not a list of transactions. Reach for it when the subject of the question is an individual: what an executive has realized across every company they file at, when they became an insider, how much of their selling was scheduled in advance under a Rule 10b5-1 plan. Pass name instead of owner_cik to look up candidate CIKs for a spelling — two people share a name more often than anyone expects, so candidates come back for you to choose between and are never merged. Share counts are reported exactly as filed: this service has no market data feed, publishes no estimated position value and states no wealth figure. A Form 4 is filed within two business days of its transaction and a Form 5 annually. See /.well-known/x402 for current pricing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoA filed name, or the beginning of one, to look up candidate owner CIKs. Returns candidates with their most recent filing so one can be chosen; it never picks a person and never merges two CIKs that share a spelling.
owner_cikNoThe insider's Central Index Key, zero-padded or not — '0001214156' and '1214156' are the same person. This is the identity key throughout: the SEC assigns it and it is stable, whereas a name is neither unique nor stable. Every row returned by the other insider tools carries the owner CIK to pass here.
window_daysNoTrailing window in days, ending today, over which the liquidity signals and the windowed proceeds total are computed. Accepts 1 to 3650; defaults to 365. The lifetime ledger is returned regardless of this value.

TDQS

A4.3/5.0
Behavior5/5

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

With no annotations, the description carries full disclosure burden and succeeds: it states the realized ledger counts open-market sales only, itemizes exclusions, says no market data/estimated wealth is provided, reports share counts as filed, and explains that candidate CIKs are never merged.

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?

Long but dense and front-loaded with the core promise. Most sentences add distinct value, though some stylistic elaborations and the pricing link are not strictly necessary for tool invocation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, but the description compensates well by enumerating the return domains and exclusions. It stops short of describing exact response structure/field names, which would be needed for a perfect score.

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?

Input schema coverage is 100%, so baseline is 3. The description reinforces parameter meanings but adds little beyond the already-rich schema descriptions for owner_cik, name, and window_days; schema text for window_days, for example, is actually more specific about liquidity signals and lifetime ledger behavior.

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?

Description opens with a concrete function: returning everything the corpus holds about one person. It enumerates content (name spellings, issuers, roles, position series, realized ledger) and explicitly contrasts 'returns one person, not a list of transactions', distinguishing it from sibling list/activity tools.

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 explicit when-to-use guidance: 'Reach for it when the subject of the question is an individual' and explains the name-vs-cik decision path. It does not name sibling alternatives directly, but the individual-vs-issuer/company framing makes the intended scope clear.

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.

TDQS

A4.3/5.0
Disambiguation5/5

Every tool targets a distinct resource and action: company reference, financial statements, single-metric history, cross-company comparison, filing history, insider transactions, insider aggregation, and vocabulary lookup. Cross-references between insider tools make boundaries explicit and prevent misselection.

Naming Consistency4/5

Names are all snake_case and mostly follow predictable verb_noun conventions like get_*, list_*, and screen_*. A few noun-phrase names (company_profile, insider_profile, issuer_insider_activity) and adjective-noun names (latest_insider_filings) break the strict pattern, but the meaning remains clear.

Tool Count5/5

Twelve tools is well within the ideal range for a focused SEC EDGAR fundamentals server. Each tool covers a meaningful slice of either financial data or insider ownership data, and none feels redundant or unnecessary.

Completeness4/5

The server covers the core read-only workflows well: company identity, normalized financials, metric history, cross-company comparison, filing history, insider transactions, insider profiles, and vocabulary support. Minor gaps exist—no company search by name/CIK and no raw filing text retrieval—but common fundamental and insider questions can be answered without dead ends.

Resources