Skip to main content
Glama

get_industry_valuation_benchmark

Read-onlyIdempotent

Industry-level valuation + profitability benchmark: the median and p25/p75 spread of P/E, P/B, EV/EBITDA, EV/EBIT, margins, ROE and revenue growth across the industry's peer set.

Use this to answer "what does industry X trade at?", "is company Y cheap vs its industry?", or "how wide is the valuation spread in this sector?" — without rerunning a full industry analysis. The numbers are computed deterministically and stored by Clarifo's industry analysis; this tool reads the latest stored snapshot from the last 120 days.

Args: industry: Industry name or group key (e.g. "gold miners", "gold_miners"). Resolved via the industry synonym mapper. market: Market scope the benchmark was computed for — "all" (default), "us", "stockholm", or a +-joined combination. Use "all" unless the user asks for one market.

Returns: {industry_group, industry_display_name, market, as_of_date, year, peer_count, constituents, stats:{metric:{count,median,p25,p75,...}}, median_ev_ebitda, median_pe, median_pb, median_roe, median_ebit_margin} — or {"error": "no_benchmark_stored", ...} with alternative_tools (screen_companies, screen_companies_multi, value_company, get_sector_peer_set) when no recent benchmark is stored for that industry/market. Benchmarks are computed offline; this tool cannot trigger one.

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": {
      "industry": "<industry>"
    },
    "name": "get_industry_valuation_benchmark"
  }
}

Input Schema

NameRequiredDescriptionDefault
marketNoall
industryYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior4/5

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

Well beyond the annotations: it discloses that numbers are computed offline and deterministically, that this tool only reads the latest stored snapshot capped at 120 days, and that it cannot trigger a computation. The error contract (no_benchmark_stored plus alternative_tools) is spelled out. The one gap is that the 120-day cutoff is the sole staleness rule stated with no mention of how as_of_date relates to it.

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 definition, then usage, then args, then returns — easy to scan. The Returns block re-enumerates every field even though an output schema already exists, which is the one section that does not fully earn its space.

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?

Covers scope, filtering semantics, determinism/offline provenance, staleness window, and the failure mode with fallbacks. Rich enough that an agent can decide, call, and recover from the empty case without a second tool lookup, even though the schema itself documents nothing.

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 coverage is 0%, so the description carries the load and does: industry accepts a display name or a normalized group key ("gold miners" vs "gold_miners") resolved through a synonym mapper, and market's valid domain ("all" default, "us", "stockholm", or "+"-joined combinations) is given with an explicit default-usage rule. This is meaning the bare schema cannot 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: an industry-level valuation and profitability benchmark, and enumerates exactly which metrics (P/E, P/B, EV/EBITDA, EV/EBIT, margins, ROE, revenue growth) plus the statistic shape (median, p25/p75). An agent can distinguish this from company-level siblings like value_company or get_company_financials purely from the first two lines.

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?

Explicitly lists the three question shapes it answers ("what does industry X trade at?", "is company Y cheap vs its industry?", "how wide is the spread?") and names the efficiency gain versus rerunning a full industry analysis. It also routes to alternatives (screen_companies, screen_companies_multi, value_company, get_sector_peer_set) when no stored benchmark exists.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.