Skip to main content
Glama

yahoo_finance_screener_custom

Read-only

Run Yahoo Finance’s custom equity, ETF, or mutual-fund screener with a required recursive query tree. Use AND/OR to combine conditions and leaves such as GT or EQ over a field and value; results contain matching quote rows, with quote_type, count, offset, and sort inputs controlling class, paging, and order.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "yahoo_finance_screener_custom"
  }
}

Input Schema

NameRequiredDescriptionDefault
countNoMax results to return, default 25, max 250.
queryNoRequired recursive Yahoo screener criteria tree. Combine conditions with operator AND or OR; each leaf uses an operator such as EQ or GT and operands [field, value], e.g. {operator: AND, operands: [{operator: GT, operands: [dayvolume, 1000000]}]}. The accepted fields depend on quote_type.
offsetNoZero-based offset of the first result, default 0, max 10000.
sort_ascNoSort ascending when true, descending when false. Default false (descending).
quote_typeNoInstrument type to screen. Allowed values: EQUITY, ETF, MUTUALFUND. Default EQUITY.
sort_fieldNoField to sort results by, e.g. ticker or marketcap. Default ticker.

Output Schema

NameRequiredDescriptionDefault
dataYesThe tool result payload (shape varies per tool; see each tool's docs resource).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered without description help. The description adds that results contain matching quote rows and that the query tree is required and recursive, but does not discuss rate limits, sort/paging side effects, or error behavior beyond that.

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?

Two dense sentences, front-loaded with the purpose and then the mechanics; little waste. It could be slightly tighter, but the query-tree explanation earns its space.

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?

For a complex nested-query screener with a full output schema and read-only annotations, the description covers the essential call mechanics (required recursive query, operators, control params). Return-value details are correctly omitted since an output schema exists.

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?

With schema coverage at 100%, the baseline is 3, but the description genuinely adds meaning: it explains the AND/OR recursive composition, leaf operators (GT, EQ) over field/value pairs, and that quote_type/count/offset/sort control class, paging, and order. That maps the flat parameters to a coherent mental model of the query tree.

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 a specific verb (Run) and resource (Yahoo Finance custom equity/ETF/mutual-fund screener), and the word 'custom' implies the contrast with the predefined screener siblings. However, it never explicitly names yahoo_finance_screener or yahoo_finance_screeners, so the agent must infer the routing from the name alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the query tree is required, which is a prerequisite, but gives no explicit when-to-use/when-not or alternative-tool guidance relative to the sibling screener tools. Usage is implied rather than spelled out.

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.