SEC insider filings as clean economic events - Form 4 trades, Form 144 notices, 13D/G stakes.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.7/5 across 4 of 4 tools scored.
Each tool has a clearly distinct purpose: activist stakes (13D/G), sale notices (Form 144), interpreted Form 4 events, and a merged timeline. Though the timeline overlaps with the others, descriptions explicitly direct users to dedicated tools for specific forms, preventing confusion.
Three tools use the verb 'get_' with a descriptive noun (activist_stakes, company_timeline, sale_notices), while one uses 'search_' for a query-oriented endpoint. This is a minor deviation from a consistent verb-first pattern, but the names remain intuitive and readable.
With only four tools, the server is tightly scoped to insider trading data. Each tool covers a distinct filing type or aggregation view, and the count is appropriate for the domain without being thin or bloated.
The surface covers all major SEC insider-trading forms: Form 4 (search_insider_events), Schedule 13D/G (get_activist_stakes), Form 144 (get_sale_notices), and a combined view (get_company_timeline). This is a complete lifecycle for reading insider activity; no obvious gaps exist.
get_activist_stakesAGet Schedule 13D/13G beneficial-ownership filings (activist and 5%+ large-holder stakes) for one company - ticker is required. Returns one row per filing with filer names and the maximum reported percent of class; detailed item narrative text is not included. event_revision is always null for these forms (a fact of the form, not missing data). Data delayed 24 hours (known_at); recent filings only.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of 13D/13G filings to return. Default 20. | |
| ticker | Yes | Stock ticker symbol of the company (issuer), e.g. AAPL or TSLA. Required. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey read-only/idempotent hints, but the description adds valuable behavioral context: return format (one row per filing, filer names, max percent), exclusions (no item narrative text), the meaning of event_revision null, and data delay. This goes well beyond the structured annotations and sets accurate expectations.
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?
The description is concise, front-loaded with the core purpose, and every sentence provides useful detail without repetition. It is well-structured for consumption by an agent.
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?
The tool has a simple parameter set and an output schema, so the description does not need to explain return values. It fully covers critical context: data delay, recency, null handling, and exclusions, making the tool's behavior clear for selection and invocation.
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 coverage is 100% with descriptive parameter definitions for both ticker and limit. The description reinforces that ticker is required and mentions 'recent filings only' as context, but it does not add substantive meaning beyond the schema. A baseline of 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 clearly states the tool's function: 'Get Schedule 13D/13G beneficial-ownership filings (activist and 5%+ large-holder stakes) for one company.' It specifies the resource (company filings), the verb (get), and the scope (one company, ticker required). It also differentiates from sibling tools by focusing on activist/large-holder filings rather than timelines or sale notices.
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 provides clear context for when to use the tool: it requires a ticker, targets recent filings only, and notes a 24-hour data delay. It does not explicitly exclude alternatives or mention when not to use it, but the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_company_timelineAGet one merged, time-ordered feed of SEC insider activity for a company: Form 4 events, Schedule 13D/13G stake filings, and Form 144 sale notices, distinguished by the source_form field (form4 | sc13 | form144). The limit applies after merging, so companies with heavy Form 4 activity can crowd out 13D/G and 144 rows - use the dedicated tools for those. Unknown tickers fail with an error (404). Data delayed 24 hours (known_at); no price-derived fields.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of timeline items after merging all form types. Default 50, maximum 300. | |
| ticker | Yes | Stock ticker symbol of the company (issuer), e.g. AAPL or TSLA. Required. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses key behavioral traits: limit applies after merging, unknown tickers return 404, data is delayed 24 hours via known_at, and no price-derived fields are present. This adds significant context not derivable from annotations alone.
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?
The description is a tight three sentences, each adding essential information: what it does, the limit caveat with alternatives, and error/delay details. It is front-loaded with the primary purpose and contains no filler.
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?
Given the tool's complexity (merging three filing types with a shared limit, error handling, data delay), the description covers all necessary context: result field, row crowding, fallback tools, ticker failure, and timeliness. An output schema exists, so return format details are covered elsewhere.
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 coverage is 100%, so ticker and limit are already documented. The description adds crucial nuance that the limit applies post-merge, affecting how the parameter should be set, and reinforces that ticker is the issuer's symbol. This exceeds the baseline by providing behavioral context for parameter usage.
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 clearly states the tool's function: merging Form 4, Schedule 13D/13G, and Form 144 filings into one time-ordered feed, with explicit mention of the source_form field. It also distinguishes from sibling tools by pointing to dedicated tools for specific filing types, making the purpose unmistakable.
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 provides explicit guidance on when to use this tool versus dedicated alternatives: it warns about Form 4 crowding out rows and advises 'use the dedicated tools for those.' It also includes error behavior (404 for unknown tickers) and data delay, helping the agent decide if this is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_sale_noticesAGet Form 144 notices of proposed insider sales for one company - ticker is required. shares_to_sell and aggregate_market_value are as-filed intentions announced before the sale, not executed trades - the matching Form 4 sale, if any, typically follows about a day later. event_revision is always null for this form. Data delayed 24 hours (known_at); recent filings only.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of Form 144 notices to return. Default 20. | |
| ticker | Yes | Stock ticker symbol of the company (issuer), e.g. AAPL or TSLA. Required. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotentHint annotations, the description adds substantial behavioral context: shares_to_sell and aggregate_market_value are as-filed intentions, not executed trades; matching Form 4 sales typically follow a day later; event_revision is always null; data is delayed 24 hours and only recent filings are returned. This goes well beyond what annotations convey.
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?
The description is concise and front-loaded, starting with a clear purpose sentence. Every subsequent sentence adds meaningful behavioral or temporal context without redundancy, and the overall length is appropriate.
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?
The description covers the tool's purpose, required input, temporal delays, filing semantics, and known quirks (event_revision null). Since an output schema exists, return value details are not needed. This is complete for a read-only, single-company lookup tool.
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?
The input schema already fully documents both parameters (ticker and limit) with descriptions and defaults, so schema coverage is 100%. The description adds no additional meaning specifically about the parameter semantics, though it clarifies the output field semantics (shares_to_sell, aggregate_market_value).
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 clearly states the tool retrieves Form 144 notices of proposed insider sales for a single company, using a specific verb ('Get') and resource ('Form 144 notices'). It also notes ticker is required, which differentiates it from broader sibling tools like search_insider_events.
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 explicitly states it is for one company and that ticker is required, providing clear context for when to use it. It does not explicitly mention alternatives or exclusions, but the 'one company' constraint and focus on Form 144 imply appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_insider_eventsASearch interpreted insider-trading events from SEC Form 4 filings. Each event classifies raw filing rows into economic meaning (OPEN_MARKET_BUY vs EQUITY_AWARD vs TAX_WITHHOLDING_ONLY etc.), separating discretionary trades from compensation noise. Supports filtering by ticker, event type, minimum USD value, and time, with cursor pagination. Form 4 only - for 13D/G stakes or Form 144 sale notices use get_activist_stakes, get_sale_notices, or get_company_timeline. Data delayed 24 hours (known_at); history ~1 month; no price-derived fields.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of events to return. Default 20, maximum 200. | |
| since | No | Only return events recorded at or after this ISO 8601 timestamp (e.g. 2026-08-01T00:00:00Z). Compares against recorded_at — useful for incremental sync. | |
| cursor | No | Opaque pagination cursor — pass the next_cursor value from the previous response. | |
| ticker | No | Stock ticker symbol to filter by, e.g. AAPL or TSLA. Omit to search across all companies. | |
| min_value | No | Minimum trade value in USD (reported shares × reported price per share). | |
| event_type | No | Filter by interpreted event type. One of: OPEN_MARKET_BUY, OPEN_MARKET_SELL, PLANNED_10B5_1_SELL, OPTION_EXERCISE_HOLD, OPTION_EXERCISE_PARTIAL_SELL, OPTION_EXERCISE_FULL_SELL, TAX_WITHHOLDING_ONLY, EQUITY_AWARD, GIFT_TRANSFER, INDIRECT_OWNERSHIP_TRANSFER, OTHER_REQUIRES_REVIEW, JOINT_FILING_AMBIGUOUS, COMPLEX_DERIVATIVE_EVENT, UNCLASSIFIED. Use OPEN_MARKET_BUY for discretionary insider buying. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds crucial context beyond these: 'Data delayed 24 hours (known_at); history ~1 month; no price-derived fields.' It also explains why event classification matters, which gives the agent a deeper understanding of the tool's behavior and limitations.
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?
The description is concise yet rich, with four sentences that each deliver unique value: purpose, classification logic, filtering/pagination, and exclusions/caveats. It is front-loaded with the core function and ends with operational constraints. No sentence is wasted.
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?
Given the tool's complexity (6 optional params, output schema, annotations), the description is complete. It covers data source, interpretation logic, filtering capabilities, pagination, alternative tools, data freshness, retention window, and absence of price-derived fields. The agent has enough context to select and invoke the tool correctly.
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?
The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description mentions filtering by ticker, event type, minimum USD value, and time, but these are already in the schema. It does not add any new semantic meaning beyond the schema, so this meets the baseline but does not exceed it.
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 clearly states 'Search interpreted insider-trading events from SEC Form 4 filings' with a specific verb and resource, and distinguishes itself from siblings by noting 'Form 4 only' and naming alternative tools. It precisely differentiates the tool's scope from get_activist_stakes, get_sale_notices, and get_company_timeline.
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?
Explicit usage guidance is given with 'Form 4 only - for 13D/G stakes or Form 144 sale notices use get_activist_stakes, get_sale_notices, or get_company_timeline.' Also, the description explains the tool's value (separating discretionary trades from compensation noise) and the event_type parameter description advises 'Use OPEN_MARKET_BUY for discretionary insider buying.' This clearly tells when and when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!