Clarifo

company_events

Read-onlyIdempotent

Corporate events: US SEC 8-K events, and official stock-exchange releases of Finnish and Swedish listed companies (from 2026-01-01: inside information such as profit warnings and large orders, management changes, tender offers, reports). Also the report calendar.

Scopes:

"company" (default): one company's events, newest first; summarise=True returns per-type counts instead. Set since/until around a date to explain a price move.
"cross_company": events across companies filtered by event type, index="sp500", industry (substring), companies list or market="nordic" (default US).
"calendar": scheduled interim / annual report dates in since_date..until_date (default today .. +14 days, max 120), optional company / market; published: true once the report is in Clarifo, include_published=False keeps only upcoming. Never extend the calendar with guessed dates. companies (up to 30) or portfolio_id (from portfolios) gives several companies in one call; coverage then says per company why it has no date (later_date_known, not_announced_yet, no_calendar_coverage).
"offerings": one US company's priced offerings (424B4 / 424B1 prospectus), the IPO first, then follow-ons newest first.
"ipos": recent US IPOs market-wide, newest first (default since: 90 days); SPACs are flagged is_spac.

Args: company: Name, ticker or CIK; required for company scope. since_date / until_date: YYYY-MM-DD (default since: 365 days for company, 30 days for cross_company, 90 days for ipos; none for offerings). event_types: acquisition, disposition, executive_change, director_change, material_contract, default, bankruptcy, covenant_breach, amendment, auditor_change, earnings, guidance_update, other; Nordic also inside_information, profit_warning, tender_offer, capital_event, major_shareholding, insider_trade, share_repurchase, agm. Nordic profit warnings and guidance changes are filed as inside information: read the titles. item_numbers: Raw 8-K items, e.g. ["2.01"] (US). limit: Max 500 (ignored when summarising). market: "us" or "nordic". portfolio_id: Calendar scope: the user's portfolio whose companies to list (from portfolios). materiality: Nordic only: "high" (inside information, tender offers, management changes; cross_company default), "medium" (+ reports, capital events, holdings; company default) or "low" (everything).

Returns events[] (company and cross_company), summary (summarise) or calendar events[] (expected_date, period_label, confirmed, published). Nordic events carry title, category, materiality, excerpt and source_url to the filed release (cite it). offerings[] / ipos[]: offering_type, pricing_date, price_per_share, price_range, shares_offered, gross_proceeds_usd, exchange, ticker, underwriters, registration (S-1 / F-1), source_url; no coverage: diagnostic.reason = "no_offerings_data_yet".

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "company_events"
  }
}

Input Schema

Name	Required	Default
`index`	No
`limit`	No
`scope`	No	company
`market`	No
`company`	No
`industry`	No
`companies`	No
`summarise`	No
`since_date`	No
`until_date`	No
`event_types`	No
`materiality`	No
`item_numbers`	No
`portfolio_id`	No
`include_published`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial operational context beyond them: per-scope date defaults, the 500 limit cap being ignored when summarising, the 120-day calendar ceiling and 14-day default window, the 30-company cap, and the diagnostic reason 'no_offerings_data_yet' when there is no coverage. It even instructs the agent to cite source_url.

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?

Front-loaded with the resource, then cleanly partitioned into scope bullets and an Args block, so it is scannable despite its length. It is dense but nearly every clause carries operational meaning; the length is justified by five scopes and 15 parameters, though the Args section repeats a few defaults already stated in the scope bullets.

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 five-scope, 15-parameter tool this covers what an agent needs to select a scope and call it correctly, including the Nordic materiality semantics and the caveat that profit warnings are filed as inside information. Return shapes are summarised briefly even though an output schema exists, which is a minor redundancy rather than a gap.

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 description coverage is 0% across 15 parameters, so the description carries the full burden and does: it documents company, since_date/until_date with per-scope defaults, a full event_types vocabulary (including the Nordic-only additions), item_numbers format example, limit, market, portfolio_id, materiality tiers and their per-scope defaults, plus index/industry/companies/summarise/include_published inline in the scope descriptions.

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 opening line names the resource precisely (US SEC 8-K events, Nordic exchange releases, report calendar) and the scope list separates five distinct modes: company, cross_company, calendar, offerings, ipos. An agent can tell this apart from siblings like get_filing_snapshot or fetch_edgar_filing_on_demand 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use per scope, including the motivating use case ('Set since/until around a date to explain a price move') and defaults that differ per scope. It also gives a negative instruction — 'Never extend the calendar with guessed dates' — and explains how to interpret missing calendar coverage via the coverage field.

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

All Clarifo tools Inspect

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.