Skip to main content
Glama
Sign In
finsage

finsage

by MikeWang1994
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

screen_stocks

Screens A-share stocks based on natural language criteria, returning a score-ranked list of candidate stocks.

Instructions

按自然语言条件筛选 A 股标的，返回按得分排序的候选清单。

Args: query: 自然语言筛选条件，例如「低估值且高 ROE 的白酒股」。 top_n: 返回前 N 只，默认 10，范围 1-50。

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "screen_stocks"
  }
}

Input Schema

NameRequiredDescriptionDefault
queryYes
top_nNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/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 does disclose a key behavioral trait—returns a score-sorted candidate list—and describes the top_n range. However, it does not explicitly state that the operation is read-only, what happens on invalid queries, or any rate/result limits beyond top_n.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: a single front-loaded purpose sentence followed by a clean Args list. No wasted words, and every sentence adds value.

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?

For a simple 2-parameter tool with no output schema, the description is complete: it covers the query semantics, top_n behavior, and the return format (scored candidate list). No critical gaps for the intended use case.

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

Parameters5/5

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

Schema description coverage is 0%, but the description's Args section fully compensates. It explains query with a concrete example ('低估值且高 ROE 的白酒股') and defines top_n's default and range (1-50). This goes beyond the bare schema types.

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?

The description states a specific verb ('筛选' / screen), a specific resource ('A 股标的' / A-share stocks), and a concrete output ('返回按得分排序的候选清单' / returns a candidate list sorted by score). This clearly distinguishes it from siblings like analyze_stock and compare_stocks, which perform different operations.

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?

The description implies usage: use when you want to filter stocks by natural language criteria. However, it provides no explicit when-to-use, when-not-to-use, or exclusions relative to the sibling tools. There is no mention of alternatives or complementary tools, so the guidance is only implicit.

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