Skip to main content
Glama
theodor90

form4api-mcp

by theodor90
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

get_insider_directory

Read-only

Find SEC Form 4 insiders alphabetically by surname, get per-letter counts and paginated insider lists. Filter by one letter or retrieve the full A-Z rail with totals.

Instructions

Browse insiders alphabetically by surname. Returns the A-Z rail with a count per letter, plus one page of insiders under the requested letter. Omit letter to get the rail and totals with no rows.

Names come from EDGAR surname-first ("HENNEMAN JOHN B III"), so alphabetical order is order by surname. Casing in the source is inconsistent and is not normalised here.

This lists only insiders with at least 3 non-superseded transactions, capped at the 5,000 most active — the same set as the insiders sitemap shard, so the two cannot drift. To find someone outside that set, use GET /v1/insiders?name= which searches every filer. Rebuilt daily; refreshedAt reports when. Not plan-gated.

One row per FILER GROUP. A fund group files a single Form 4 listing several reporting owners — the fund, its GP, its management company — and each is a real EDGAR filer with its own CIK. Listing all of them spent about 11% of this capped surface describing the same actors more than once, so browse shows one per group and filerGroupSize says how many others share those exact transactions. The others are not hidden: each keeps its own profile and is still returned by GET /v1/insiders?name=.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNo1-based page number within the letter. Defaults to 1.
letterNoSingle letter A-Z to list, or "#" for names that do not begin with a letter. Omit to get the A-Z rail and totals without any rows.
per_pageNoRows per page. Defaults to 200, maximum 500.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.9.6

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnly/openWorld annotations, the description discloses important behavior: only insiders with 3+ non-superseded transactions, the 5,000 most active cap, daily rebuilds, non-normalized casing, and de-duplication of filer groups into one row per group. It also confirms this is not plan-gated, which is useful invocation context.

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 longer than average, but every paragraph adds substantive context: coverage rules, source collision behavior, grouping rationale, and search alternative. It is front-loaded with the core behavior and mostly well organized.

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?

Given the absence of an output schema, the description does enough by stating the returned scaffold: A-Z rail, counts, one page of insiders, and filerGroupSize. Minor gaps remain around full row field names and pagination metadata, but nothing that blocks correct invocation.

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 baseline is 3, but the description adds real value by explaining letter omission semantics, the '#' use case, sorting by surname due to EDGAR formatting, and how one page maps to a letter. This goes beyond simply restating the schema.

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 states a precise verb and resource: browse insiders alphabetically by surname, returning a per-letter rail and one page of rows. It clearly differentiates this from search-by-name tools, telling the agent this is not a full-text search over every filer.

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?

It gives an explicit alternative: use GET /v1/insiders?name= to search every filer when a target is outside the capped directory set. It also explains the inclusion rule and caps, making the configured scope unambiguous.

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