Skip to main content
Glama

Trader & Insider Signals

signal
Read-onlyIdempotent

PURPOSE: Look up who is trading what — actual positioning and trade calls, with the original content so you can read the reasoning, size, and timing.

COVERS (by intent):

  • [signal-kol-call] KOL trading calls (Twitter/TG personalities posting calls) — covers BOTH crypto KOLs AND tradfi (stock/ETF) finance influencers; omit asset_type for both, or set asset_type="crypto"|"tradfi" to scope one class; query="consensus" → aggregated bullish/bearish view across KOLs (best with a specific ticker/entity). Watch / subscribe / alert / remind / notify / monitor intents about KOL-call symbols fit subscription; it tracks watched symbols with zero quota cost.

  • [signal-trader-position] latest directional trader-position legs by symbol/asset, including simultaneous long+short hedge legs, bot-reported notional size, active status, compact trader profile context, and empty-keyword trending symbol groups; covers crypto and tradfi position rows, while asset_type narrows one family

  • [signal-insider-trading] corporate insider (SEC Form 4) + political / congressional trades (tradfi)

  • [signal-institutional] A ticker's bounded 13F holder page, a manager's latest reported portfolio, and changes versus its previous available report (tradfi). Manager results disclose the selected filing and bounded evidence when more than one filing version was observed for a report period.

BOUNDARIES:

  • signal = crypto-social calls + tradfi insider/13F filings. Sell-side Wall Street ANALYST ratings / price targets / rating upgrades-downgrades / "评级" / "华尔街怎么看…评级" fit metrics(fundamentals). "KOL / 喊单" maps to finance influencer calls; "分析师 / analyst" maps to sell-side analyst data. Institutional means 13F holdings.

  • News articles & commentary → news.

  • Watch / subscribe / alert / remind / notify / monitor intents about KOL-call symbols → subscription, a free watchlist inbox that lists watched symbols and unread counts. Immediate call content and original posts → signal.

  • trader_position and kol_call cover BOTH crypto and tradfi (asset_type="crypto"|"tradfi" narrows; omit → both classes). insider_trading & institutional are tradfi-only.

USAGE: Argument contract: keywords is the ENTITY FIELD; query is the INTENT FIELD. Whenever the user names tickers, symbols, KOLs, people, or managers, put each entity in a separate keywords item and put the requested signal view in query. Example: "ETH KOL consensus" → keywords=["ETH"], query="consensus", categories=["kol_call"]. Standalone query serves entity-free discovery; trader_position with empty keywords returns trending symbol groups. Corporate insider trades default to revision_view="effective": only evidence-verified superseded rows are hidden; unresolved amendments remain visible with revision_complete=false and must not be summed as a complete total. Use revision_view="history" to preserve all versions; explicit filing lookup defaults to history. meta.revision.insider_trading reports stored revision coverage independently of pagination or original SEC completeness. For complete stored insider history, put security/person entities in keywords and set paginate=true with categories=["insider_trading"] and sort_by="time" (or omit sort_by); follow meta.pagination.insider_trading.next_cursor with the same request and limit. Add filing= and one security keyword to read one corporate filing across pages. coverage=stored_rows describes database coverage, not a guarantee that FMP supplied every original filing line. Ordinary latest-window requests remain bounded. For insider_trading, a person keyword selects that person’s Congress disclosures; a security keyword selects corporate and Congress trades for that security. Mixed person/security keywords combine those scoped results as a union. Pick categories to scope (omit for all). Up to 5 keywords run in parallel, and omissions are reported in meta.warnings. For institutional, put security tickers and/or manager CIKs or exact legal/common names in keywords. Security and manager matches are additive and may coexist. Explicit keywords are authoritative for Institutional entity execution; with empty keywords, query-derived entities provide compatibility discovery. Each resolved manager returns both manager_portfolio and manager_changes, with query supplying context while the view set stays fixed. English / canonical names match best.

