Skip to main content
Glama

insidergraph

by com.insidergraph

Announced vs executed sales

planned_vs_executed
Read-onlyIdempotent

Cross-feed signal: pair each Form 144 notice (an insider's ANNOUNCED sale) with the seller's actual Form 4 sale executions - same person, exact CIK identity, matched inside the notice's factual Rule 144 validity window (90 days from filing). Surfaces execution ratios and, most notably, announced-but-never-executed sales: insiders whose notice expired with no sale. Raw EDGAR cannot answer this in one query.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax rows per page, default 50, cap 500.
sinceNoEarliest approximate sale date, YYYY-MM-DD. Default: 90 days back.
untilNoLatest approximate sale date, YYYY-MM-DD.
cursorNoOpaque pagination token from the previous response's page.next_cursor; pass it back verbatim to fetch the next page.
sellerNoSubstring match on the seller's name.
statusNoFilter: executed, pending (window still open), not_executed (window elapsed, no matching sale - the leading-indicator residue), unverifiable (the seller entity never files Form 4 - trusts and foundations report via the beneficiary), or all (default).all
tickersNoTicker symbols to include. Empty = all issuers.
min_planned_usdNoMinimum planned sale value in USD.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed2 schema fields changed
    • changedInput schema / properties / since / description
      Previous value: -"Earliest approximate sale date, YYYY-MM-DD. Default: 90 days back - pass an explicit date to reach deeper history."New value: +"Earliest approximate sale date, YYYY-MM-DD. Default: 90 days back."
    • addedInput schema / properties / status / default
      Added value: +"all"
  2. Changed3 schema fields changed
    • addedInput schema / $schema
      Added value: +"https://json-schema.org/draft/2020-12/schema"
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / limit / default
      Added value: +50
  3. Changed2 schema fields changed
    • changedInput schema / properties / status / description
      Previous value: -"Filter: executed, pending (window still open), not_executed (window elapsed, no matching sale - the leading-indicator residue), or all (default)."New value: +"Filter: executed, pending (window still open), not_executed (window elapsed, no matching sale - the leading-indicator residue), unverifiable (the seller entity never files Form 4 - trusts and foundations report via the beneficiary), or all (default)."
    • changedInput schema / properties / status / enum
      Previous value: -[
-  "executed",
-  "pending",
-  "not_executed",
-  "all"
-]New value: +[
+  "executed",
+  "pending",
+  "not_executed",
+  "unverifiable",
+  "all"
+]
  4. Changed1 schema field changed
    • removedInput schema / properties / window_days
      Removed value: -{
-  "description": "Days after the approximate sale date to look for executions (default 10; matching also allows 3 days before the stated date).",
-  "type": "integer"
-}
  5. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already provide readOnlyHint and idempotentHint, so safety is covered. The description adds meaningful behavioral context: exact-CIK identity matching, the 90-day Rule 144 validity window, and the treatment of unverifiable sellers via trusts/foundations. It does not describe output shape, but the matching semantics are transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three dense sentences lead with the core cross-feed signal, then explain the matching logic, and end with a differentiating, value-adding remark. No filler; every sentence earns its place.

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 8 fully documented parameters and read-only/idempotent annotations, the description covers the key operational logic and the main analytical use case. It does not specify exact response fields, but no output schema exists and the description still conveys what results will surface (execution ratios and non-executed notices), which is sufficient for selection and invocation.

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?

Schema description coverage is 100%, so the baseline is 3 and the description does not need to compensate. It reinforces the status concept by explaining the not_executed signal, but it does not add parameter-level syntax, formatting, or constraints beyond what the schema already provides.

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 names a concrete analytic operation: pairing Form 144 notices with Form 4 executions by exact CIK identity inside the 90-day Rule 144 window. It also highlights the distinctive 'announced-but-never-executed' signal, making it easy to differentiate from siblings like get_planned_sales or get_insider_trades.

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?

It clearly implies when to use the tool: when the agent needs execution ratios or expired-notice/no-sale residue, and it notes that raw EDGAR cannot answer this in a single query. It does not explicitly name alternatives or state when not to use it, but the context is clear enough for routing.

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

All insidergraph toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0
Disambiguation5/5

Each tool has a clearly distinct job: per-feed searches, cross-feed signals, entity resolution, coverage orientation, profile aggregation, and a recent-filings firehose. Even overlapping areas like Form 144 are cleanly separated between raw search (get_planned_sales) and matched analytics (planned_vs_executed). An agent should rarely pick the wrong tool.

Naming Consistency3/5

Most tools follow a readable verb_noun pattern such as get_insider_trades, find_company, and list_recent_filings. However, company_profile is a noun-only name, and planned_vs_executed plus trades_before_events are descriptive labels rather than commands, making the overall convention mixed though still understandable.

Tool Count5/5

11 tools is well-scoped for an SEC insider-data server: four feed-specific searches, three cross-feed signals, a company resolver, a profile aggregator, a coverage guide, and a firehose. Each tool earns its place and none feels redundant.

Completeness5/5

The set covers all core SEC feeds (Forms 3/4/5, 8-K, 144, 13D/13G) plus identifier resolution, recent filings, an aggregated company profile, and sophisticated cross-feed analytics. For a read-only data service, there are no obvious dead ends or missing operations that would strand an agent.

Resources