Skip to main content
Glama
Sign In

Clarifo

by com.clarifo
OverviewDiscussionsAdmin

insider_activity

Read-onlyIdempotent

SEC Form 4 insider trading for a US company. Three modes:

  • "summary" (default): counts and net USD by reporter class (c_level = officers and directors, vs 10% owners) and transaction type; pass granularity for a per-period trend. "Is the CEO buying?"

  • "clusters": cluster trades, several distinct officers or directors trading the same direction within a rolling window (after Cohen, Malloy and Pomorski), ranked by conviction_score (insiders, size, recency). Descriptive, not a recommendation.

  • "transactions": raw Form 4 rows, newest first.

Args: company: Name, ticker or CIK. since_date / until_date: YYYY-MM-DD (default last 365 days; until_date unused in clusters). include_derivatives: Include option grants / exercises (default False; summary and transactions). granularity / periods: Summary trend, "quarter" or "month"; periods caps buckets (max 60). direction: Clusters: "purchase" (default) or "sale". window_days / min_insiders / min_total_value / top_k / include_raw: Clusters: window 1-365 (default 90), insiders >= 2 (default 2), USD floor, clusters kept (default 5; 0 = all), pre-dedup windows. transaction_types / reporter_class / reporter_cik / limit: Transactions: subset of purchase, sale, award, exercise, other; "officer", "director", "ten_pct_owner" or "c_level"; one insider; row cap (default 50, max 1000).

Returns: Summary: summary {transaction_count, net_value_usd, by_type, by_reporter_class} and sources[] (at most the 1,000 newest transactions), or trend[]. Clusters: clusters[], each with a source_ref into sources[]. Transactions: transactions[] with an EDGAR source_url per row.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "company": "<company>"
    },
    "name": "insider_activity"
  }
}

Input Schema

NameRequiredDescriptionDefault
modeNosummary
limitNo
top_kNo
companyYes
periodsNo
directionNopurchase
since_dateNo
until_dateNo
granularityNo
include_rawNo
window_daysNo
min_insidersNo
reporter_cikNo
reporter_classNo
min_total_valueNo
transaction_typesNo
include_derivativesNo

Output Schema

NameRequiredDescriptionDefault

No arguments

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 already cover read-only/idempotent/non-destructive, so the description goes further: default 365-day window, until_date ignored in clusters, max 60 periods, 1000-row cap (default 50), top_k default 5 with 0 = all, and sources limited to the 1,000 newest transactions. These are the operational constraints an agent needs to avoid bad calls.

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?

Mode list is front-loaded and the Args/Returns layout is scannable. It is dense but almost every line carries a default, range, or mode attribution; only mild length from listing parameters that duplicate schema names.

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?

For a 17-parameter, three-mode tool, the description covers mode selection, defaults, caps, per-mode parameter applicability, and return shapes with source_ref/source_url linkage. Nothing an agent needs to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must carry the parameter burden, and it does: it documents company, date range and defaults, include_derivatives scope, granularity/periods caps, direction values, cluster tuning ranges (window 1-365, insiders >= 2), and transaction filter values including reporter_class options and limit cap.

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 opens with a specific verb+resource: 'SEC Form 4 insider trading for a US company', then enumerates three distinct modes with what each returns. An agent can tell exactly what data it gets and how each mode differs from the others.

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?

Each mode carries usage context: summary answers 'Is the CEO buying?', clusters are flagged as 'descriptive, not a recommendation', transactions yields raw rows newest-first. It does not name sibling tools or state exclusions relative to alternatives such as governance, so it stops short of full when/when-not guidance.

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

All Clarifo 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