Clarifo

get_valuation_history

Read-onlyIdempotent

Return historical valuation multiples for a listed company.

Each data point represents P/E, P/B, P/S, EV/EBITDA, EV/EBIT, EV/Sales and FCF yield as of one trading day, pre-computed from that day's closing price and the latest annual fundamentals. Data is delayed by one day (up to yesterday).

At least one of company_name or ticker must be supplied. days controls the lookback window (default 365, max 1825).

Returns {company, ticker, data_points, period, series, pe_basis} where series is a list of daily multiples snapshots. US issuers also carry pe_ttm (trailing-twelve-month EPS, point in time): prefer it for a P/E trend; trailing_pe is on the latest fiscal year.

Rendering: when the trend matters, draw a static line chart (x=date, one line per multiple) from series yourself per the server's "Charts" guidance (Clarifo theme, source line ending "Clarifo calculation"; no widgets). In ChatGPT (with output="python") or a host that cannot draw: render_chart(source_tool="get_valuation_history", source_args={...same args...}).

On error: {"error": "...", "failure_kind": "..."}.

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_valuation_history"
  }
}

Input Schema

Name	Required	Description	Default
`days`	No
`ticker`	No
`company_name`	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 declare a safe read-only, idempotent operation, and the description adds genuinely new behavior: data is delayed by one trading day, values are pre-computed from close price plus latest annual fundamentals, and errors return a failure_kind envelope. The pe_ttm vs trailing_pe caveat is the kind of nuance an agent cannot get from the schema.

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 core purpose, then constraints, then return shape, then rendering. The rendering paragraph is long and host-specific, but it is actionable operational guidance rather than filler; a small amount of formatting noise (backticks, bold headers) is the only drag.

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?

Despite an output schema existing, the description still clarifies the semantics of the returned fields (series as daily snapshots, pe_ttm point-in-time vs trailing_pe fiscal-year), plus latency and error shape. Nothing an agent needs to invoke it correctly appears missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must carry the load and largely does: it documents the cross-parameter constraint that at least one of company_name/ticker is required and that days defaults to 365 with a max of 1825, neither of which appears in the schema. It does not say what company_name accepts (fuzzy match, legal name) or the expected ticker format.

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?

States a specific verb and resource ('Return historical valuation multiples') and enumerates exactly which multiples (P/E, P/B, P/S, EV/EBITDA, EV/EBIT, EV/Sales, FCF yield), which cleanly separates it from price-history or statement-level siblings.

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?

Gives concrete usage context: at least one identifier is required, 'days' bounds the window, and it advises preferring pe_ttm for a P/E trend and pe_ttm/trailing_pe distinction. It also prescribes the chart workflow when trends matter. It stops short of naming when to choose this over get_stock_price or get_company_financials.

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.