get_insider_filingFetch one Form 4 insider-transaction filing by SEC accession number (e.g. 0001653558-26-000110), with all transaction legs, holdings, and footnotes.
| Name | Required | Description | Default |
|---|---|---|---|
| accession | Yes | SEC accession number, e.g. 0001653558-26-000110. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context by specifying that the response includes all transaction legs, holdings, and footnotes — information not present in annotations or schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One efficient sentence that front-loads the verb and resource, includes the key identifier format, and lists the return contents. No filler or redundant clauses.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter fetch tool, the combination of schema (parameter format and requirement), annotations (read-only, non-destructive), and description (return contents) covers everything an agent needs to select and invoke the tool correctly. No output schema is present, but the description sufficiently conveys the response contents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the single parameter 'accession' is fully documented with type and example in the schema. The description repeats the accession example but adds no new semantic meaning, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and resource ('one Form 4 insider-transaction filing'), identified by SEC accession number. The singular focus and mention of transaction legs, holdings, and footnotes clearly distinguish it from the sibling get_insider_trades, which presumably handles trade lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is for retrieving a single filing when an accession number is known, and the detail offered ('all transaction legs, holdings, and footnotes') signals it is the richer, single-record counterpart to get_insider_trades. However, it does not explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct resource and action: corporate events, insider filings, IPO registrations, dataset status, and schema. The pairings of list/fetch for insider filings and registrations follow a clear pattern, so there is no meaningful overlap.
All seven tools use a consistent get_* prefix with a clear object or dataset name. The naming is uniform and predictable, making the tool surface easy to navigate.
Seven tools is well-scoped for a read-only SEC filing query service. Each tool earns its place, covering list, fetch, status, and schema needs without redundancy or bloat.
The Form 4 and registration domains have both list and single-record fetch capabilities, and dataset status/schema cover operational needs. A minor gap is that 8-K corporate events have no single-event fetch by accession, and IPO registration listing lacks explicit filter options beyond the envelope.