Skip to main content
Glama

screen_metric_trend

Read-onlyIdempotent

Multi-period time series of one financial metric across a peer group, each cell traceable to one filing period ("how has Costco's operating margin moved vs. Walmart and Target?").

Chart: per the server "Charts" guidance; in ChatGPT call render_chart(source_tool="screen_metric_trend", source_args=, output="python").

Pick companies either with peers (names or tickers, Nordic and US mixed) or by ranking the top top_n by rank_metric within countries / industry / tag_slugs.

Args: metric: revenue, gross_profit, ebit, ebitda, net_income, operating_cash_flow, free_cash_flow; margins gross_margin, operating_margin, ebit_margin, ebitda_margin, net_margin (computed deterministically; ebit_margin uses EBIT, operating_margin the IFRS operating profit line); plus granular IFRS line items (annual only). US EBITDA is operating income + D&A; companies without D&A drop out. peers: Explicit list; ranking filters are then ignored. countries: e.g. ["FI"], ["SE"], ["DK"], ["US"] or a combination; omit for all markets. industry: Free-text industry substring. tag_slugs: taxonomy filter. top_n: Ranked group size (1-50, default 8). window: Periods in the series (2-16, default 5). anchor_year: Latest period; omit for the latest available. frequency: "annual" (default) or "quarterly" (Nordic only). rank_metric: Ranking metric (defaults to metric). strict_resolution: Fail on ambiguous peer names instead of choosing.

Returns {metric, unit, frequency, periods, companies, series_data, chart_series, coverage}; error: {"error": "..."}.

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

Input Schema

NameRequiredDescriptionDefault
peersNo
top_nNo
metricNorevenue
windowNo
industryNo
countriesNo
frequencyNoannual
tag_slugsNo
anchor_yearNo
rank_metricNo
strict_resolutionNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations by disclosing computation semantics (margins computed deterministically, ``ebit_margin`` uses EBIT while ``operating_margin`` uses the IFRS operating profit line, US EBITDA is operating income + D&A), drop-out behavior for companies lacking D&A, and the Nordic-only limit on quarterly frequency. It also explains that granular IFRS line items are annual only and that ``strict_resolution`` fails on ambiguous names rather than guessing.

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-loads the purpose and the example query, then a chart note, then a compact per-argument block; nothing is padding. It is dense but justified for an 11-parameter tool, though the charting instruction sits between purpose and argument docs and slightly interrupts flow.

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 selection logic, computation rules, frequency constraints, error behavior, and the returned structure even though an output schema exists. For an 11-parameter screening tool with no schema descriptions, this is about as complete as a description can be.

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% and there are 11 parameters, so the description carries the full burden and does so: it enumerates allowed ``metric`` values, explains ``peers`` vs. ranking filters, gives country code examples, bounds ``top_n`` (1-50, default 8) and ``window`` (2-16, default 5), and clarifies ``anchor_year``, ``frequency``, ``rank_metric`` and ``strict_resolution``.

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+resource combination: a multi-period time series of one financial metric across a peer group, with each cell traceable to a filing period. The parenthetical example ("how has Costco's operating margin moved vs. Walmart and Target?") makes the output shape concrete, and it clearly differs from single-company tools like get_company_financials.

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 an explicit either/or selection rule: use ``peers`` explicitly, or rank ``top_n`` by ``rank_metric`` within ``countries``/``industry``/``tag_slugs``. It also states the precedence rule that ranking filters are ignored when ``peers`` is supplied. It lacks explicit when-not-to-use guidance versus siblings like compare_companies or screen_companies.

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.