Clarifo

search_filing_content

Read-onlyIdempotent

Semantic search within the full text of company filings (annual and interim reports, stock exchange releases, SEC filings) for qualitative questions: strategy, risk factors, guidance, accounting policies. Covers US (NYSE, NASDAQ) and Nordic (HEL, STO) filings. Results are ranked by meaning, not keywords: check each result's company_name, and put synonyms (and for Nordic filings, local-language terms) in the query. Ask one topic per call: several topics in one query ("compute, customer concentration and key people") blend into passages about none of them. For a US filer's risk factors as a list, or what changed between two filings, use search_filings(mode="risk_factors" / "risk_changes").

Args: company: Name or ticker, fuzzy-matched ("DHI", "D.R. Horton"). A company named only in the query is auto-detected (resolution.auto_detected); set it explicitly to be certain. year: Fiscal year. quarter: 1-4; unpopulated for part of the corpus, so use only for one quarter's interim report. With quarter unset, a period in the query ("Q3 2026", "H1 2025", "FY2024") is applied as the filter; period_scope reports it. Passages from another period are never in results: they come under other_period_results (period_scope.status is period_not_indexed when none match the period asked). document_type: "annual_report", "interim_report", "stock_exchange_release", "10-K", "10-Q"; aliases normalized. market: "us" or "nordic"; omit to auto-detect. With no company or index the search covers Nordic filings only (market="us" alone returns nothing). index: Only "sp500" (forces US, queries every constituent). Cannot be combined with company. limit: Passages to return (default 5, max 20). max_total_results caps rows after adjacent-page expansion. include_adjacent_pages: Also return the page before and after each Nordic hit (is_adjacent_page, supports: "context"), for policy text that spans pages. For a full page use get_filing_snapshot with include_text=true. topic_tags / ifrs_tags: Restrict to pages tagged with these concepts (deterministic; unknown values are ignored and reported back). Topics are snake_case, e.g. leases, goodwill, impairment, segment_reporting, risks_uncertainty, strategy_outlook, ceo_review, dividends, sustclimate. IFRS (Nordic only): "IAS 1" .. "IAS 40", "IFRS 1" .. "IFRS 18", e.g. "IFRS 16". auto_detect_tags: Default True: with no explicit tags, tags are detected from the query. A tag filter matching nothing is retried untagged (tag_filters.applied: false). For US filings detected tags only order the passages. response_mode: "detailed" (default) or "concise" (drops long excerpts, keeps citation fields); use "concise" across several companies.

Returns results (content, page_id, page_number, evidence, citation_markdown, source_url), sources, source_policy, resolution, tag_filters, and a diagnostic when nothing is found. Keyword-fallback hits (pages not yet vectorised) carry retrieval: "keyword". Each result has relevance (high / medium / low against the best passage of this search, not a judgement of the answer), its topic_tags, risk_factor (heading, category) for a SEC risk-section passage, and also_in_versions when the same text is in another version of the filing (an S-1 and its S-1/A). Cite as numbered links to citation_markdown's URL; page_id is only for follow-up calls (get_filing_snapshot) and never shown to the user.

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": {
      "query": "<query>"
    },
    "name": "search_filing_content"
  }
}

Input Schema

Name	Required	Default
`year`	No
`index`	No
`limit`	No
`query`	Yes
`market`	No
`company`	No
`quarter`	No
`ifrs_tags`	No
`topic_tags`	No
`document_type`	No
`response_mode`	No	detailed
`auto_detect_tags`	No
`max_total_results`	No
`include_adjacent_pages`	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 only declare readOnly/idempotent/non-destructive; the description goes much further, disclosing period-scoping behavior (other_period_results, period_not_indexed), the untagged retry on empty tag filters, keyword-fallback hits when pages aren't vectorised, and relevance semantics that are relative to this search rather than a quality judgement. It also states the counterintuitive constraint that market="us" alone returns nothing and that index cannot be combined with company.

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 and well structured: purpose and disambiguation first, then a scannable Args block, then return-value notes. It is long, and a few asides (the S-1/S-1-A version example, some internal field names) could be trimmed, but nearly every sentence carries operational information.

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 14-parameter tool spanning two markets with auto-detection and fallback paths, the definition covers selection, query construction, filtering gotchas, and output fields. An output schema exists, yet the return summary still adds useful guidance (cite citation_markdown, never show page_id to the user).

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 does: every one of the 14 parameters is explained with formats, defaults, and caveats (quarter unreliable for part of the corpus, limit default 5 / max 20, topic_tags snake_case examples, IFRS tag range, concise vs detailed response_mode). This is meaning the bare JSON schema could not supply.

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: 'Semantic search within the full text of company filings', then enumerates the source types (annual/interim reports, stock exchange releases, SEC filings) and the question classes it suits. It also names the sibling that handles the list-style risk-factor case, so an agent can separate the two without opening either 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 routing advice: use this for qualitative questions, use search_filings(mode="risk_factors" / "risk_changes") for risk-factor lists or period deltas. It also gives query-shaping rules ('one topic per call', add synonyms and local-language terms, check company_name) and tells the agent when to set company explicitly vs rely on auto-detection.

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.