Skip to main content
Glama
Sign In

TradeStar Insider

by com.tradestarinsider
OverviewDiscussionsAdmin

Recent Form 4/A amendments and what each corrected (SEC Form 4/A)

insider_amendments_recent
Read-onlyIdempotent

Use when the user asks which insider filings were amended, corrected, or restated, or wants recent Form 4/A amendments. Returns 4/A amendments, newest-filed first; ticker, issuer_name, person, start/end, days narrow. Each row carries the amendment_accession, filed_date, issuer/insider, source filing_url, the original_accession it amends (when collected), and changed_fields (before/after). Caveat: when the original is not collected the amendment is still listed with original_in_corpus=false and before/after null (never guessed); linkage is by issuer/owner/period.

Input Schema

NameRequiredDescriptionDefault
endNoOnly amendments filed on/before this ISO date
daysNoOnly amendments filed within the last N days.
as_ofNoPublish-boundary replay: UTC ISO-8601 instant (or a bare YYYY-MM-DD, read as end-of-day UTC). Returns only rows that had crossed the publish boundary at or before it — the exact feed visible at that past moment. Each row carries `first_served_at` (null on rows published before the stamp existed; those are kept, as they were already public).
limitNoMax rows to return (default 25, newest first). Page with offset; the response's total_matched shows the full count. limit<=0 = no cap.
startNoOnly amendments filed on/after this ISO date
offsetNoRows to skip before this page (pagination). Default 0.
personNoFilter by insider name substring (case-insensitive)
tickerNoFilter to one issuer ticker (case-insensitive substring), e.g. GLBZ
issuer_nameNoFilter by issuer/company name substring (case-insensitive)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / as_of
      Added value: +{
+  "description": "Publish-boundary replay: UTC ISO-8601 instant (or a bare YYYY-MM-DD, read as end-of-day UTC). Returns only rows that had crossed the publish boundary at or before it — the exact feed visible at that past moment. Each row carries `first_served_at` (null on rows published before the stamp existed; those are kept, as they were already public).",
+  "type": "string"
+}
  2. Added

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already establish readOnly/idempotent/non-destructive, and the description adds substantive traits beyond them: ordering (newest-filed first), per-row return contents, and a real behavioral caveat that uncollected originals still appear with original_in_corpus=false and null before/after values that are 'never guessed'. That linkage-by-issuer/owner/period detail is exactly the kind of edge-case behavior an agent needs.

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 trigger sentence is front-loaded and the return-shape and caveat follow logically, with no redundant filler. It is dense and slightly cluttered with field lists in prose, which keeps it from a 5.

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?

With no output schema, the description shoulders the burden of describing the return shape (amendment_accession, filed_date, issuer/insider, filing_url, original_accession, changed_fields) and the not-collected edge case. For a nine-parameter read tool, nothing essential to correct invocation is missing.

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 schema already documents all nine parameters with formats and defaults. The description only summarizes that ticker, issuer_name, person, start/end and days 'narrow' the results, adding no syntax or filtering semantics beyond the structured fields; baseline 3 is appropriate.

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 uses a specific verb and resource ('Returns 4/A amendments, newest-filed first') and scopes the task to amended/corrected/restated insider filings, which cleanly separates it from siblings like insider_buys and insider_cluster_buys. An agent can identify the tool without opening the schema.

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 gives an explicit trigger ('Use when the user asks which insider filings were amended, corrected, or restated'), which is strong when-to-use guidance. It does not name an explicit alternative sibling or a when-not condition, so it stops short of a 5.

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

All TradeStar Insider toolsInspect
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.

Resources