Clarifo

answer_reporting_standards

Read-onlyIdempotent

Answer a reporting-framework / financial-statement-preparation question for a controller, auditor or CFO, with paragraph-level standard citations and real filing examples of how companies implement it. Runs a Clarifo model, so it is not on every account; others get an informational message. Standard citations and filing examples come from Clarifo's index; contextual_links come from a live web search (the question and named companies are sent to a search API restricted to ifrs.org and Big-4 accounting sites).

Never print a raw page_id or [page_id: ...] marker: replace each with the matching sources[] card's citation_markdown.

When the detected standard has a curated teaching example (e.g. IFRS 15 cost-to-cost, IFRS 16 lease liability), interactive_example is returned. Present it as a step-by-step walkthrough (presets side by side, five_steps / scenarios as tables with the key numbers), not as an app-style widget with sliders or toggles.

Args: question: The reporting question, e.g. "How is a defined-benefit pension liability measured under IAS 19?". company: Optional name or ticker to draw examples from; omit for examples across the corpus. framework: "ifrs" (default), "us_gaap", "local_gaap" (Nordic) or "multi". question_kind: "standard_rule" (default), "structure", "preparation", "sec_filing" (10-K / 10-Q mechanics) or "comparison". locale: "en" (default), "fi" or "sv". include_examples: Default true; ground in filing disclosures. jurisdiction_hint: e.g. "foreign private issuer", "EU".

Returns answer, standard_references, contextual_links, implementation_examples, accounting_context, sources, source_policy, sourcing (tag_filtered | semantic | no_relevant_example_found), detected_standards, coverage and, when matched, interactive_example. Failures return error.

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": {
      "question": "<question>"
    },
    "name": "answer_reporting_standards"
  }
}

Input Schema

Name	Required	Default
`locale`	No	en
`company`	No
`question`	Yes
`framework`	No	ifrs
`question_kind`	No	standard_rule
`include_examples`	No
`jurisdiction_hint`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Well beyond the annotations (readOnly, idempotent, openWorld, non-destructive), the description discloses a real availability constraint, the provenance split between the Clarifo index and a live web search, and an explicit data-egress warning that the question and named companies are sent to a search API restricted to ifrs.org and Big-4 sites. It also specifies a mandatory post-processing rule (replace every page_id marker with the matching sources[].citation_markdown) and how interactive_example must be rendered. That is unusually rich behavioral context.

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?

Purpose and availability gating are front-loaded, and the Args block is dense but scannable. The description is long, but nearly every line carries operational weight (gating, data egress, citation marker rule, presentation rule). The rendering instructions for interactive_example and the full return-key enumeration are the most expendable parts and push it below 5.

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 complex, gated, multi-source research tool this is complete: purpose, availability, data sources and privacy implications, all seven parameters, failure behavior ('Failures return error'), and the sourcing enum values an agent must interpret. An output schema exists, so the return-key list is redundant but harmless 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 7 parameters, so the description carries the full burden and does: it gives a concrete example for question, explains company as optional with the omit-case behavior, and supplies the allowed values for framework ('ifrs' default, 'us_gaap', 'local_gaap' Nordic, 'multi'), question_kind, and locale — enums the schema itself lacks. include_examples and jurisdiction_hint also get default and example semantics. This adds meaning the input schema does not provide.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence names a specific verb and resource ('Answer a reporting-framework / financial-statement-preparation question') plus the audience and the distinguishing output (paragraph-level standard citations, real filing examples). That is far more precise than any sibling like get_company_financials or reporting_change. It stops short of 5 because it never explicitly contrasts itself with a sibling tool or states the boundary of its domain.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

Usage is implied rather than stated: the availability gate ('Runs a Clarifo model, so it is not on every account; others get an informational message') tells the agent when it will fail, and the question_kind values signal the kinds of questions it accepts. There is no explicit 'use this instead of X' routing and no stated prerequisite for when a standards question should go here versus a general company-data tool.

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.