RETURNS: signals with original content, bucketed {kol_call, trader_position, insider_trading, institutional} — only fired buckets present. trader_position returns {top_trader}; groups are by symbol/asset/instrument so multi-keyword requests keep BTC, ETH, MSTR, etc. separate. Each active direction is a separate position leg, so one trader may have both long and short rows for the same symbol. For trader_position, each symbol group returns up to limit position rows, across up to 5 symbol groups from keywords or empty-keyword trending; symbol_rollup metadata is returned per group outside that row budget. top_trader groups contain symbol_rollup + positions; symbol_rollup exposes long/short leg counts, positions_without_notional, gross_notional_value_usd, net_notional_value_usd, long_notional_ratio, short_notional_ratio, net_direction, agreement, actions, and classification. Exposure sums only reported notional_value_usd values: a position with null notional remains in leg counts but is excluded from dollar exposure and increments positions_without_notional; entry_price is never used as notional. Exposure and action totals count position legs; agreement counts distinct canonical traders, with a trader holding both long and short counted once and abstaining from the directional vote. notional_value_usd/value_usd remains bot-reported notional, not an inferred margin value. trader_position profile.status remains available when collected profile fields exist and unavailable otherwise. profile.history_access_status reports whether the trader's TG history is currently accessible or hidden, but hidden access never suppresses already collected profile fields or profile-quality ranking. Every available profile includes history_data_note="Based on collected records; data may be incomplete." because reopening history does not guarantee gap backfill. Institutional returns security_holders for security keywords and both manager_portfolio and manager_changes for each resolved manager; both capability legs may coexist in one response. Ambiguous live manager discovery returns manager_candidates instead of guessing. Every nested list is capped by limit. Manager rows return only the selected filing's bounded positions or cross-period changes, plus every observed filing summary, selected_filing_id, semantic_status, and at most min(limit,10) same-period filing differences when complete version positions are available. The Host does not receive raw multi-megabyte extracts; the filing-aware DB snapshot retains complete normalized positions for all current-response filings while public output remains bounded to one selected portfolio. For trader_position, omitted sort_by ranks positions by profile quality (tier, then profile_confidence) with amount/time tie-breakers; pass sort_by="time" for newest-first or "amount" for largest-position-first. Notices in meta.warnings[] (reason=not_applicable / no_match).

EXAMPLES (user → args; cross-lingual):

  • "KOL 在喊什么单" → categories=["kol_call"]

  • "现在 KOL 都在喊什么币" → categories=["kol_call"]

  • "近 24h KOL 对 ETH 共识" → categories=["kol_call"], keywords=["ETH"], query="consensus", time_range="1d"

  • "订阅/监控/提醒 BTC 的 KOL 喊单" → use tool subscription(action="set", items=[{"symbol":"BTC","asset_type":"crypto"}]) — zero quota cost

  • "美股 KOL 在喊什么 / who's calling stocks on Twitter" → categories=["kol_call"], asset_type="tradfi"

  • "谁在推特喊 NVDA" → categories=["kol_call"], keywords=["NVDA"], asset_type="tradfi"

  • "BTC 最新交易员仓位 / BTC latest trader positions" → categories=["trader_position"], keywords=["BTC"]

  • "MSTR 最新持仓动向" → categories=["trader_position"], keywords=["MSTR"], asset_type="tradfi"

  • "现在交易员都集中在哪些标的" → categories=["trader_position"], keywords=[]

  • "비트코인 롱숏 포지션" → categories=["trader_position"], keywords=["BTC"]

  • "AAPL 内部人最近交易" → categories=["insider_trading"], keywords=["AAPL"]

  • "佩洛西最近交易" → categories=["insider_trading"], keywords=["Pelosi"]

  • "金额最大的几笔国会交易" → categories=["insider_trading"], sort_by="amount"

  • "TSLA 13F 机构持仓变化" → categories=["institutional"], keywords=["TSLA"]

  • "AAPL 的机构持有人" → categories=["institutional"], keywords=["AAPL"]

  • "Berkshire Hathaway 最新 13F 组合和持仓变化" → categories=["institutional"], keywords=["BERKSHIRE HATHAWAY INC"]

  • "同时看 AAPL 持有人和 BlackRock 组合" → categories=["institutional"], keywords=["AAPL","BlackRock"]

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoDefault 10\, max 50. KOL raw posts: per asset family; consensus top_calls: min(N,5), aggregate counts unchanged. Trader positions: per symbol or complete trending group. Insider trades: merged category list. Institutional: each subject's holdings/positions/changes lists. Not a total-response limit.
queryNoINTENT FIELD — State the requested signal view or routing intent applied to keywords. Pair with keywords whenever the request names tickers, actors, or managers. Canonical kol_call intents: 'consensus' for an aggregated bullish/bearish view and 'detail' for fuller raw posts. Standalone query supports entity-free discovery such as trending trader-position groups. Explicit keywords are authoritative for Institutional entity execution; with empty keywords, query-derived entities provide compatibility discovery. Each resolved Institutional manager returns both manager_portfolio and manager_changes, with query supplying the surrounding intent while the view set stays fixed. Manager responses disclose summaries for observed filing versions. English usually gives the best recall. Use categories\, asset_type\, time_range\, sort_by\, and limit for their respective controls. Up to 500 runes; truncation is reported in meta.warnings.
cursorNoOpaque next_cursor from meta.pagination.insider_trading. Repeat the original insider_trading filters and limit. Pagination uses a stored-row high-water mark, excludes later inserts, and never falls back to an unrelated latest feed.
filingNoSEC accession number (18 digits or dashed form) for one corporate filing. Requires categories=[insider_trading], exactly one security keyword, and sort_by omitted or time. Implies paginate=true. Read every page to obtain all stored rows for this filing; separate accessions remain separate.
sort_byNoSort order: time (newest first) | amount (largest trades/positions first — meaningful for trader_position latest positions, insider_trading, and institutional). For trader_position, omit sort_by to use profile-quality order (tier then profile_confidence, with amount/time tie-breakers); pass time explicitly for newest-first. kol_call uses time order.
keywordsNoENTITY FIELD — Put every named ticker, symbol, KOL handle, person, CIK, or institutional manager here as a separate array item. Required whenever the request names a specific entity. Known complete token addresses are also aliases (e.g. the UNI contract address resolves to UNI). Per category: kol_call uses a ticker or KOL handle (without @); trader_position uses ticker/symbol lenses such as BTC\, ETH\, MSTR\, QQQ; insider_trading uses a ticker or person name such as AAPL or Pelosi; institutional uses a security ticker and/or a manager's 1-10 digit CIK or exact legal/common name. Institutional security and manager matches are additive and may coexist. At most 5 keywords are processed; omissions are reported in meta.warnings. Each keyword supports up to 128 runes; truncation is reported in meta.warnings.
paginateNoRead stored insider_trading history in pages rather than a bounded latest/live window. Requires categories=[insider_trading], a security or person keyword, and sort_by omitted or time. Follow meta.pagination.insider_trading.next_cursor with the same filters and limit. Covers stored rows only; does not certify the original filing is complete.
verbosityNoFree-text fields (including nested prose) use original prefixes: concise 200 Unicode runes | standard 600 (default for empty or unknown) | detail 2000. Numeric facts, dates, IDs, URLs, tags and technical data are not shortened. Detail still applies this cap; record counts use topic-specific limit.
asset_typeNocrypto | tradfi — restrict to one asset class. kol_call and trader_position cover both crypto and tradfi; insider_trading and institutional are tradfi-only.
categoriesNoWhich kind of signal: kol_call (what KOLs are calling)\, trader_position (latest trader positions by symbol/asset)\, insider_trading (corporate insider / political filings)\, institutional (13F institutional holdings). Omit to auto-detect from the query. Watch / subscribe / alert / remind / notify / monitor intents about KOL-call symbols fit the subscription tool; it stores a zero-quota watchlist inbox.
time_rangeNoExplicit caller-requested recency window\, written as <number><unit> where unit is h|d|w|m|y — e.g. 1h\, 4h\, 1d\, 1w\, 1m\, 6m\, 1y. Supply this field when a time constraint is required; the server does not infer a window from query text. Sources without truthful rolling-window semantics fail closed.
revision_viewNoinsider_trading: effective (default) hides only verified superseded transactions and retains unresolved filings with warnings; history preserves all versions. Explicit filing lookup defaults to history. Revision status is evidence-backed; revision_complete=false forbids treating candidate sums as a complete total.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare read-only/idempotent/open-world, but the description discloses far more: bounded latest windows, pagination high-water-mark semantics, meta.warnings reporting for omissions/truncation, revision_complete=false forbidding sum-as-total, null notional excluded from exposure while remaining in leg counts, and coverage=stored_rows not guaranteeing original FMP completeness. These are non-obvious behavioral traits 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.

