Skip to main content
Glama

Fair Value Calculator

Find stock

resolve_stock
Read-onlyIdempotent

Find a listed company by name, ticker or ISIN-like input and return up to 5 matching stocks that Fair Value Calculator covers (40,000+ stocks worldwide), in the same order as the search on fairvalue-calculator.com. Each match has the exact "symbol" (TICKER.EXCHANGE) to pass to the other tools, the company name and a short valuation snapshot. Use it when the user names a company or the exchange is unclear; the returned symbol identifies the exact listing. Fields: valuation_status (undervalued = price at least 10% below fair value, overvalued = price at least 10% above fair value, else near_fair_value; no_valuation = covered, but no fair value is shown right now, note says why), upside_band (distance from price to fair value in 10-point bands, e.g. "10_to_20", "above_30", "below_-30"), quality_score (0-100 business quality), evidence_level (how much audited data backs the value), price_as_of (date of the share price the valuation status refers to), calculated_at (date the valuation models last ran for this stock), requested_symbol with listing = other_listing_same_company (present when the answer is about another listing of the same company than the symbol asked for, the listing the website shows for it, e.g. 939.HK answered with the Shanghai listing 601939.SHG; fair value and currency refer to the listing in symbol), deep_link (full analysis page on fairvalue-calculator.com with the fair value history chart and the result of each valuation model with its bear, base and bull case), trend12 (uptrend: true when the price one month ago was higher than twelve months ago, false when not, null when not known), trend12_pct (that change in percent), trend_arrow (arrow on the site: up = rising, sideways = sideways down to -10 percent, down = falling), buy_rules (the three buy rules of the Fair Value Calculator strategy, each true, false or null: fair_value = fair value upside of at least fair_value_min_pct percent, quality = quality score of at least quality_min, measured as in the backtest without the AI Quality points, trend = uptrend, all = all three met; quality_rule = the quality score the rule decided on, present only when it decides differently from quality_score; upside_rule = the fair value upside in percent the rule decided on (fair value before the cycle and dilution adjustment), present only when it decides differently from the shown upside; the strategy only buys stocks with all three), fair_value_adjustment (present together with upside_rule: the shown fair value was adjusted after the model blend, the buy rule decides on the value before; reason = cyclical_peak_year (a record profit year of a cyclical business is not carried forward in full), cyclical_trough_year (a weak year of a cyclical business is not carried forward in full), dilution_new_shares (new shares lower the value per share) or adjusted; before and now = the fair value before the adjustment and the shown fair value, only where the fair value itself is shown), fair_value_last_change (only in the verdict, present when the shown fair value changed by 15 percent or more within the last 30 days: date, before and after (the shown fair value before and right after that change; the current value is fair_value) and reason = new_fiscal_year_figures (the figures of fiscal_year arrived and the value was recalculated from them), cyclical_peak_year, cyclical_trough_year or dilution_new_shares (that adjustment started to apply on this date), calculation_update (an updated calculation went live for all stocks on this date, nothing happened at the company itself) or not_recorded (no cause is on record)).

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": {
      "query": "<query>"
    },
    "name": "resolve_stock"
  }
}

Input Schema

NameRequiredDescriptionDefault
queryYesCompany name or ticker, e.g. "Siemens", "Novo Nordisk", "AAPL".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive search behavior, so the description does not need to repeat safety details. It adds useful matching behavior such as the 5-result cap, website search order, 40,000+ stock coverage, and the requested_symbol = other_listing_same_company edge case. It does not explain no-match behavior or error cases, so it is strong but not exhaustive.

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

Conciseness3/5

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

Purpose and usage are front-loaded, but the remainder is one dense paragraph packing every return field and sub-field. The field glossary is useful because no output schema exists, but it is difficult to scan and longer than necessary; structured bullets would improve it.

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?

Because no output schema exists, the description must carry return-value semantics, and it thoroughly defines valuation_status, upside_band, quality_score, buy_rules, adjustments, trends, and listing edge cases. Combined with annotations and 100% schema coverage, it is complete enough to call the tool correctly; the absence of no-match/error text is minor.

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 100% for the single query parameter, establishing a baseline of 3. The description adds meaning beyond the schema by accepting name, ticker, or ISIN-like input and by addressing exchange ambiguity and exact-listing resolution. It still leaves query normalization and format rules unspecified, so a 4 is appropriate.

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?

The opening sentence names a specific verb (find), the resource (listed company/stock), accepted keys (name, ticker, ISIN-like), and output (up to 5 matches with exact symbol). It also states the downstream role: the returned symbol is what other tools need, which distinguishes it from preview/verdict 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?

It explicitly says to use it when the user names a company or when the exchange is unclear, and explains that the returned symbol identifies the exact listing. It does not state when not to use it or name specific alternative tools, so it falls short of full when/when-not/alternatives guidance.

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.