Clarifo

get_ceo_barometer

Read-onlyIdempotent

Serve the CEO Barometer board (methodology ceo-tone-v2): how upbeat or cautious CEOs sound in their own published reviews, by market, sector, size tier and company, with QoQ / YoY, the dominant tone dimension and the market trend. It measures tone, not company performance.

Reading the numbers: * index is on a 0-100 scale. 50 = the average tone of Nordic companies in 2020-2023 (not a neutral midpoint or a percentage). Tone bands: >= 57 pos, <= 27 neg, else neu. * jev_scores (0-4, with jev_confidence) are six dimensions rated by a third-party model (TypeSafe Jev): confidence, demand, profitability, growth_ambition, caution, external_blame. Silence scores lowest; caution and external blame lower the index. * jev_evidence explains each displayed column (1-10) with a verified quote. uncertain: true: the two raters disagree on the band; do not present a stale: true cell as the explanation. * Do not compare markets by level: US rows come from shareholder letters (genre: us_letter), Nordic rows from CEO reviews. trend_constant_composition is the like-for-like trend.

Args: period: period_end YYYY-MM-DD; default the newest period with enough reporters. company: One company (US: lowercase ticker; Nordic: name); adds company_signal. include_themes: Backward compatibility only. include_companies: Return the full companies[] (default off). include_trend_members: Per-period membership, for custom subsets (heavy; default off). history_periods: Trend points to keep (default 4; 0 = all).

Returns: {market, period, periods, release, distribution, sectors, markets, cap_tiers, companies[], trend[], company_signal?, trend_members[]?}. release is "locked" or "provisional" (kept off the trend).

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

Input Schema

Name	Required	Description	Default
`period`	No
`company`	No
`include_themes`	No
`history_periods`	No
`include_companies`	No
`include_trend_members`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already establish read-only, idempotent, closed-world behavior, yet the description adds substantial context beyond them: the 0-100 index anchoring (50 = Nordic 2020-2023 average), tone band thresholds, the fact that silence scores lowest and caution/external blame lower the index, the meaning of uncertain and stale flags, and the warning not to compare US shareholder-letter rows with Nordic reviews by level. It also discloses the release lock/provisional state and that provisional periods are kept off the trend — exactly the operational detail annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Structure is strongly front-loaded: purpose, then interpretation rules, then args, then returns. The interpretation bullets are dense but each carries non-obvious semantics (band thresholds, stale/uncertain handling) that an agent cannot get elsewhere. The Returns block is partly redundant with the output schema, but it is short and adds the locked/provisional distinction.

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-parameter analytical tool with no schema descriptions, the definition supplies purpose, all parameter semantics, interpretation rules and caveats, plus the release-state behavior. With an output schema present, it needn't enumerate return fields in depth, and the brief Returns block is enough.

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: period format YYYY-MM-DD plus its default rule, company identifier formats (US lowercase ticker, Nordic name) and the side effect of adding company_signal, include_themes deprecated status, include_companies default, include_trend_members purpose and cost, and history_periods default of 4 with 0 meaning all. Every one of the six parameters gains meaning absent from the bare schema.

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 description opens with a specific verb and resource ('Serve the CEO Barometer board') and immediately scopes it: tone of CEOs in published reviews broken down by market, sector, size tier and company, with a methodology label (ceo-tone-v2). The line 'It measures tone, not company performance' usefully fences it off from financial siblings, but no sibling tool is named, so the boundary with score_ceo_sentiment_for_company is left implicit.

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?

Context is clear: defaults are stated for period ('newest period with enough reporters') and history_periods, and include_themes is flagged as 'Backward compatibility only' while include_trend_members is marked 'heavy; default off', which steers an agent away from costly options. There is no explicit when-to-use-this-vs-another-tool statement, so it stops short of the top band.

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.