Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

yahoo_finance_screener_custom

Screen equities, ETFs, or mutual funds with custom JSON criteria using AND/OR operators; sort and paginate results to return matching quotes and totals.

Instructions

Yahoo Finance custom screener. Runs a custom Yahoo Finance screen from a JSON body. query is a tree of operator and operands: combine conditions with AND or OR, and compare a field to a value with operators such as EQ or GT. Screen equities (default), ETFs or mutual funds with quote_type, and page and sort with count, offset, sort_field and sort_asc. Returns the matching quotes and the total.

Input Schema

NameRequiredDescriptionDefault
requestYesJSON body for a custom screen. The query field is required; quote_type, count, offset, sort_field, and sort_asc are optional.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv1.17.14
    • changedInput schema / properties / request / description
      Previous value: -"Custom screener request"New value: +"JSON body for a custom screen. The query field is required; quote_type, count, offset, sort_field, and sort_asc are optional."
    • addedInput schema / properties / request / properties / count / description
      Added value: +"Count is the maximum number of matching quotes to return (default 25, maximum 250)."
    • addedInput schema / properties / request / properties / offset / description
      Added value: +"Offset is the zero-based index of the first matching quote (default 0, maximum 10000)."
    • addedInput schema / properties / request / properties / query / description
      Added value: +"Query is required and contains Yahoo's recursive criteria tree. Combine conditions with AND or OR; leaves use an operator such as EQ or GT with operands [field, value], for example {operator: GT, operands: [dayvolume, 1000000]}. Accepted fields depend on quote_type."
    • addedInput schema / properties / request / properties / quote_type / description
      Added value: +"QuoteType selects the instrument class to screen. Allowed values are EQUITY (default), ETF, and MUTUALFUND."
    • addedInput schema / properties / request / properties / sort_asc / description
      Added value: +"SortAsc sorts in ascending order when true; the default is descending."
    • addedInput schema / properties / request / properties / sort_field / description
      Added value: +"SortField selects the quote field used to order results, such as ticker or marketcap (default ticker)."
  2. Changed2 schema fields changedv1.17.5
    • addedInput schema / properties / request / properties
      Added value: +{
+  "count": {
+    "type": "integer"
+  },
+  "offset": {
+    "type": "integer"
+  },
+  "query": {
+    "additionalProperties": {},
+    "type": "object"
+  },
+  "quote_type": {
+    "type": "string"
+  },
+  "sort_asc": {
+    "type": "boolean"
+  },
+  "sort_field": {
+    "type": "string"
+  }
+}
    • addedInput schema / properties / request / required
      Added value: +[
+  "query"
+]
  3. First observedv1.0.0

TDQS

A3.5/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses the return shape ('matching quotes and the total'), the query-tree mechanics, and pagination/sort controls, which is useful. However it omits auth needs, rate limits, and the field vocabulary caveat only found in the schema.

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-loaded with the core purpose, then the query mechanics, then screening options and return value. Every sentence carries information with no obvious padding, though it is somewhat dense.

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 nested-JSON query tool with no output schema, the description covers the query-tree structure, instrument selection, pagination, sorting, and return shape. It is close to complete, missing only auth/limits context.

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 description coverage is 100%, so the schema already documents count, offset, sort_field, sort_asc, and quote_type. The description restates the query tree with AND/OR and EQ/GT examples, adding mild clarity but largely mirroring the schema's own query description. Baseline 3 is appropriate.

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?

States a specific verb+resource: 'Runs a custom Yahoo Finance screen from a JSON body.' The 'custom' qualifier implicitly separates it from the predefined screener siblings, and it names the input shape (JSON body with a query tree). It stops short of explicitly contrasting with yahoo_finance_screener, so a 4 rather than 5.

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 conveys what can be screened (equities/ETFs/mutual funds) and how to page/sort, which implies usage, but gives no explicit when-to-use-this-vs-alternatives guidance against siblings like yahoo_finance_screener or yahoo_finance_screeners. Usage 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.

Deploy Server

Other Tools