MetricDuck — Financial Analysis

Compare Companies / Peers

compare_companies

Read-only

Use this when the user asks how a company compares with its peers or named rivals: a side-by-side table of ~70 metrics (latest TTM, FY or Q), its rank on ROIC, operating margin and revenue growth, and whether it leads or trails on them; screen_companies finds companies by criteria, and get_metric_history covers one company's past.

Returns a side-by-side table covering valuation (P/E, P/B, EV/EBITDA, EV/Sales, FCF yield), profitability (gross/operating/net/EBITDA margins, ROE, ROA, ROIC), leverage & liquidity (cash, debt/equity, net debt/EBITDA, interest coverage, current ratio), efficiency (asset/inventory turnover, DSO, cash conversion cycle), and capital returns (dividend yield, dividend payout ratio, buyback yield, shareholder yield). Sector-inapplicable metrics are omitted (e.g. gross margin / FCF leverage for banks).

Pass 'metrics' to focus the table on specific metric_ids. Each company's row is dated: 'Data through' is its latest reported period, and valuation multiples are priced at the last close on/before that period end (period-end LOCF) — NOT today's price, and the dates can differ across peers by a quarter. For a multiple AS OF a specific date, or at the live price, or a CUSTOM definition (e.g. lease-adjusted EV), assemble it from get_stock_price (price leg) + get_metric_history primitives.

peer_mode controls peer selection:

'sector' (default): auto-selected from same sector + similar market cap
'tags': auto-selected by business model similarity (tag Jaccard) — better for cross-sector comparisons

Override with custom_peers for specific matchups. The number of custom_peers is capped (up to 10 peers); exceeding it returns the limit and the count you asked for, so retry with that many.

Use Cases:

"Compare AAPL vs MSFT" -> compare_companies("AAPL", custom_peers="MSFT")
"How does NVDA stack up in its sector?" -> compare_companies("NVDA")
"Dividend payout ratio: KO vs KDP/PEP/KHC" -> compare_companies("KO", custom_peers="KDP,PEP,KHC", metrics="dividend_payout_ratio,dividend_yield")

Input Schema

Name	Required	Description	Default
`ticker`	Yes	Primary company ticker symbol to compare (e.g., 'AAPL'). Must be exact.
`metrics`	No	Optional comma-separated metric_ids to show instead of the default curated table (e.g. 'dividend_payout_ratio,dividend_yield,ev_ebitda,roa,interest_coverage'). Drawn from the ~70 curated fundamentals. A near-miss such as 'operating_margin' is read as 'oper_margin' and said so; any other unknown id is named in the response with its closest ids. Responses cap at ~20K chars — a subset here (or fewer custom_peers) keeps a large comparison whole.
`peer_mode`	No	Peer selection method: 'sector' (same sector + similar market cap, default) or 'tags' (business model similarity — finds companies with overlapping classification tags). Use 'tags' for cross-sector business model comparisons, e.g. NVDA vs AMD/Broadcom instead of NVDA vs MSFT/GOOG.	sector
`period_type`	No	'TTM' (default): trailing twelve months. 'FY': each company's latest reported fiscal year. 'Q': each company's latest reported fiscal quarter. Each company is at ITS OWN latest period (fiscal years end in different months, e.g. CRM January, ORCL May), and the 'YoY' rows compare it with the same period a year earlier ('Prior period' row). At 'Q' the ratios annualized from one quarter (P/E, EV multiples, ROE/ROA/ROIC, yields, turnover) are not shown. net_interest_income (banks) is served at FY and Q only. Example: compare_companies("JPM", custom_peers="BAC,WFC", period_type="Q", metrics="net_interest_income,net_income").	TTM
`custom_peers`	No	Optional comma-separated peer tickers (e.g., 'MSFT,GOOG,AMZN'). Auto-selected if omitted.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 10, 2026

addedInput schema / properties / period_type

Added value: +{
+  "default": "TTM",
+  "description": "'TTM' (default): trailing twelve months. 'FY': each company's latest reported fiscal year. 'Q': each company's latest reported fiscal quarter. Each company is at ITS OWN latest period (fiscal years end in different months, e.g. CRM January, ORCL May), and the 'YoY' rows compare it with the same period a year earlier ('Prior period' row). At 'Q' the ratios annualized from one quarter (P/E, EV multiples, ROE/ROA/ROIC, yields, turnover) are not shown. net_interest_income (banks) is served at FY and Q only. Example: compare_companies(\"JPM\", custom_peers=\"BAC,WFC\", period_type=\"Q\", metrics=\"net_interest_income,net_income\").",
+  "enum": [
+    "TTM",
+    "FY",
+    "Q"
+  ],
+  "type": "string"
+}

First observedOct 1, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the readOnly/openWorld annotations: discloses the period-end LOCF pricing rule (multiples are NOT at today's price), that row dates can differ across peers by a quarter, that sector-inapplicable metrics are omitted, that Q annualized ratios are suppressed, and that responses cap at ~20K chars. The 10-peer cap and its failure mode ('returns the limit and the count you asked for, so retry') is exactly the kind of operational detail agents need.

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 trigger, then bulleted peer_mode rules and three concrete use-case call examples — well structured and skimmable. It runs long and repeats the 'Data through'/period-end point that the schema partly covers, so it is dense rather than tight.

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 5-param, no-output-schema tool, everything an agent needs is present: peer selection modes, period semantics, metric selection and its fallbacks, size caps, and where to go for data this tool deliberately does not provide.

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 already 100%, so the baseline is 3; the description still adds real value beyond it — the custom_peers cap and its retry behavior, and the metrics-subset workaround for the response-size limit. Most other parameter guidance (peer_mode, period_type semantics) duplicates the schema text rather than extending it.

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 (side-by-side comparison table of ~70 metrics with peer ranks on ROIC/margin/growth) and immediately differentiates from screen_companies and get_metric_history. An agent knows exactly what this returns versus its siblings.

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?

Opens with an explicit trigger ('when the user asks how a company compares with its peers or named rivals'), names the two alternative tools and their scopes, and explains when to pick peer_mode='sector' vs 'tags'. It even routes the agent elsewhere (get_stock_price + get_metric_history) for as-of-date or custom-definition multiples.

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

All MetricDuck — Financial Analysis 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.

Resources

Need Help?