TickerDB

get_insiders

Read-only

Find insiders (people and organisations whose trades are disclosed in SEC Form 4: CEOs, officers, directors, 10%+ owners including funds) by name, ticker or type, or list them most active first. Step 1 of a copy/inverse insider model ('make a model that copies Bezos'): search the name, pick the right result from its companies, roles and activity, then call get_insider_trades with its slug. Search is loose: any order and case, word starts, initials, nicknames both ways (bill = william), typos, run-together or split names (jeffbezos, value act), legal suffixes ignored, and extra words tolerated (half the words must match; full matches rank first, matched_words says how many matched). Several people can share a name: check companies and roles. Curated aliases cover famous names filed differently (Jensen Huang files as 'Huang Jen Hsun'). Each result has lag_days_median/_p90 (days from trade to public disclosure) and late_filing_share.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_insiders"
  }
}

Input Schema

Name	Required	Description
`q`	No	Name to search, e.g. "jeff bezos" or "pershing square". Omit to list.
`role`	No	Role ever held at any company.
`type`	No	person or organization (funds, trusts, companies).
`limit`	No	Results per page, default 20, max 100.
`offset`	No	Paging offset, default 0.
`ticker`	No	Only insiders who filed at this company, e.g. "AMZN".
`active_since`	No	YYYY-MM-DD: last disclosure on or after this date.

Output Schema

Name	Required	Description	Default
`data`	No	The TickerDB API response payload for this tool call.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedNov 1, 2026

removedInput schema / properties / category

Removed value: -{
-  "description": "Role ever held at any company.",
-  "enum": [
-    "ceo",
-    "cfo",
-    "coo",
-    "president",
-    "chair",
-    "officer",
-    "director",
-    "ten_percent_owner"
-  ],
-  "type": "string"
-}

removedInput schema / properties / kind

Removed value: -{
-  "description": "person or entity (funds, trusts, companies).",
-  "enum": [
-    "person",
-    "entity"
-  ],
-  "type": "string"
-}

addedInput schema / properties / role

Added value: +{
+  "description": "Role ever held at any company.",
+  "enum": [
+    "ceo",
+    "cfo",
+    "coo",
+    "president",
+    "chair",
+    "officer",
+    "director",
+    "ten_percent_owner"
+  ],
+  "type": "string"
+}

addedInput schema / properties / type

Added value: +{
+  "description": "person or organization (funds, trusts, companies).",
+  "enum": [
+    "person",
+    "organization"
+  ],
+  "type": "string"
+}

AddedNov 1, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already establish read-only, non-destructive, open-world behavior. Beyond that, the description discloses how matching works (any order/case, initials, nicknames, typos, split/run-together names, legal suffixes ignored, partial-match rules and ranking), that aliases cover famous names filed differently, and that results include lag_days_median/_p90 and late_filing_share. These are substantive behavioral traits not available in the annotations.

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 front-loaded with purpose and workflow, and every section carries useful information. It is dense and somewhat run-on in the search-behavior parenthetical, but not padded with generic filler.

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 seven optional parameters, full schema coverage, annotations, and an output schema, the description covers the critical missing context: workflow placement, ambiguous-name resolution, loose search behavior, aliases, and result metrics. Nothing essential for correct invocation appears missing.

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 meaning about the q parameter's matching semantics, including partial matching, aliases, ranking, and matched_words. It does not add much for limit/offset/active_since beyond the schema, but the search semantics are valuable.

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?

States a specific verb and resource: find/list insiders from SEC Form 4, including the populations covered (CEOs, officers, directors, 10%+ owners, funds). It also distinguishes itself from siblings by naming get_insider_trades as the next step, so an agent knows this tool returns the insider identity rather than the trades.

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 describes the workflow: search by name, ticker, or type, pick the right result using companies/roles/activity, then call get_insider_trades with the slug. It also tells the agent what to do when several people share a name and how to interpret loose search ranking, leaving little inference required.

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

All TickerDB 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.