Yahoo Finance MCP Server

Search instruments

search

Read-only

Resolve company names, tickers, or ISINs to Yahoo Finance symbols and instrument details so other tools can retrieve quotes, history, and financials.

Instructions

Search Yahoo Finance by company name, ticker symbol, or ISIN.

Use this to turn a company name into a Yahoo symbol that the other tools accept. They take an ISIN directly. Returns up to limit matches (1-25), each with its symbol, name, exchange, instrument type, sector and industry.

Input Schema

Name	Required	Description	Default
`limit`	No	Maximum number of matches to return.
`query`	Yes	Company name, ticker symbol, or ISIN to look up.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.8.6Oct 17, 2026
- removedInput schema / properties / limit / title
```
Removed value: -"Limit"
```
- removedInput schema / properties / query / title
```
Removed value: -"Query"
```
- removedInput schema / title
```
Removed value: -"searchArguments"
```
- removedOutput schema / properties / result / title
```
Removed value: -"Result"
```
- removedOutput schema / title
```
Removed value: -"searchOutput"
```
First observedv0.2.2Aug 2, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations cover safety (readOnlyHint, openWorldHint), so the bar is lower; the description adds the bounded result window (1-25), the default-capped count, and the exact fields returned, which the annotations do not convey.

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, then the routing advice, then the return shape, in four short sentences with little waste, though the field list slightly overlaps the output schema.

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 purpose, routing, input types, result bounds, and returned fields; since an output schema exists, no further return-value detail is required for an agent to call it correctly.

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 100% and both params are described, including the limit's 1-25 range; the description restates rather than extends this, so baseline 3 applies.

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 (Search) and resource (Yahoo Finance) plus accepted input types, and distinguishes itself from all sibling get_* tools by framing itself as the symbol-resolution entry point.

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?

Explicitly states when to use it (turn a company name into a Yahoo symbol) and names an alternative path (other tools take an ISIN directly), giving the agent clear routing guidance.

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