ValuEdge

Get stock fundamentals

get_stock_fundamentals

Read-onlyIdempotent

Use this when the user asks for a stock's ValuEdge financial history, profitability, growth, balance-sheet evidence, business quality, or data coverage. An optional history_limit requests up to 30 periods of selected metrics, current EPS consensus for at most three future fiscal years where present, quarterly P/E samples from existing monthly observations, and bounded source-native annual income, balance-sheet, and cash-flow statement rows where the existing snapshot contains them. EPS is not normalized and past estimate revisions are unavailable. Selected metric trends remain distinct from the full annual statement JSON. Do not infer a trade instruction.

Input Schema

Name	Required	Description	Default
`ticker`	Yes
`history_limit`	No	Optional maximum number of recent annual/quarterly selected-metric rows and annual statement rows (1–30). Omit to preserve the existing compact response. Full annual statement rows retain source fields and currencies; missing source rows/provenance are reported, never filled. Current EPS consensus is capped separately at three future fiscal years; it is not normalized and past revisions are unavailable.

Output Schema

Name	Required	Description	Default
`data`	No
`error`	No
`metadata`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 23, 2026

changedInput schema / properties / history_limit / description

Previous value: -"Optional maximum number of recent annual, quarterly, and quarterly P/E history rows (1–30). Omit to preserve the existing compact response. Provider-reported EPS consensus is capped separately at three future fiscal years; it is not normalized and past revisions are unavailable."New value: +"Optional maximum number of recent annual/quarterly selected-metric rows and annual statement rows (1–30). Omit to preserve the existing compact response. Full annual statement rows retain source fields and currencies; missing source rows/provenance are reported, never filled. Current EPS consensus is capped separately at three future fiscal years; it is not normalized and past revisions are unavailable."

Changed1 schema field changedOct 23, 2026

addedInput schema / properties / history_limit

Added value: +{
+  "description": "Optional maximum number of recent annual, quarterly, and quarterly P/E history rows (1–30). Omit to preserve the existing compact response. Provider-reported EPS consensus is capped separately at three future fiscal years; it is not normalized and past revisions are unavailable.",
+  "maximum": 30,
+  "minimum": 1,
+  "type": "integer"
+}

First observedOct 15, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already cover readOnly, idempotent, openWorld and non-destructive, and the description adds real data-quality context beyond them: EPS is not normalized, past estimate revisions are unavailable, missing source rows are reported rather than filled, and selected metric trends are distinct from the full statement JSON. It stops short of stating response size, latency, or auth requirements.

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?

The use-when trigger is properly front-loaded, but the second sentence is an overstuffed run-on enumerating four separate response behaviors, and the 'EPS is not normalized and past estimate revisions are unavailable' clause is repeated verbatim-ish from the schema. Several clauses could be cut without loss.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values needn't be explained, and the description covers trigger conditions plus key data limitations (unnormalized EPS, no revisions, no backfill of missing rows). For a two-parameter read tool this is nearly complete; only sibling routing guidance is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50%: the ticker parameter is undocumented but self-evident from name and pattern, while history_limit already has a thorough schema description. The description's history_limit sentences largely restate the schema (30-period cap, three-year EPS consensus cap, non-normalized EPS) rather than adding meaning, so this sits at the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource (a stock's financial history, profitability, growth, balance-sheet evidence, business quality, data coverage) and frames it as a retrieval keyed to a ticker, which an agent can distinguish from get_stock_valuation or compare_stocks. It never states a clean verb like 'retrieve' and leans on the scenario framing, so it is clear but slightly indirect.

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 gives an explicit when-to-use trigger ('Use this when the user asks for a stock's ... financial history ...') and an explicit behavioral boundary ('Do not infer a trade instruction'). It does not name alternative siblings or say when not to use it, so routing to get_stock_valuation vs. this tool is left to inference.

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

All ValuEdge 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?