Clarifo

intelligence

Read-onlyIdempotent

Anomaly-detection intelligence over one company or a universe. One tool, six operations, chosen with op:

"brief" (default): plain-language brief on what changed in ONE company's numbers, grounded in measured anomaly signals, filing citations and CEO quotes. Requires company. Pro-plan tool (LLM-narrated) for every brief_operation: "brief" (fresh narrative), "history" (past versions), "get_version" (version_id), "diff" (from_version_id -> to_version_id, with a why-changed note).
"discovery": anomaly-ranked watchlist across the universe ("any red flags right now?"). No company; sector, min_score (default 0.5), limit (default 20).
"dna": how ONE company reports vs. peers on six dimensions: predictability, oneoff, discretion (goodwill / judgment), breadth (disclosure), practice and guidance (delivery record). Requires company; signal narrows to one dimension.
"report_structure": how a UNIVERSE builds its annual report: section shares (median / p25 / p75; pages for Nordic PDFs, text length for SEC filings), typical order and deviating reports. Universe: companies (max 500), preset (a get_sector_peer_set slug), market ("nordic" / "us" / "all") or index="sp500". Deterministic; write the narrative and cite sources[].citation_markdown.
"restatements" (beta): which earlier headline figures (revenue, operating profit, net profit, assets, equity, operating cash flow) a company RESTATED in later filings, by how much, and the likely cause (discontinued_operations, presentation_reclassification, ifrs18_presentation, remeasurement), plus its IFRS 18 baseline. With company: one company. Without: universe screen filtered by market, cause, year (restating fiscal year), limit. Deterministic; the cause is inferred from which items moved, so cite sources[].citation_markdown and tell the user to confirm in the filing's restatement note.
"ifrs18" (beta): IFRS 18 (FY2027) exposure baseline for ESEF reporters, exposure = no_operating_subtotal | entity_specific_subtotal | reclassification_history | subtotal_reported. With company the same as restatements.

For overviews or financials use get_company_snapshot / get_company_financials; to rank by a metric, screen_companies; for historical break points, detect_inflection_points.

Args: period: brief, e.g. "2024" (FY) or "2024-Q2"; default freshest. max_signals: brief (1-10, default 3). language: brief / dna: "en" (default) or "fi"; pass the user's language. knowledge_cutoff: brief, ISO YYYY-MM-DD point-in-time view. year: report_structure fiscal year (default: latest report per company for a list, previous calendar year for a market / index). max_reports / include_reports / offset: report_structure (default 200, max 500; per-report rows, 25 per page from offset).

Returns: brief: {headline, paragraphs[], citations[], measured_track_record, coverage, provenance}. discovery: {items[], scoring_explanation, disclaimer}. dna: {signals[], methodology, disclaimer}. report_structure: section distribution plus sources[]. restatements / ifrs18: {restatements[] | items[], ifrs18, data_quality_flags, sources[], methodology}.

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": "intelligence"
  }
}

Input Schema

Name	Required	Default
`op`	No	brief
`year`	No
`cause`	No
`index`	No
`limit`	No
`market`	No
`offset`	No
`period`	No
`preset`	No
`sector`	No
`signal`	No
`company`	No
`exposure`	No
`language`	No	en
`companies`	No
`min_score`	No
`version_id`	No
`max_reports`	No
`max_signals`	No
`to_version_id`	No
`brief_operation`	No	brief
`from_version_id`	No
`include_reports`	No
`knowledge_cutoff`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, and the description adds real behavior beyond that: the Pro-plan/LLM-narrated gating on all ``brief_operation`` variants, the deterministic nature of ``report_structure`` and ``restatements``, the 25-per-page pagination, and the caveat that restatement causes are inferred and must be confirmed in the filing note. It stops short of describing enforcement of the Pro-plan limit or any failure mode, which keeps it off a 5.

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?

Structure is strong — the operation list is front-loaded and the Args block is terse and bullet-like. Density is justified by six operations and 24 parameters, but some sentences pack three facts together (the brief/Pro-plan/``brief_operation`` sentence), which costs a little scannability.

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 six-operation, 24-parameter tool this covers operations, per-op prerequisites, parameter meanings, pagination and output shape. An output schema exists and is echoed, and the sibling-routing paragraph closes the remaining ambiguity about when this tool is the wrong choice.

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%, so the description carries the full burden — and it does: ``op``, ``brief_operation``, ``company``, ``sector``, ``min_score``/``limit``, ``signal``, ``companies`` (max 500), ``preset``, ``market``, ``index``, ``period``, ``max_signals`` (1-10), ``language``, ``knowledge_cutoff``, ``year``, ``cause``, ``exposure``, the three version ids, and ``max_reports``/``include_reports``/``offset`` are each given meaning, defaults or accepted values. Nearly every one of the 24 parameters is explained in context.

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 by naming the resource (anomaly-detection intelligence over a company or universe) and enumerates all six operations behind ``op`` with specific verbs and inputs for each: brief narratives, discovery ranking, DNA peer comparison, report-structure distribution, restatements, and IFRS 18 exposure. An agent can tell exactly which operation it needs 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?

Each operation carries its own routing rule (``company`` required vs. universe screen, deterministic vs. LLM-narrated), and the closing paragraph explicitly redirects to siblings: ``get_company_snapshot``/``get_company_financials`` for overviews, ``screen_companies`` for metric ranking, ``detect_inflection_points`` for historical break points. When-to-use and when-to-use-something-else are both stated.

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.