Conciseness3/5

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

It is well front-loaded and headed, but very large, and the USAGE/RETURNS prose substantially duplicates facts already stated in the schema descriptions (revision_view semantics, paginate requirements, filing accession rules, limit behavior). Every sentence does not earn its place when the same content is in the structured fields.

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 12 parameters and no output schema, the description compensates fully: it documents the bucketed return shape, which buckets appear when fired, symbol_rollup fields (gross/net notional, agreement, classification), manager filing-version disclosure, and warning surfaces. An agent has everything needed to call and interpret the result.

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 description coverage is 100%, so the baseline is 3, but the description adds a genuine semantic layer beyond the schema: keywords is the ENTITY FIELD and query is the INTENT FIELD, with a worked example ('ETH KOL consensus' → keywords=['ETH'], query='consensus'). It also clarifies that keyword scope changes meaning per category (person keyword → Congress disclosures) and that Institutional matches are additive.

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?

Opens with a specific verb+resource: 'Look up who is trading what — actual positioning and trade calls.' It enumerates the four concrete buckets (kol_call, trader_position, insider_trading, institutional) and explicitly distinguishes itself from siblings by naming metrics for sell-side analyst ratings and news for commentary. An agent can route to this tool without opening any schema.

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?

The BOUNDARIES section gives explicit when-to-use/when-not rules (analyst ratings → metrics, articles → news, watch/subscribe intents → subscription) plus the crypto-vs-tradfi scoping rule. The USAGE contract and 18 cross-lingual examples map user phrasings to concrete argument sets, leaving little to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources