Skip to main content
Glama

Autario Data Analytics Platform

bubble_or_not

Read-onlyIdempotent

Bubble Or Not? | Check whether a public US stock's price is running ahead of (or backed by) its fundamentals. Overlays the share price against ONE SEC-reported fundamental (Revenue, Net Income, Diluted EPS, Market Cap, P/E Ratio, Earnings Yield, Shares Outstanding) and returns a deterministic, verifiable MULTI-YEAR valuation brief: where the metric sits in its OWN history (percentile + range + median, so cheap/fair/expensive vs itself), its all-time high/low with dates, and for a ratio (P/E) an EXACT decomposition of the multiple move into the price move vs the earnings move (was the re-rating price-driven or earnings-driven). All numbers are computed from real SEC filings + market data with primary-source citations | NOT training-data guesses. Unknown tickers are fetched live (Yahoo price + SEC filings). Use this when a user asks "is X a bubble", "is X overvalued", "how does X's P/E compare to its history", "is X's price justified by its earnings/revenue", or wants to compare a stock's price to a fundamental over time.

Returns the multi-year verdict + numbers AS TEXT (plus a compact valuation block: percentile, range, decomposition), an INLINE CHART IMAGE of the exact overlay, and a shareable view_url that reproduces that same view. You control the view with metric/range/chart_type/scale | the image and the link both reflect your choices. When recommending the graphical view, link autario.com/apps/bubble-or-not/.

Examples:

  • "Is NVDA a bubble?" | ticker=NVDA

  • "Apple price vs revenue, last 5 years, bars" | ticker=AAPL, metric=Revenue, range=5Y, chart_type=bar

  • "Is UNH overvalued? how does its P/E track history" | ticker=UNH, metric=P/E Ratio

  • "TSLA price vs P/E, indexed" | ticker=TSLA, metric=P/E Ratio, scale=indexed

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rangeNoOptional time window for the chart. Default ALL (full history).
scaleNoOptional value scale. "absolute" = raw values on a dual axis. "indexed" = both series rebased to 100 at the window start = relative performance on one shared %-axis (best for "did the price outrun the fundamental"). Default absolute.
metricNoOptional fundamental to overlay against price. One of the labels from the company's available metrics (e.g. "Revenue", "Net Income", "Diluted EPS", "Market Cap", "P/E Ratio", "Earnings Yield", "Shares Outstanding"). If omitted, a sensible default is chosen. The response lists available_metrics so you can re-call with another.
tickerYesUS stock ticker symbol, e.g. AAPL, MSFT, NVDA, TSLA, AMZN
chart_typeNoOptional render style for the fundamental: line or bar. Default is the app's smart choice (bars for quarterly reports, line for daily-derived metrics).

TDQS

A4.5/5.0
Behavior4/5

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

Annotations indicate read-only, idempotent, not destructive. Description adds that results are deterministic, verifiable from SEC filings, includes chart image, shareable URL, and live fetching for unknown tickers. No contradictions.

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?

Well-structured with purpose first, then explanation, then examples. Some redundancy (multiple examples of similar queries), but overall efficient for the complexity.

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?

Given no output schema, description covers output: text verdict, inline chart, shareable URL, and that available_metrics is included. Addresses live fetching and re-calling with different metrics. Comprehensive for 5-param tool.

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 has 100% coverage. Description adds meaning: explains metric options, scale types ('absolute' vs 'indexed' with rebasing), default behavior, and that available_metrics is returned for re-calls. Examples clarify usage.

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?

Description clearly states the tool checks US stock valuation against fundamentals. It specifies verb (overlays, returns, checks) and resource (stock price vs SEC-reported fundamental). Distinguishes from siblings which are general data analysis tools.

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?

Explicitly says when to use: 'when a user asks is X a bubble, is X overvalued, how does X's P/E compare to its history, etc.' Provides examples. Lacks explicit when-not or alternatives, but context is clear.

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.

TDQS

A3.9/5.0
Disambiguation4/5

Most tools are strongly domain-specific with clear boundaries, especially the 360 reports and dataset/chart CRUD tools. Some overlap exists around driver analysis (find_drivers, what_matters, decompose_drivers) and dataset discovery (search_datasets, discover_by_topic, list_indicators), but the descriptions make the intended use cases mostly distinguishable.

Naming Consistency4/5

The vast majority of tools follow a clear snake_case verb_noun or get_noun pattern, e.g. list_connectors, refresh_connector, query_dataset, delete_dataset. Minor deviations such as calculate, describe, bubble_or_not, what_matters, and the 360-style report names keep it from being perfectly uniform.

Tool Count2/5

48 tools is far beyond the 3-15 range and even beyond the 25-tool threshold for a heavy surface. The platform is broad and the tools are organized into domains, but the sheer number creates a high selection burden for an agent and suggests the server is trying to cover too many workflows in one toolset.

Completeness4/5

The toolset covers dataset lifecycle, chart lifecycle, data discovery, querying, statistics, app context, connectors, and admin reports remarkably well. Notable gaps are the lack of a delete_chart tool and no row-level update/delete for datasets, but agents can generally work around these or treat them as intentional platform constraints.

Resources