Real-time Stock MCP Service

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.2.1
Disambiguation4/5
Most tools target distinct aspects (real-time, K-line, financials, technicals, etc.), but some overlap exists among financial analysis tools (e.g., get_main_financial_data, get_financial_summary, get_financial_ratios) that might confuse an agent.
Naming Consistency5/5
All tools consistently use the 'get_' prefix followed by descriptive snake_case names (verb_noun pattern). No mixing of conventions or ambiguous names.
Tool Count4/5
34 tools is high but justified by the broad scope of stock data (real-time, history, fundamentals, technicals, plates). Could potentially consolidate a few, but overall reasonable for a comprehensive data service.
Completeness4/5
Covers most major data categories for stock analysis (search, quotes, K-line, financials, technical indicators, fund flow, plates, ratings). Minor gaps like missing options or bond data, but core needs are met.
Average 3.5/5 across 34 of 34 tools scored. Lowest: 2.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose any behavioral traits such as rate limits, data freshness, or potential side effects.
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?
The description is very short, with a one-line purpose and a code example. It is efficient but could be better structured with separate sections for purpose and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is simple (one parameter) and has an output schema, the description is still incomplete. It lacks explanation of what 'participation wish' means and how the data is obtained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides an example format for stock_code (e.g., '300750.SZ'), which adds some meaning beyond the type 'string'. However, it does not explain the code's structure or alternative formats.
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 states it retrieves individual stock participation willingness data. It is specific and clear, but does not differentiate from sibling tools beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. No context provided about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It states the output is a formatted Markdown table, implying a read operation, but does not explicitly confirm safety (e.g., no side effects) or disclose any authentication or rate-limiting requirements. The description lacks critical transparency for an agent.
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?
The description is short, with a purpose statement and return format, kept to one sentence in Chinese and one in English. It is front-loaded with the core action. The example is minimal but valid. Could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of parameters and presence of an output schema, the description should summarize the output content. It only specifies 'Markdown table format' without detailing columns or data types. This leaves the agent unaware of what the table contains, which is insufficient for a complete understanding.
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?
The tool has zero parameters and 100% schema coverage, so the baseline is 3. The description adds no parameter-specific meaning since none exist, but it does not detract from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '获取当日异动对数据对比情况' (get today's unusual change pair comparison), which indicates a specific verb and resource. However, the term '异动对' is ambiguous and not clearly defined, making it unclear whether this applies to stocks, plates, or other entities. It does not adequately distinguish from siblings like 'get_current_plate_changes' or 'get_intraday_changes'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or contextual hints about selecting this tool over its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states it returns text. It lacks disclosure of latency, rate limits, or any side effects, which would be needed for a minimally transparent description.
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?
The description is brief and structured with Args, Returns, and Examples sections, conveying necessary information without extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter and minimal output, the description covers the essential usage. However, it omits details like data freshness or limits, which could be useful given the output schema is not shown.
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 0%, but the description adds meaningful context by specifying the stock code format with exchange code and an example, significantly aiding parameter understanding beyond the bare schema.
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?
Description clearly states the tool retrieves the main business scope for a stock, with a specific verb and resource. It differentiates from siblings like get_business_review and get_main_business through the term 'scope'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides the required format for the stock code parameter, but no guidance on when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only states that it returns a Markdown table. It does not disclose behavior such as read-only nature, error handling, rate limits, or what happens with invalid stock codes. This is insufficient for a tool with no annotations.
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?
The description is concise with a clear structure: purpose, args, returns, and example. It is front-loaded with the Chinese phrase. However, it could be more structured with bullet points for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (not shown), the description need not detail return values, but it does mention a Markdown table. One parameter is adequately explained. However, it lacks context on data sources, update frequency, or error scenarios, making it minimally complete for a simple tool.
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 0% (no param descriptions in schema). The description explains the stock_code parameter format: '需要在数字后加上交易所代码，格式如300750.SZ' and provides an example. This adds significant meaning beyond the schema.
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 clearly states '获取成长性比较数据' which translates to 'get growth comparison data'. This specifies the verb and resource, and distinguishes it from sibling tools like get_valuation_comparison or get_industry_profit_comparison. However, it lacks detail on what exactly is compared (e.g., historical vs peer).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_valuation_comparison or get_financial_ratios. The agent has no context for selecting this tool over similar ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so weight falls on description. It only states it gets 'latest' info and returns a Markdown table, without disclosing read-only nature, potential delays, or market scope.
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 sentences with an example, efficiently conveying core purpose and output format. The example is slightly redundant due to zero parameters but not harmful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an output schema, the description is adequate but lacks specifics like which exchange's calendar, date formats, or whether historical data is included.
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?
Input schema has zero parameters with 100% coverage. The description adds value by stating the output is a Markdown table containing recent trading day info, which goes beyond the empty schema.
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 states it retrieves the latest trading calendar info including trading days and holidays, which clearly defines the verb and resource. The tool is distinct from siblings focusing on stock data or financial analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Only an example call is provided; no guidance on when to use this tool versus alternatives like get_current_count_changes or get_real_time_data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the return format (Markdown table) but fails to disclose behavioral traits such as read-only nature, authentication needs, rate limits, or error handling.
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?
The description is structured with Args, Returns, and Examples sections, making it easy to parse. It is concise without unnecessary fluff, though slightly verbose with docstring formatting.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic purpose and parameters, but lacks context for disambiguation from sibling tools, error scenarios, and limitations. Given the complexity (2 params, no annotations), it is adequate but not complete.
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 0%, but the description compensates by explaining each parameter: 'stock_code' with format example and 'page_size' with meaning and default. This adds meaning beyond the schema.
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 clearly states it retrieves historical billboard data for a specific stock, using a specific verb (获取). It provides parameter details and return format, but does not distinguish from the sibling tool 'get_billboard_data' which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'get_billboard_data'. The description explains what it does but not when it is appropriate or when to avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry full behavioral burden. It only states the purpose but does not disclose whether this is a read operation, any side effects, or how results are ordered. The example provides minimal behavioral hint.
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?
The description is extremely concise with one line and an example. It avoids unnecessary words, but could include a brief note on the output without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is an output schema (assumed to describe return structure), the description is minimally adequate. However, it lacks context on ranking criteria (e.g., what makes a stock 'top rated') and whether results are live or cached.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameter. It only indirectly shows usage via example but does not define what 'page_size' means or its expected range/format beyond the default.
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 clearly states the action ('get') and resource ('high-rated stocks across the entire market'). It distinguishes from siblings like 'get_smart_score_rank' which focuses on a specific score type, whereas this is about overall top-rated stocks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as 'get_smart_score_rank' or 'get_stock_search'. No prerequisites or contexts are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only states that it 'gets ranking data'. It does not disclose whether it is read-only, any rate limits, or what the output contains. Since the output schema exists, the burden is partially reduced, but the description adds no behavioral context beyond the basic function.
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 extremely concise: one line for purpose, one line for parameter format, and one example. It is well-structured and front-loads the key information. Every sentence is necessary and no word is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and an output schema exists, the description is minimally adequate. It covers how to call the tool but lacks context on why to use it, such as common use cases or differences from similar tools like 'get_smart_score'. The example helps but does not fully compensate for missing usage context.
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?
The schema for the single parameter 'stock_code' has no description (0% coverage). The description provides critical information: it explains the format (code with exchange suffix, e.g., '300750.SZ') and gives an example. This significantly improves the parameter's usability.
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 clearly states it retrieves smart score ranking data for a stock, using the Chinese phrase '获取个股智能评分排名数据'. However, it does not explicitly differentiate from the sibling tool 'get_smart_score', which might return the raw score rather than ranking, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as 'get_smart_score'. There is no mention of prerequisites, intended use cases, or situations where this tool is preferred. The example only shows a call without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It states the return format (Markdown table) but omits behavioral traits like data freshness, authentication, or side effects. It doesn't disclose that this is a read operation.
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?
Description is concise and well-structured with Args, Returns, and Examples sections. Every sentence adds value without redundancy.
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?
Given the tool's simplicity and presence of an output schema, the description is mostly complete. It explains the return format (Markdown table) but could elaborate on the exact fields returned.
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 has 0% description coverage. The description adds format for 'trade_date' (YYYY-MM-DD) and default value for 'page_size', providing meaningful context beyond the schema types.
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 clearly states the tool retrieves billboard data for a specified trading day, including basic info and fund flow. It uses a specific verb and resource, but doesn't differentiate from the sibling 'get_stock_billboard_data'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs. alternatives like 'get_stock_billboard_data'. Examples show typical usage, but no context for when-not-to-use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the tool returns a Markdown table, which is a useful behavioral detail. However, it does not disclose what the comparison is against (e.g., industry, peers) or any side effects. With no annotations, the description carries the transparency burden but only partially fulfills it.
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?
The description is brief and uses a structured docstring format with Args and Returns sections. It avoids unnecessary detail, but the format could be more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low schema coverage and the existence of an output schema, the description covers the basic purpose and parameter format. However, it lacks explanation of what the comparison data contains (e.g., components of DuPont analysis) and how it differs from related tools.
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?
The input schema has 0% coverage, but the description adds value by specifying the required format for stock_code (appending exchange code like .SH) and providing an example. This clarifies the parameter semantics beyond the schema.
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 clearly states the tool retrieves DuPont analysis comparison data, which is a specific financial analysis method. This distinguishes it from other sibling tools like 'get_financial_ratios' or 'get_growth_comparison', though it does not explicitly call out the differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only explains what it does, not the context or prerequisites for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It states the return type (Markdown table) and parameter formats, but does not disclose potential side effects, rate limits, error handling, or whether it is read-only. The behavioral disclosure is minimal.
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?
The description is structured with Args, Returns, and Examples sections, making it easy to parse. It is concise without unnecessary details, though it could be slightly more succinct in language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters and no output schema (though described as Markdown table), the description is adequate for basic usage. However, it lacks details on return structure, error scenarios, and data scope, making it only moderately complete.
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?
The input schema has 0% description coverage, but the description adds meaning: stock_code is 'stock code, digits only', begin_time and end_time specify format examples. This goes beyond the schema's titles, aiding correct invocation.
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 name and description clearly state the tool retrieves institutional rating data. The description includes parameters and an example, making the purpose unambiguous. However, it does not explicitly differentiate from sibling tools like 'get_business_review' or 'get_valuation_analysis', which might also provide financial data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. It only describes the tool's function without context about its applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, error handling, rate limits, or authentication needs. The tool likely performs a read operation, but this is not explicitly stated.
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 extremely concise: a one-line purpose, a parameter explanation, and an example. Every sentence is necessary, and there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and an output schema (not shown), the description is minimally adequate. It explains how to call the tool but does not describe the return value or behavior on errors, leaving some gaps.
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?
The schema has 0% description coverage, but the description adds meaning by specifying the stock_code format and providing an example. This partially compensates for the schema gap, though it does not cover all aspects.
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 clearly states the tool retrieves individual stock main force control data (获取个股主力控盘数据), which is a specific verb+resource. However, it does not distinguish itself from siblings like get_main_financial_data or get_market_performance.
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 provides a format requirement for stock_code (suffix like .SZ) and a usage example. However, it lacks guidance on when to use this tool over alternatives and no exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It states the output is formatted as a Markdown table, which is helpful, but it does not disclose if the operation is read-only, requires authentication, or has rate limits. It adequately conveys the return format but lacks completeness on traits like side effects or prerequisites.
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?
The description is relatively concise, with a clear sentence explaining the tool, followed by structured Args, Returns, and Examples sections. However, it mixes Chinese and English (first line in Chinese, rest in English), which may reduce clarity. Overall, it is efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with an output schema, the description covers the core purpose, parameter meanings, and return format. It lacks usage guidelines and fails to mention error handling or edge cases, but given the existence of an output schema and the tool's simplicity, it is adequately complete.
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?
The description adds significant meaning beyond the input schema, which has 0% coverage. It explains that plate_type takes values 1, 2, 3 corresponding to regional, industry (default), and concept plates, and page_size defaults to 10. Examples further clarify usage. This fully compensates for the schema's lack of descriptions.
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 clearly states the tool retrieves top N plate market data by percentage change from East Money Network, specifying plate types like industry, concept, and regional. It is specific about the resource and verb, though it does not explicitly differentiate from siblings like 'get_plate_fund_flow' or 'get_current_plate_changes', but the context of '涨跌幅前N' (top N by change) provides implicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. The description gives parameter examples but does not mention scenarios, prerequisites, or comparisons to sibling tools like get_billboard_data or get_plate_fund_flow. The agent must infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must handle behavioral disclosure. It mentions the return format (Markdown table), which adds some transparency, but does not discuss side effects, authorization, or error behavior.
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?
The description is compact with clear sections (main, Args, Returns, Examples). No extraneous information, though it repeats parameter names from the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description explains the return format (Markdown table). For a simple two-parameter tool, it covers the basics but lacks details on date format and error handling.
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?
The input schema has no descriptions (0% schema description coverage), so the description's 'Args' section adds basic meaning by labeling parameters as 'begin_time' and 'end_time' with short descriptions. However, it does not specify expected date format or constraints.
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 clearly states it retrieves macroeconomic research data (verb+resource). However, it does not differentiate from many sibling tools that also 'get' data, so it lacks sibling distinction.
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 provides a recommendation to use the latest dates ('推荐填入最新的日期以紧跟时事'), but no explicit context on when to use this tool versus alternatives, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states the return format (Markdown table) but omits details like side effects, data freshness, or authentication needs. As a read operation, basic safety is implied but not explicit.
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?
The description is concise, with a clear Args/Returns/Examples structure. It is mostly front-loaded but mixes English and Chinese; the information density is high without being verbose.
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?
Given one simple parameter, the description adequately covers the required input format and output type (Markdown table). The presence of an output schema reduces the need to detail return fields, making it complete for its simplicity.
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?
The input schema has 0% description coverage, but the description adds critical meaning by specifying the stock_code format (e.g., '600000.SH' with exchange suffix). This compensates for the schema's lack of detail.
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 clearly states it retrieves valuation comparison data for a stock, using a specific stock code format. It distinguishes from other tools like get_valuation_analysis primarily by the comparison aspect, but does not explicitly differentiate from siblings.
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 provides a code format requirement for the parameter, implying usage context. However, it offers no guidance on when to choose this tool over alternatives like get_valuation_analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the return format (Markdown table) and provides an example call. However, it does not disclose whether the operation is read-only, any error conditions, or authentication requirements. With no annotations, more behavioral detail would be beneficial.
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 very concise with clear sections (Args, Returns, Examples). Every sentence is informative without redundancy. It is well-structured and easy to parse.
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?
Given the simple one-parameter input and stated output schema (Markdown table), the description adequately covers usage. However, it lacks detail on what constitutes 'main financial data', which might be ambiguous given the many sibling tools.
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?
The description adds significant value beyond the schema: it specifies the required format (stock code with exchange suffix) and gives an example ('300750.SZ'). This compensates for the 0% schema description coverage.
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 clearly states '获取公司主要财务数据' (get main financial data), indicating the verb and resource. It provides an example showing the expected format. However, it does not explicitly differentiate from sibling tools like get_financial_ratios or get_financial_summary, which cover specific aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description only shows an example call, but lacks context such as when to prefer this over other financial data tools among the many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It states the return format (Markdown table) but omits details such as data freshness, error handling, authentication needs, or whether the operation has side effects. For a read operation, basic safety is implied but not stated.
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?
The description is fairly concise with a short sentence plus structured Args/Returns/Examples sections. It avoids unnecessary details, though the example could be integrated into the text. The structure aids readability.
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 simple tool with one parameter and an output schema, the description provides essential context: purpose, return format, and parameter format. However, it lacks details on edge cases, error messages, or data freshness. Given the low complexity, it is mostly complete.
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?
The schema has 0% parameter descriptions, but the description adds crucial format guidance: '股票代码，数字后带上交易所代码，格式如688041.SH'. This clarifies the exact expected input format beyond the schema's bare type string.
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 clearly states the verb '获取' (get) and resource '实时股票数据' (real-time stock data), specifying key fields like price, change, and volume. It distinguishes from siblings such as get_kline (historical) and get_market_performance (broader).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The example shows a usage pattern, but there is no mention of prerequisites, exclusions, or contexts where other tools would be preferred. With many siblings, this lack of guidance may lead to confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must compensate but only states it returns a Markdown table. It does not disclose that this is a safe read operation, any rate limits, data freshness, or potential errors. Missing key behavioral traits.
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?
Description is short, well-structured with Args and Returns sections, and includes an example. Every sentence adds value with no redundancy. Front-loads the core purpose.
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?
Given the presence of an output schema, the description adequately covers purpose, parameter format, and return format. However, it lacks context on what constitutes an 'abnormal fluctuation' or any edge cases, but these are minor omissions.
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?
Despite 0% schema coverage, the description adds necessary meaning for the stock_code parameter by specifying the required format (e.g., 300750.SZ) and providing an example. This significantly clarifies usage beyond the bare 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?
Description clearly states the tool retrieves intraday chart order book anomaly data, including important trading events and abnormal fluctuations. This is a specific verb+resource combination that distinguishes it from sibling tools like get_kline or get_real_time_data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description lacks context about appropriate scenarios, prerequisites, or when to choose this over similar tools like get_market_performance or get_kline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully convey behavioral traits. It mentions the return format (Markdown table) but does not address read-only nature, potential side effects, authentication, rate limits, or error behavior.
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 with clear sections: purpose, Args, Returns, Example. No superfluous text; every sentence adds value.
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?
Given the presence of an output schema (context signal), the description does not need to detail return values. It covers the parameter requirement and outcome sufficiently for a simple tool, though edge cases or errors are not mentioned.
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 0%, and the description significantly enriches the parameter stock_code by specifying the format (数字后加上交易所代码，如300750.SZ). This adds critical meaning beyond the bare schema title.
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 explicitly states '获取主营构成分析' (Get main business composition analysis), clearly indicating the tool's purpose. It is distinct from sibling tools like get_business_review or get_financial_ratios, which cover different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description provides an example and format requirements but does not specify conditions for use or exclude inappropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states '获取' (get), implying a read operation, but lacks details on side effects, authentication needs, or whether it is read-only. The description adds minimal behavioral context beyond the name.
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, with a clear purpose followed by structured Args and Examples. Every sentence is meaningful and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not explain return values. However, the lack of behavioral transparency and usage guidelines makes the description less complete for a tool with no annotations. The parameter explanation is thorough, but other aspects are missing.
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?
The input schema has 0% description coverage, but the description fully explains the parameter 'stock_code' with the format required (add exchange code like 300750.SZ) and provides an example. This greatly adds meaning beyond the bare schema.
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 clearly states it '获取股票智能评分数据' (gets stock smart score data), specifying the resource and action. The sibling tool 'get_smart_score_rank' suggests differentiation, but the description does not explicitly contrast with siblings.
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 provides an example and explains the parameter format (adding exchange code), but does not specify when to use this tool versus alternatives like 'get_smart_score_rank' or other data retrieval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states the return format (Markdown table) and default page_size, but omits data freshness, rate limits, or any side effects. Given the lack of annotations, this is insufficient for full transparency.
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?
The description is concise and well-structured with Args, Returns, and Examples sections. It is not overly verbose, but some sentences could be streamlined. The example is helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present (not shown), the description does not need to detail return values. However, it lacks information on error handling, data range, or limitations. Given the tool's two parameters and output schema, it is moderately complete but could benefit from more context.
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 description coverage is 0%, so the description must compensate. It explains the stock_code format (e.g., '300750.SZ') and the default value for page_size (30). However, it does not clarify the meaning of page_size beyond '返回数据条数', which is partially addressed. Overall, it adds significant value over the bare 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?
The description clearly states that the tool retrieves technical indicator data (MACD, KDJ, RSI, BOLL) for a stock, with a specific verb '获取' and resource '技术指标数据'. It distinguishes itself from sibling tools by its unique function; no other sibling focuses on technical indicators.
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 provides usage via Args and Examples, but lacks explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites or when not to use it, relying on implied usage from the example.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only states it returns business review text, with no disclosure of side effects, auth needs, or rate limits. Basic read-only nature is implied but not explicit.
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 extremely concise, with a clear structure including Args, Returns, and Examples. Every sentence provides value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an output schema exists (though not shown). The description covers the basic purpose and parameter format, but lacks usage guidelines and behavioral transparency, leaving some gaps for a complete understanding.
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?
The only parameter, stock_code, is not described in the schema (0% coverage). The description adds crucial format details (must include exchange suffix like .SZ or .SH) and an example, greatly enhancing understanding beyond 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?
The description clearly states the tool retrieves a business review (获取经营评述) for a given stock code. It uses a specific verb and resource, and is distinct from sibling tools which cover different financial data.
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 specifies the required stock code format and provides an example, but does not explicitly state when to use this tool versus alternatives. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as data freshness, authentication requirements, or side effects. It only states the tool retrieves data, which is implied by the name. For a read-only tool, this is minimally transparent.
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 with a clear purpose, Args, Returns, and Examples sections. Every sentence adds value, and it is front-loaded with the main functionality. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (Markdown table), the description does not need to detail return values. However, it only vaguely mentions key indicators without listing which ratios. For a tool with many siblings, more specificity about included ratios would improve completeness.
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?
The input schema has one parameter with no description (0% coverage). The description adds meaningful format guidance: 'add exchange code after the number, format like 300750.SZ'. This compensates for the schema gap, though it could specify allowed exchange codes.
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 clearly states the tool retrieves financial ratio data for a specified stock, listing specific categories like profitability and solvency. This verb+resource pair is distinct from siblings like 'get_financial_summary' or 'get_main_financial_data'.
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 provides basic usage with argument format and example, but does not explicitly guide when to use this tool versus its many siblings. Usage is implied by the tool name and description, but no exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
描述声明返回Markdown表格，隐含为只读操作，但未明确说明无副作用。由于注释未提供，描述承担披露责任，但未提及数据延迟、分页、错误处理等行为。不过对于简单查询工具，基本足够。
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?
描述包含目的、参数说明、返回值格式和示例，结构完整，信息密度适当，没有冗余。但篇幅略长，可进一步精简。
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?
工具只有一个参数且功能明确，描述涵盖了核心用途和参数格式，输出模式存在但未提供内容，描述说明了返回Markdown表格，基本满足使用需求。
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?
输入模式只有一个stock_code参数且描述覆盖率为0%，描述补充了股票代码格式示例（如688041.SH），增加了语义价值，帮助理解参数格式要求。
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?
描述明确说明了工具获取指定股票的股东户数数据，包括历史各期的股东人数及收盘价，动词'获取'清晰定义了操作，资源'股东户数数据'具体，与兄弟工具中其他金融指标区分明显。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
描述没有提供何时使用此工具 vs 其他兄弟工具的指导，也没有说明排除条件或先决条件，例如是否需要特定权限或数据范围。仅给出了基本功能描述，缺乏使用上下文。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that data is for the current day, sorted descending, and returns a Markdown table. However, it does not mention side effects, authorization needs, rate limits, or error handling, leaving gaps in behavioral transparency.
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 with one clear sentence for purpose, followed by structured sections for Args, Returns, and Examples. No redundant information, and the length is appropriate for the tool's simplicity.
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?
Given the tool has one optional parameter and an output schema exists, the description covers key aspects: purpose, parameter, return format (Markdown table), ordering, and examples. It lacks error handling details but is complete enough for a simple data retrieval tool.
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?
The description adds meaning to the 'page_size' parameter beyond the schema by explaining it controls the number of returned entries (默认10条). Schema has no description field for the parameter, so the description compensates effectively.
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 clearly states the tool retrieves current-day plate changes data, including rise/fall percentages, main capital flow, and abnormal stocks, sorted by total abnormal count descending. It specifies the verb '获取' and resource '板块异动数据', distinguishing it from sibling tools like get_plate_fund_flow or get_plate_quotation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It does not mention when to avoid it or provide comparisons with sibling tools like get_plate_fund_flow. The usage context is implied but not clearly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the output format (Markdown table) but omits behavioral traits like data freshness, any access restrictions, or whether it requires market hours. Middle ground given lack of annotation support.
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?
Two concise sentences covering purpose and output format, plus a clear example. Every sentence adds value; no waste.
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?
Despite lacking details like required market status or data latency, the description is sufficient for a parameterless tool with output schema. Could be improved with usage context, but adequate.
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?
Input schema has zero parameters (coverage 100% trivial). Baseline for zero parameters is 4; description does not need to elaborate on parameters, and it correctly omits such.
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 clearly states it retrieves real-time market index data, listing specific indices (Shanghai Composite, Shenzhen Component, ChiNext) and mentions output format. This definitively distinguishes it from sibling tools like get_real_time_data which might be broader.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_real_time_data or other index-related tools. Lacks when/when-not or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds behavioral context by stating it returns a Markdown table and implies a read-only operation. However, it does not disclose potential side effects, authorization needs, or rate limits, limiting transparency.
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?
The description is well-structured with a clear purpose sentence, Args/Returns sections, and examples. It is comprehensive but slightly verbose; could be trimmed by merging the first sentence with Returns.
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?
Given that an output schema exists (true), the description adequately covers parameters and purpose with examples. It lacks detail on output structure beyond 'Markdown table', but the listed metrics partially compensate.
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?
The description fully compensates for 0% schema coverage by explaining both parameters: stock_code format (e.g., '300750.SZ') and date_type options (1-4 years). This provides meaning beyond the bare 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?
The description clearly states it retrieves all valuation analysis data for a stock, listing specific metrics (PE, PB, PS, PC) with current values and historical percentiles. This specific verb-resource description distinguishes it from sibling tools that cover other financial data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus siblings like 'get_valuation_comparison' or 'get_main_financial_data'. It only describes its own functionality, leaving the agent to infer appropriateness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden for behavioral transparency. It states the return format (Markdown table) but does not disclose read-only nature, authentication needs, rate limits, or potential side effects. Given the absence of annotations, the disclosure is minimal.
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 well-structured with separate sections for summary, Args, Returns, and Examples. Each sentence earns its place; there is no repetition or extraneous information. It is appropriately sized for the tool's complexity.
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?
Given the tool's two parameters and return format, the description is largely complete. It covers parameter semantics, return type, and provides examples. However, it could further specify the range of financial indicators returned or clarify the expected use case (e.g., historical analysis). The presence of an output schema (not detailed) reduces the need for return value explanation.
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 fully compensates by explaining stock_code format (including example '688041.SH') and providing a clear mapping for date_type_code values (001-004 with their meanings). This adds significant meaning beyond the bare 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?
The description clearly states the tool retrieves financial summary data for a specified stock, including historical operating revenue and net profit. It uses a specific verb (获取) and resource (业绩概况数据), and distinguishes from sibling tools like get_main_financial_data and get_financial_ratios which focus on different financial aspects.
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 includes parameter details and examples, but does not explicitly state when to use this tool versus alternatives or when not to use it. Usage is implied through the parameter and return description, but no explicit context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the return format (Markdown table) and data types but does not mention side effects, rate limits, auth requirements, or data freshness. It is adequate but lacks depth such as data source or update frequency.
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 well-structured with a clear main description, Args, Returns, and Examples sections. It is concise, using only essential information without redundancy, and each sentence adds value.
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 data retrieval tool with 2 parameters and no annotations, the description covers input, output format, and examples. It lacks details on valid market codes, data history length, and error handling, but it is mostly sufficient for an agent to invoke correctly.
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?
Despite 0% schema coverage, the description's Args section explains both parameters: stock_code format (e.g., 688041.SH) and limit's default and meaning (number of records). This adds significant value beyond the raw schema, though it could specify constraints like valid markets for stock_code.
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 clearly states it retrieves historical fund flow data for a specified stock, including types of funds (main, retail, medium). It uses specific verb '获取' and resource '指定股票最近N个交易日的资金流向数据', distinguishing it from sibling tools like get_plate_fund_flow which is for sector data.
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 for stock-level historical fund flow but does not explicitly state when to use this tool versus alternatives like get_plate_fund_flow. No exclusions or alternative suggestions are provided, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It describes the function as fetching data and returning a Markdown table, which implies a read-only operation. However, it does not explicitly state that it is read-only or disclose any potential side effects.
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, with sections for Args, Returns, and Examples. Every sentence is informative without redundancy. The structure is front-loaded with the purpose.
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?
The description covers the tool's purpose, input format, and output type (Markdown table). Given the single parameter and the presence of an output schema (though not shown), it is fairly complete. However, it lacks context about limitations or performance considerations.
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?
Although schema coverage is 0%, the description adds meaning by specifying the stock_code format with an exchange suffix (e.g., '688041.SH'), which is not present in the schema's type definition. This helps the agent construct valid inputs.
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 clearly states it retrieves peer profit comparison data for a given stock, including basic financial and profitability indicators. This distinguishes it from siblings like get_valuation_comparison or get_growth_comparison.
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 it is for industry profit comparison but does not provide explicit guidance on when to use this tool versus alternatives like get_financial_ratios or get_growth_comparison. An example is given, but no when-not-to-use advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 that output is formatted as a Markdown table, but does not mention data freshness, limitations, or auth requirements. For a read-only tool, this is adequate but not thorough.
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 extremely concise with a clear purpose, structured Args/Returns/Examples sections, and no superfluous content. Every sentence serves a purpose.
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?
Given the tool's simplicity (one parameter, read-only, output schema present), the description covers the core functionality. It does not elaborate on edge cases or error handling, but for a straightforward data retrieval tool this is sufficient.
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?
The input schema has 0% description coverage, so the description adds essential meaning by explaining the parameter as '股票代码，包含交易所代码，如 300750.SZ'. This clarifies the format beyond the schema's bare title.
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 clearly states the tool retrieves stock market performance data including comparisons with the broader market and industry sectors. It uses a specific verb ('获取') and resource ('市场表现数据'), and distinguishes itself from siblings like get_real_time_data or get_kline by emphasizing comparison aspects.
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 provides an example and parameter details but does not explicitly specify when to use this tool over alternatives or its prerequisites. The context signals show many similar get_ tools, but no guidance is given on selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the return format (Markdown table) and parameter effects, but does not mention side effects (e.g., mutability), authentication requirements, rate limits, or error behavior. Basic behavioral traits are covered, but depth is lacking.
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?
The description is well-structured with Args, Returns, and Examples sections. It is moderately concise but includes slight redundancy (Chinese/English mix). Each section serves a purpose, though some lines could be trimmed. Overall efficient.
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?
Given the tool has only two optional parameters and an output schema (handling return format), the description is fairly complete: it covers purpose, parameters, return format, and examples. Missing: error handling, possible limitations (e.g., requires market open), but acceptable for this complexity.
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 fully explains both parameters: plate_type values (1,2,3) and page_size default (10). Examples illustrate usage with different parameter combinations. This adds substantial value beyond the schema's bare defaults.
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 clearly states the tool retrieves today's ranking of plate fund flow, covering industry, concept, region sectors. It uses a specific verb (获取/get) and resource (板块资金流排行), and the examples further clarify usage. It is distinct from sibling tools like get_historical_fund_flow or get_current_plate_changes.
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 the tool is for today's fund flow ranking (今日排行) but does not explicitly state when to use this vs. alternatives (e.g., get_historical_fund_flow for history). No exclusion criteria or prerequisites are mentioned. The examples show typical calls but no guidance on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must cover behavior. It mentions returns are in Markdown format and gives examples, but does not explain rate limits, authentication needs, or potential side effects. Basic transparency is present but incomplete.
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, with clear sections: purpose, arguments, returns, and examples. No extraneous text, well-structured and front-loaded.
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?
The tool has an output schema (not shown), so return details are not required. With one parameter and examples, the description covers the main use cases. However, missing behavioral info like rate limits or data freshness prevents a perfect score.
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?
Input schema has 0% description coverage for the keyword parameter. The description explains that keyword can be a stock code or name, adding meaning beyond the schema's type string. This compensates well for the lack of schema descriptions.
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 clearly states the tool searches for stock information by keyword, with fuzzy search support. It specifies outputs like stock code, name, and market type. This distinguishes it from sibling tools which focus on financial analysis, bills, etc.
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 for finding stocks by keyword, but does not explicitly state when to use vs. alternatives, nor any prerequisites or when to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 explains input format, supported markets, and return type (Markdown table). However, it does not disclose behavioral traits like data frequency limitations, rate limits, or data update frequency.
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 well-structured with sections for Args, Returns, and Examples. It is concise, front-loading the purpose, and every sentence provides value without redundancy.
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?
Given the tool has 4 parameters, no annotations, and an output schema, the description covers inputs comprehensively and explains the return format. It lacks details on edge cases or limitations, but the examples and parameter descriptions make it functionally complete.
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 coverage is 0%, and the description adds essential semantics: stock_code format (e.g., 300750.SZ), date format (YYYY-MM-DD), frequency options (d, w, m, 5, 15, 30, 60), and examples. This far exceeds the schema's minimal type information.
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 clearly states the tool's function: retrieving K-line data for stocks in a specified date range, supporting A-shares, B-shares, H-shares, and market indices. This distinguishes it from sibling tools that focus on other financial data types.
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?
The description implicitly defines usage for obtaining historical price data through parameter and example details. It lacks explicit guidance on when not to use or alternatives, but the tool's specific purpose and sibling context make it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![real-time-stock-mcp-service MCP server](https://glama.ai/mcp/servers/DannyWongIsAvailable/real-time-stock-mcp-service/badges/card.svg)](https://glama.ai/mcp/servers/DannyWongIsAvailable/real-time-stock-mcp-service)

Score Badge

Copy to your README.md:

[![real-time-stock-mcp-service MCP server](https://glama.ai/mcp/servers/DannyWongIsAvailable/real-time-stock-mcp-service/badges/score.svg)](https://glama.ai/mcp/servers/DannyWongIsAvailable/real-time-stock-mcp-service)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/DannyWongIsAvailable/real-time-stock-mcp-service'

If you have feedback or need assistance with the MCP directory API, please join our Discord server