Yahoo Finance MCP Server

Market status

get_market

Read-only

Check a market's trading status and headline index summary using a Yahoo market key like US or EUROPE; status includes next open and close for US, with index moves for all keys.

Instructions

Get the trading status and headline index summary for a market.

Answers questions like whether the market is open, when it opens or closes next, and how the major indices are doing. Takes a market key such as US or EUROPE — not a ticker symbol. status (open/closed plus the next open and close times) is only available for US and is null for every other key, which is an upstream limitation rather than an error. The index summary, with price, previous close and change, works for all keys.

Input Schema

Name	Required	Description	Default
`key`	No	A Yahoo market key (uppercase). One of: US, GB, ASIA, EUROPE, RATES, COMMODITIES, CURRENCIES, CRYPTOCURRENCIES. Only 'US' reports a trading status, the others return the index summary with 'status' set to null.	US

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.8.6Oct 17, 2026
- removedInput schema / properties / key / title
```
Removed value: -"Key"
```
- removedInput schema / title
```
Removed value: -"get_marketArguments"
```
- removedOutput schema / title
```
Removed value: -"get_marketDictOutput"
```
Addedv0.4.0Aug 18, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations cover only read-only/open-world safety, and the description adds a genuinely valuable behavioral disclosure: `status` is populated only for `US` and is null elsewhere, explicitly framed as an upstream limitation rather than an error. That pre-empts an agent misreading a null as a failure — exactly the kind of context annotations cannot carry.

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 in one sentence, then qualifies input semantics and the US-only status caveat. Every sentence earns its place, though the prose runs slightly longer than a single-parameter tool strictly needs.

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?

With an output schema present, return-shape detail is not required, yet the description still sketches what the index summary contains (price, previous close, change) and covers the one edge case an agent would otherwise trip on. Nothing needed to call it correctly is missing.

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% and the key enum is documented there, but the description still adds meaning: it reinforces that `key` is a market key rather than a ticker, gives concrete examples (`US`, `EUROPE`), and ties the parameter to the null-status behavior. Marginal but real value above the schema.

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 and resource ('Get the trading status and headline index summary for a market') and immediately scopes it apart from ticker-oriented siblings by noting it takes a market key 'such as `US` or `EUROPE` — not a ticker symbol'. An agent can distinguish this from get_quote/get_quotes without opening any schema.

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?

Enumerates the questions it answers — market open, next open/close, index performance — which gives clear context for when to reach for it. It does not name an explicit alternative tool to prefer when the agent wants per-symbol data, so it stops short of full when/when-not routing.

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