Xueqiu MCP

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
Most tools have distinct purposes targeting specific financial data types (e.g., balance sheet, cash flow, fund info), but there is some overlap in tools like quotec and quote_detail for stock quotes, and multiple fund tools (fund_info, fund_detail) could be confusing. The descriptions help differentiate, but the sheer number increases potential for misselection.
Naming Consistency4/5
Naming is mostly consistent with snake_case and descriptive nouns (e.g., capital_flow, income, fund_manager), with clear patterns for related tools (e.g., index_perf_30, index_perf_90). Minor deviations exist, such as pankou (non-English) and quotec (abbreviated), but overall the conventions are readable and predictable.
Tool Count2/5
With 45 tools, the count is excessive for a financial data server, making it heavy and potentially overwhelming. While the domain is broad (stocks, funds, indices, etc.), many tools could be consolidated (e.g., multiple fund tools, index performance periods), indicating poor scoping and unnecessary fragmentation.
Completeness4/5
The tool set covers a wide range of financial data, including stocks, funds, indices, and market metrics, with good CRUD-like coverage for key entities (e.g., financial statements, fund details). Minor gaps exist, such as limited update/delete operations typical for read-only data, but agents can likely access most needed information without major dead ends.
Average 2.8/5 across 45 of 45 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits 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

Behavior2/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 of behavioral disclosure. The description only states it 'gets' data, implying a read-only operation, but provides no information about authentication requirements, rate limits, error conditions, response format, or whether this is a real-time or cached data source. For a financial data tool with no annotation coverage, this represents significant 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with only two sentences that directly address purpose and parameters. The structure is clear with a purpose statement followed by an 'Args' section. While efficient, the front-loading could be improved as the first sentence is quite vague, but overall there's minimal wasted text.
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 complexity of financial data tools, no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't explain what 'derived data' includes, how results are structured, whether there are limitations or prerequisites, or how this differs from similar fund tools. For a tool in a crowded namespace with 45 siblings, more contextual information is needed to guide appropriate usage.
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 description includes an 'Args' section that documents the single parameter 'fund_code' with a brief explanation. However, with 0% schema description coverage, the schema provides only a default value and type. The description adds minimal semantic value by confirming this is a fund code parameter, but doesn't explain format requirements, validation rules, or provide examples beyond the default. This meets the baseline for a single parameter tool but doesn't fully compensate for the schema coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '获取基金衍生数据' (get fund derived data), which is a tautology that essentially restates the tool name 'fund_derived' in Chinese. While it specifies the resource (fund derived data), it lacks a specific verb beyond 'get' and doesn't distinguish this tool from its many siblings that also retrieve financial data (like fund_detail, fund_info, fund_asset, etc.). The purpose is vague about what type of 'derived data' this provides compared to other fund-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. With 45 sibling tools on the server, including multiple fund-specific ones (fund_achievement, fund_asset, fund_detail, fund_growth, fund_info, fund_manager, fund_nav_history, fund_trade_date), there's no indication of what makes 'fund_derived' distinct or when it should be chosen over these other options. No context, 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states what data is retrieved without mentioning any behavioral traits: no information on permissions needed, rate limits, data freshness, error handling, or output format. This is inadequate for a tool with no annotation coverage.
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 a single, efficient sentence in Chinese, making it concise and front-loaded. However, it's overly brief given the tool's potential complexity, bordering on under-specification rather than optimal 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 no annotations, no output schema, and low parameter schema coverage, the description is incomplete. It doesn't cover behavioral aspects, parameter meanings, or what the tool returns, leaving significant gaps for an AI agent to understand and use the tool effectively.
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?
The input schema has 1 parameter with 0% description coverage, and the tool description doesn't mention parameters at all. It doesn't explain what 'stock_code' represents, its format (e.g., 'SZ000002' as default), or how it affects the rating data retrieval. This fails to compensate for the low schema coverage.
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 '获取机构评级数据' (Get institutional rating data) states a general purpose but lacks specificity. It mentions the resource (institutional rating data) but doesn't specify what kind of ratings, for what entities, or how they're retrieved. It doesn't distinguish from siblings like 'suggest_stock' or 'indicator' which might also provide rating-related 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 is provided on when to use this tool versus alternatives. With many sibling tools (e.g., 'suggest_stock', 'indicator', 'earningforecast'), there's no indication of whether this is for historical ratings, real-time updates, or comparative analysis. The description doesn't mention prerequisites, exclusions, or specific contexts for application.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the action ('获取' - get) without any details on permissions, rate limits, data freshness, or output format. For a tool with no annotations, this is a significant gap, offering no behavioral context beyond the basic purpose.
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 a single, efficient sentence in Chinese ('获取F10行业对比数据') with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every element contributes directly to stating the purpose.
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 has no annotations, 0% schema description coverage, and no output schema, the description is incomplete. It doesn't explain what 'F10' refers to, what 'industry comparison' entails, or how the parameter influences the output. For a tool with such minimal structured data, more context is needed to be fully usable.
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 compensate. It mentions 'F10行业对比数据' but doesn't explain the 'stock_code' parameter's role in this context (e.g., whether it's the target stock for comparison or a reference). No additional parameter details are provided, failing to address the coverage gap.
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 '获取F10行业对比数据' (Get F10 industry comparison data) states a general purpose but lacks specificity. It mentions 'F10' (likely a financial data source) and 'industry comparison', but doesn't clarify what exactly is compared (e.g., metrics, companies) or the scope. It's vague about the verb '获取' (get) - whether it retrieves, calculates, or generates data. No distinction from siblings is provided.
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 is given. The description doesn't mention prerequisites, context, or exclusions. With many sibling tools (e.g., 'balance', 'income', 'indicator'), there's no indication of how this tool differs or when it's appropriate, leaving usage entirely implicit.
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 the full burden. It mentions 'detailed' market data but doesn't disclose behavioral traits such as data freshness (real-time vs. delayed), rate limits, authentication needs, error handling, or what 'detailed' includes (e.g., price, volume, bid-ask spreads). This is a significant gap for a data-fetching tool with zero annotation coverage.
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 a single, efficient sentence in Chinese ('获取某支股票的行情数据-详细'), which is appropriately concise and front-loaded with the core purpose. However, it could be slightly improved by specifying what 'detailed' means, but it avoids unnecessary verbosity.
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 complexity of financial data tools, no annotations, no output schema, and low parameter coverage, the description is incomplete. It doesn't explain the return values (e.g., data structure, fields), error cases, or how it fits among the many sibling tools, making it inadequate for reliable agent use without additional context.
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?
The schema description coverage is 0%, so the description must compensate. It implies a stock parameter but doesn't explain the 'stock_code' input beyond what's in the schema (which only has a title and default). No details on format (e.g., exchange prefixes like 'SZ'), valid codes, or handling of invalid inputs are provided, leaving the parameter poorly documented.
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 '获取某支股票的行情数据-详细' (Get detailed market data for a stock) states a clear verb ('获取' - get) and resource ('行情数据' - market data), but it's vague about what 'detailed' entails compared to other tools. It doesn't distinguish from siblings like 'quotec' (which might be a simpler quote tool) or 'kline' (which could provide chart data), leaving the scope ambiguous.
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. With many sibling tools (e.g., 'quotec', 'kline', 'pankou'), the description lacks context on whether this is for real-time data, historical data, or specific metrics, and doesn't mention prerequisites or exclusions, leaving the agent to guess based on tool names alone.
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 the full burden of behavioral disclosure. It mentions '搜索' (search) but doesn't specify if this is a read-only operation, what the output format might be (e.g., list of suggestions with codes/names), or any limitations like rate limits. The description is too minimal to adequately inform an agent about 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences and an Args section, avoiding unnecessary verbosity. It's front-loaded with the main purpose, though the structure could be improved by integrating the parameter info more seamlessly rather than as a separate note.
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 complexity (a search tool with no annotations, 0% schema coverage, and no output schema), the description is incomplete. It doesn't explain what the tool returns (e.g., a list of matching stocks), how results are ordered, or any error conditions. For a tool that likely outputs structured data, this lack of detail hinders effective use by an agent.
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?
The description includes an 'Args' section that lists 'keyword: 关键词', adding minimal semantics beyond the schema. However, with 0% schema description coverage and no output schema, the description doesn't compensate enough—it doesn't explain what constitutes a valid keyword (e.g., partial names, codes, symbols) or how results are structured. This leaves significant gaps in parameter understanding.
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 the tool's purpose as '关键词搜索股票代码' (keyword search for stock codes), which provides a basic verb+resource combination. However, it doesn't differentiate from sibling tools like 'quotec' or 'quote_detail' that might also retrieve stock information. The purpose is clear but lacks specificity about what makes this tool unique.
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. With many sibling tools related to stocks (e.g., 'quotec', 'quote_detail', 'kline'), there's no indication of whether this is for fuzzy matching, exact codes, or initial discovery. The user must infer usage from the name alone.
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 states it 'gets' data, implying a read-only operation, but doesn't disclose behavioral traits like authentication needs, rate limits, data freshness, or what 'distribution' means (e.g., time-based, volume-based). For a tool with no annotation coverage, this leaves significant gaps in understanding its 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 a single, efficient phrase in Chinese that directly states the tool's function. It's front-loaded with no wasted words, making it easy to parse quickly. However, this conciseness comes at the cost of detail, which is reflected in other scores.
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 no annotations, 0% schema description coverage, no output schema, and one parameter, the description is incomplete. It doesn't explain what 'capital transaction distribution data' includes, how the parameter influences results, or what the return format is. For a tool with such minimal structured data, the description should provide more context to be useful.
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 compensate. It mentions no parameters at all, while the input schema has one parameter ('stock_code'). The description doesn't add any meaning about what 'stock_code' represents or how it affects the output. With low coverage and no parameter info in the description, it fails to provide necessary context.
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 '获取资金成交分布数据' (Get capital transaction distribution data) states a general purpose but lacks specificity about what 'capital transaction distribution' entails or what resource it operates on. It distinguishes from siblings like 'capital_flow' or 'capital_history' only by the term 'distribution', but doesn't clarify how it differs functionally. The purpose is vague rather than specific.
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 like 'capital_flow' or 'capital_history'. The description implies it's for capital-related data but doesn't specify contexts, prerequisites, or exclusions. Without any usage instructions, the agent must infer from the name alone.
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 provided, the description carries the full burden of behavioral disclosure. It mentions data retrieval ('获取') but lacks details on permissions, rate limits, data freshness, or response format. For a tool that likely involves real-time or sensitive financial data, this is a significant gap in 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 with a single sentence in Chinese, front-loading the core purpose. It efficiently states the action and data type without unnecessary elaboration, though it could be slightly clearer in English translation for broader accessibility.
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 complexity of financial data tools, no annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't address key aspects like data format, update frequency, error handling, or how it differs from siblings, leaving the agent with insufficient context for reliable use.
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 description adds no parameter information beyond what the schema provides. With 0% schema description coverage and one parameter ('stock_code'), the description doesn't compensate by explaining the parameter's role, format, or default value implications. However, since there's only one parameter, the baseline is adjusted to 3, as the agent can infer it's for specifying a stock.
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 the tool '获取当日资金流如流出数据，每分钟数据' (gets daily capital flow and outflow data, minute-by-minute data), which provides a clear verb ('获取') and resource ('资金流数据'). However, it doesn't differentiate from sibling tools like 'capital_history' or 'capital_assort', leaving ambiguity about scope or granularity distinctions.
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 implies it's for current-day, minute-level capital flow data, but it doesn't specify prerequisites, exclusions, or compare to siblings like 'capital_history' for historical data or 'cash_flow' for broader financial metrics.
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 the full burden of behavioral disclosure. It mentions retrieving daily data but does not specify aspects like data format, time range limits, authentication needs, rate limits, or whether it's a read-only operation. This is inadequate for a tool with no annotation coverage.
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 a single, efficient sentence that clearly states the purpose. It is front-loaded and avoids unnecessary words, making it easy to parse quickly.
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 complexity of financial data retrieval, no annotations, no output schema, and incomplete parameter documentation, the description is insufficient. It lacks details on data scope, return format, and behavioral traits, making it incomplete for effective tool use.
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 one parameter ('stock_code') with 0% description coverage, and the tool description does not mention any parameters. Since there are no parameters described, the baseline is 4, but the description fails to compensate for the lack of schema coverage by explaining what 'stock_code' represents or its format, resulting in a score of 3.
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 the tool retrieves historical capital flow data (e.g., outflow) on a daily basis, which clarifies the verb ('获取' meaning 'get/retrieve') and resource ('历史资金流如流出数据' meaning 'historical capital flow such as outflow data'). However, it does not distinguish this tool from sibling tools like 'capital_flow' or 'capital_assort', leaving ambiguity about their specific differences.
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. It does not mention any prerequisites, exclusions, or comparisons to sibling tools such as 'capital_flow' or 'capital_assort', leaving the agent without context for selection.
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 the full burden of behavioral disclosure. It only states what the tool does ('获取可转债信息') and lists parameters, but fails to describe key behaviors such as whether this is a read-only operation, potential rate limits, authentication requirements, error handling, or what the output format looks like. For a tool with no annotation coverage, this is a significant gap in 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: it starts with the purpose in one line, then lists parameters with brief explanations. There's no wasted text, and it's front-loaded with the main function. However, it 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 complexity (a data retrieval tool with pagination), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what '可转债信息' includes, how results are formatted, pagination behavior, or error cases. For a tool with two parameters and no structured output documentation, this leaves significant gaps for an agent to understand and use it effectively.
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 description lists the parameters 'page_size' and 'page_count' with brief Chinese explanations ('每页显示数量' for page size, '页码' for page count), which adds basic semantic meaning beyond the schema's titles ('Page Size', 'Page Count'). However, with 0% schema description coverage, the description doesn't fully compensate by detailing constraints, defaults, or usage examples. The added value is minimal but present.
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 convertible bond information), which provides a clear verb ('获取') and resource ('可转债信息'). However, it doesn't distinguish this tool from potential siblings like 'bond' or 'financial_instruments' tools that might exist elsewhere, though none are in the provided sibling list. The purpose is understandable but could be more specific about what type of convertible bond information is retrieved.
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. It doesn't mention any prerequisites, context for usage, or comparisons to other tools in the sibling list (e.g., 'balance', 'capital_flow'). This leaves the agent without direction on appropriate scenarios for invoking this tool.
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 for behavioral disclosure. It only states what data is retrieved ('业绩预告数据') without mentioning any behavioral traits like whether this requires authentication, has rate limits, returns structured or raw data, includes error handling, or what time periods are covered. For a data retrieval tool with zero annotation coverage, this is insufficient.
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 single phrase in Chinese—with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place by conveying the essential purpose without redundancy.
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's complexity (data retrieval with a parameter), lack of annotations, no output schema, and low parameter documentation, the description is incomplete. It doesn't address what the output contains (e.g., forecast values, dates, confidence intervals), how results are structured, or any prerequisites. For a financial data tool, this leaves significant gaps for an AI agent to use it correctly.
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?
The input schema has 1 parameter with 0% description coverage (only title 'Stock Code' and default 'SZ000002'). The description adds no semantic information about parameters—it doesn't explain what 'stock_code' represents, valid formats, or how it affects the output. With low schema coverage, the description fails to compensate, leaving the parameter poorly documented.
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 '按年度获取业绩预告数据' (Get annual earnings forecast data) states a clear verb ('获取' - get) and resource ('业绩预告数据' - earnings forecast data), but it's vague about scope and granularity. It doesn't specify whether this returns historical forecasts, future projections, or both, nor how it differs from siblings like 'income' or 'report' which might contain related 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. With many sibling tools (e.g., 'income', 'report', 'indicator') that could overlap with financial data, there's no indication of when this specific earnings forecast data is preferred or what distinguishes it from other financial reporting 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 carries the full burden of behavioral disclosure. It only states what the tool does without mentioning whether it's a read-only operation, if it requires authentication, rate limits, data freshness, or what format the output returns. For a tool with no annotations, this leaves critical behavioral traits unspecified.
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 a clear purpose statement followed by parameter documentation. However, the Args section could be integrated more smoothly, and there's room to add brief usage context without sacrificing brevity. It avoids unnecessary verbosity while maintaining clarity.
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 annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't address key contextual elements like output format (e.g., structured data vs. raw text), error handling, or dependencies on other tools. For a tool in a financial data context with many siblings, more guidance is needed to ensure correct usage.
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 description adds minimal parameter semantics by listing 'index_code: 指数代码' in the Args section, which mirrors the schema's 'Index Code' title. With 0% schema description coverage and only 1 parameter, this provides basic clarification but doesn't explain format expectations (e.g., examples like 'SZ000002'), validation rules, or how the parameter affects results beyond what's implied by the tool name.
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 the tool's purpose as '获取指数权重股前十' (Get top 10 index weight stocks), which is a clear verb+resource combination. However, it doesn't differentiate from sibling tools like 'index_basic_info', 'index_details_data', or 'index_perf_*' tools, leaving ambiguity about when to use this specific tool versus other index-related 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?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools related to indices (e.g., index_basic_info, index_details_data, index_perf_30), there's no indication of whether this tool is for real-time data, historical analysis, or comparison purposes. The user must infer usage from the name alone.
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 a default parameter value but lacks critical behavioral details such as data source, rate limits, authentication needs, error handling, or what the output format looks like. This is inadequate for a data retrieval tool with no 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two short sentences, making it easy to parse. It front-loads the core purpose and includes parameter guidance efficiently, though it could benefit from slightly more detail without becoming verbose.
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 complexity of financial data retrieval, no annotations, no output schema, and low schema coverage, the description is incomplete. It lacks details on output format, error conditions, data freshness, and how it differs from sibling tools, making it insufficient for reliable agent use.
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 description adds minimal semantics: it explains that the second parameter ('days') specifies a range from now to N days ago with a default of 100. However, with 0% schema description coverage, it doesn't clarify the first parameter ('stock_code') or provide examples, leaving significant gaps in parameter understanding.
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 '获取K线数据' (Get K-line data), which clearly indicates the tool's purpose as retrieving financial chart data. However, it doesn't specify what type of K-line data (e.g., stock, crypto) or distinguish itself from potential sibling tools that might also retrieve financial data, making it somewhat vague.
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 mentions a default value for the 'days' parameter but doesn't explain use cases, prerequisites, or comparisons with sibling tools like 'quotec' or 'quote_detail' that might offer related financial 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. '获取' (get) implies a read operation, but there's no information about rate limits, authentication requirements, data freshness, error conditions, or what format the data returns. For a financial data tool with zero annotation coverage, this represents a significant behavioral transparency gap.
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 - a single Chinese phrase. While this is efficient, it may be too brief given the tool's likely complexity. There's no wasted language, but it may be under-specified rather than appropriately concise. The structure is simple and front-loaded with the core action.
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?
For a financial data tool with no annotations, no output schema, and 0% parameter documentation, the description is inadequate. It doesn't explain what 'F10 main indicator data' includes, how it differs from other indicator tools, what the return format is, or any behavioral characteristics. Given the context of financial data tools where precision matters, this description leaves too many questions unanswered.
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 description mentions no parameters at all, while the schema shows one parameter (stock_code). With 0% schema description coverage, the description doesn't compensate by explaining what stock_code represents, what format it should be in, or what the default 'SZ000002' signifies. The baseline is 3 since there's only one parameter, but the description adds no value beyond what's minimally visible in 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 '获取F10主要指标数据' (Get F10 main indicator data) states a clear verb ('获取' - get) and resource ('F10主要指标数据' - F10 main indicator data). However, it doesn't distinguish this tool from sibling tools like 'indicator' or 'report' which likely provide related financial data. The purpose is understandable but lacks specificity about what makes this 'main indicator' data unique.
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. With many sibling tools providing financial data (balance, cash_flow, income, indicator, etc.), there's no indication of what distinguishes 'main indicator' data or when it should be preferred over other data sources. The description offers no context about use cases or prerequisites.
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 the full burden of behavioral disclosure. It states '获取' (get), implying a read-only operation, but does not specify if it requires authentication, has rate limits, returns real-time or historical data, or details error conditions. For a tool with no annotation coverage, this is a significant gap in 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 a single, concise phrase ('获取融资融券数据') that directly states the tool's function without unnecessary words. It is front-loaded and efficiently communicates the core purpose, making it easy to parse quickly.
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 has no annotations, no output schema, and low parameter schema coverage, the description is incomplete. It does not address behavioral aspects, parameter usage, or output format, which are critical for an AI agent to invoke the tool correctly in a financial data context with many sibling tools.
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?
The schema has 1 parameter with 0% description coverage, and the tool description does not mention any parameters. It fails to explain the 'stock_code' parameter's role, format (e.g., 'SZ000002' as default), or how it affects the data retrieval. With low schema coverage, the description does not compensate, leaving parameter meaning unclear.
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 '获取融资融券数据' (Get margin trading data) clearly states the verb ('获取' - get) and resource ('融资融券数据' - margin trading data), providing a basic purpose. However, it lacks specificity about what margin trading data includes (e.g., balances, positions, history) and does not differentiate from siblings like 'balance' or 'capital_flow', which could also relate to financial data. This makes it vague but not tautological.
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. With siblings like 'balance', 'capital_flow', and 'holders' that might overlap in financial data contexts, there is no indication of specific use cases, prerequisites, or exclusions. This leaves the agent without direction on tool selection.
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 the full burden. It mentions the action ('获取') but does not disclose behavioral traits such as whether this is a read-only operation, potential rate limits, authentication needs, error handling, or the format of returned data. This is a significant gap for a tool with no structured safety hints.
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 front-loaded with the purpose, followed by parameter details. It avoids unnecessary verbosity, but the structure could be improved by integrating the parameter explanation more seamlessly rather than as a separate 'Args' section.
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 no annotations, no output schema, and low schema description coverage, the description is incomplete. It lacks details on return values, error conditions, and behavioral context, making it inadequate for safe and effective use by an AI agent without additional assumptions.
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 description includes an 'Args' section that lists 'cube_symbol: 组合代码', adding meaning by specifying that the parameter is a portfolio code. With 0% schema description coverage and 1 parameter, this partially compensates, but it does not explain the parameter's format, constraints, or the default value ('SZ000002') shown in 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 portfolio net value data), which provides a clear verb ('获取') and resource ('组合净值数据'), establishing the basic purpose. However, it does not differentiate this tool from sibling tools like 'fund_nav_history' or 'fund_detail', which might also retrieve net asset value data, leaving ambiguity about its specific 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?
The description offers no guidance on when to use this tool versus alternatives. With many sibling tools (e.g., 'fund_nav_history', 'fund_detail', 'balance'), there is no indication of context, prerequisites, or exclusions, leaving the agent to guess based on tool names alone.
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 the full burden of behavioral disclosure. The description only states what data is retrieved ('F10 institutional holding data') but doesn't mention any behavioral traits such as whether this is a read-only operation, potential rate limits, authentication requirements, data freshness, or what format the data is returned in. For a data retrieval tool with zero annotation coverage, this is a significant gap.
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 a single, efficient phrase that directly states the tool's function. There's no wasted verbiage or unnecessary elaboration. It's appropriately sized for a simple data retrieval tool.
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 complexity (data retrieval tool with 1 parameter), lack of annotations, and no output schema, the description is incomplete. It doesn't explain the parameter, behavioral aspects, or return values. For a tool in a crowded namespace with 45 siblings, more context is needed to help an agent use it correctly.
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?
The input schema has 1 parameter ('stock_code') with 0% schema description coverage (the schema provides only a title and default value). The description doesn't mention this parameter at all, failing to compensate for the low coverage. It doesn't explain what 'stock_code' represents, what format it should be in, or how it affects the data retrieval.
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 '获取F10机构持仓数据' translates to 'Get F10 institutional holding data', which provides a clear verb ('get') and resource ('F10 institutional holding data'). However, it doesn't distinguish this tool from its many siblings (like 'holders', 'top_holders', 'capital_history', etc.), which likely also deal with holding/ownership data. The purpose is understandable but lacks sibling 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?
The description provides no guidance on when to use this tool versus alternatives. With 45 sibling tools including several related to holdings (e.g., 'holders', 'top_holders'), there's no indication of what makes this tool unique or when it should be preferred over others. No context about prerequisites or exclusions is mentioned.
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 the full burden of behavioral disclosure. It only states what the tool does ('获取基金经理信息') without mentioning whether it's a read-only operation, if it requires authentication, rate limits, error conditions, or what format the output might be in. This leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief with two sentences, but the structure is somewhat awkward with 'Args:' appearing in the description text rather than being handled by the schema. It's front-loaded with the purpose, but could be more polished in presentation.
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?
For a tool with no annotations, no output schema, and minimal sibling differentiation, the description is incomplete. It doesn't explain what information about fund managers is returned, how results are formatted, or provide any context about the data source or limitations. The agent would struggle to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explicitly documenting the single parameter 'fund_code' and its purpose ('基金代码' - fund code). This adds meaningful context beyond what the schema provides, though it doesn't specify format requirements or examples beyond the default in 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 fund manager information), which provides a clear verb ('获取' - get) and resource ('基金经理信息' - fund manager information). However, it doesn't differentiate from sibling tools like 'fund_detail' or 'fund_info' that might also provide fund-related information, making the purpose somewhat vague in context.
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. With many sibling tools related to funds (e.g., fund_detail, fund_info, fund_asset), there's no indication of what makes this tool unique or when it should be preferred over others for accessing fund manager data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 of behavioral disclosure. It only states what data is fetched without any information on permissions, rate limits, data freshness, or response format. For a data retrieval tool with zero annotation coverage, this is inadequate and fails to disclose critical 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?
The description is a single, efficient sentence in Chinese that directly states the tool's purpose without any fluff or redundancy. It is appropriately sized and front-loaded, making it easy to parse quickly.
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 complexity of financial data tools, lack of annotations, no output schema, and minimal parameter documentation, the description is incomplete. It does not cover behavioral aspects, usage context, or return values, leaving significant gaps for an AI agent to understand how to invoke it correctly.
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 description does not mention parameters at all, and the input schema has 0% description coverage, with only one parameter 'stock_code' documented structurally. Since there is only one parameter, the baseline is higher, but the description adds no semantic value beyond the schema, such as explaining what 'F10' refers to or format expectations for the stock code.
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 '获取F10股东人数数据' clearly states the action ('获取' meaning 'get' or 'fetch') and the resource ('F10股东人数数据' meaning 'F10 shareholder count data'), providing a specific purpose. However, it does not explicitly differentiate from sibling tools like 'top_holders' or 'org_holding_change', which might also relate to shareholder information, 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 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. It does not mention any context, prerequisites, or exclusions, such as whether it's for real-time data, historical trends, or specific stock types. With many sibling tools potentially overlapping in financial data, this omission is significant.
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 states the tool retrieves data ('获取'), implying a read-only operation, but doesn't disclose important behavioral aspects like data source, freshness, format of returned data, error conditions, or rate limits. For a financial data tool with no annotations, this leaves significant gaps in understanding how it behaves.
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 appropriately concise with a clear purpose statement followed by parameter explanations. Each sentence serves a purpose: the first states what the tool does, and the subsequent lines explain each parameter. No wasted words, though the structure could be slightly improved with clearer formatting.
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?
For a financial data retrieval tool with 3 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the returned cash flow data looks like (structure, fields, time periods), data currency, source reliability, or typical use cases. The parameter explanations help, but significant context about the tool's behavior and output is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides meaningful parameter explanations that compensate well. It clarifies that 'stock_code' is a stock code, 'is_annals' controls whether to get only annual reports (with default 1), and 'count' specifies the number of data items to return (default 5). This adds substantial value beyond the bare schema fields.
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 cash flow statement data), which is a clear verb+resource combination. However, it doesn't distinguish this tool from potential siblings like 'balance' or 'income' that might provide other financial statements. The purpose is understandable but lacks 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 about when to use this tool versus alternatives. With siblings like 'balance' and 'income' that likely provide other financial statements, the description offers no context about when cash flow data is needed versus balance sheet or income statement data. The only usage hint is implicit through parameter descriptions.
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 provided, the description carries full burden for behavioral disclosure. It only states what information is retrieved without describing response format, error conditions, rate limits, authentication needs, or whether the data is real-time vs historical. For a tool with zero annotation coverage, this represents significant gaps in behavioral context.
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 appropriately brief with two sentences that directly address purpose and parameters. The structure is clear with purpose first followed by parameter documentation. No unnecessary information is included, though the formatting could be slightly improved for readability.
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 no annotations, no output schema, and 0% schema description coverage, the description is incomplete for effective tool use. While it states the basic purpose and parameter, it lacks crucial information about return format, error handling, data freshness, and how this tool differs from similar sibling tools in the financial data 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 description explicitly documents the single parameter 'fund_code' with a brief explanation, though schema description coverage is 0%. Since there's only one parameter and the description provides its purpose, this adequately compensates for the lack of schema documentation. However, it doesn't provide format examples or validation rules beyond the basic explanation.
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 fund trading date information), which provides a basic verb+resource combination. However, it's somewhat vague about what specific trading date information is retrieved (e.g., next trading day, historical schedule, settlement dates) and doesn't distinguish from sibling tools like 'fund_info' or 'fund_detail' that might also provide related 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 is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context for use, or compare it to sibling tools like 'fund_info' that might overlap in functionality. This leaves the agent without clear direction on appropriate usage 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 the full burden of behavioral disclosure. It only states the action ('获取') without detailing permissions, rate limits, output format, or error handling. For a tool with no annotation coverage, this is a significant gap in 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 with two sentences: one stating the purpose and another listing the parameter. It's front-loaded with the main action, though the Args section could be integrated more smoothly. No wasted words, but structure is basic.
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 no annotations, 0% schema description coverage, and no output schema, the description is incomplete. It doesn't explain what 'basic information' includes, how to interpret results, or handle errors, making it inadequate for a tool with one parameter and unclear output.
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 minimal semantics by listing 'index_code' in the Args section, but schema description coverage is 0%, so the schema provides no parameter details. With only one parameter and the description naming it, this partially compensates, though it doesn't explain format or constraints beyond the default in 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 the purpose as '获取指数基本信息' (get index basic information), which is clear but vague. It specifies the verb '获取' (get) and resource '指数基本信息' (index basic information), but doesn't detail what constitutes 'basic information' or differentiate it from sibling tools like 'index_details_data' or 'index_perf_30'.
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 doesn't mention prerequisites, exclusions, or compare it to sibling tools like 'index_details_data' or 'index_perf_30', leaving the agent without context for tool selection.
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 the full burden of behavioral disclosure. It states the tool retrieves quote data but does not describe any behavioral traits such as data freshness, rate limits, error handling, or authentication needs. This is a significant gap for a tool with zero annotation coverage.
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 a single, efficient sentence with zero waste: '获取某支股票的行情数据'. It is appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary details.
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's complexity (simple data retrieval), lack of annotations, no output schema, and incomplete parameter documentation, the description is inadequate. It does not provide enough context for an AI agent to understand how to use the tool effectively, such as explaining the parameter or describing the return format.
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?
The description does not add any meaning beyond the input schema. With 0% schema description coverage, the parameter 'stock_code' is undocumented in both the schema and description. The description does not explain what 'stock_code' represents (e.g., format like 'SZ000002'), its required status, or default behavior, failing to compensate for the coverage gap.
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's purpose as '获取某支股票的行情数据' (Get quote data for a specific stock), which specifies the verb (获取/get) and resource (行情数据/quote data). It distinguishes from siblings like 'quote_detail' by focusing on basic quote data rather than detailed information, though not explicitly. The purpose is clear but lacks explicit sibling 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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention when to choose 'quotec' over 'quote_detail' or other sibling tools like 'kline' or 'pankou', nor does it specify prerequisites or exclusions. Usage is implied by the purpose but lacks explicit 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 are provided, so the description carries the full burden of behavioral disclosure. It only states the tool retrieves information, implying it's read-only, but doesn't cover aspects like rate limits, authentication needs, error conditions, or response format. For a tool with no annotations, this is a significant gap in 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 brief and front-loaded with the main purpose, followed by parameter details. It avoids unnecessary verbosity, though the structure could be improved by integrating the parameter explanation more seamlessly rather than as a separate 'Args' section.
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's complexity (historical data retrieval), lack of annotations, no output schema, and minimal parameter documentation, the description is incomplete. It doesn't explain what data is returned, time ranges, or how to interpret results, making it inadequate for effective agent use without additional 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 description adds meaningful context for the single parameter 'cube_symbol' by labeling it as '组合代码' (portfolio code), which clarifies its purpose beyond the schema's generic 'Cube Symbol' title. With 0% schema description coverage and only one parameter, this compensation is adequate, though it could specify format or examples.
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 portfolio historical transaction information), which clearly indicates the tool retrieves historical data for a portfolio. However, it doesn't distinguish this from similar sibling tools like 'capital_history' or 'fund_nav_history', leaving ambiguity about what specific type of 'transaction information' is provided.
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. With many sibling tools related to historical data (e.g., capital_history, fund_nav_history), the description fails to specify use cases, prerequisites, or exclusions, leaving the agent to guess based on the tool name alone.
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 the full burden of behavioral disclosure. It only states the action ('获取' - get) without details on permissions, rate limits, data freshness, or output format. This is inadequate for a tool that likely involves external data fetching, as it omits critical operational context.
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 a single, efficient phrase ('获取大宗交易数据') with zero waste. It's front-loaded and appropriately sized for the basic information it conveys, though this conciseness contributes to gaps in other dimensions.
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 complexity of financial data tools, no annotations, no output schema, and low schema description coverage (0%), the description is incomplete. It fails to address key aspects like return format, error handling, or data scope, making it insufficient for reliable agent use.
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 doesn't mention parameters, but with only one parameter ('stock_code') and 0% schema description coverage, the baseline is high. Since no parameters are explained in the description, it doesn't add value beyond the schema, but the minimal parameter count keeps the score from dropping lower.
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 '获取大宗交易数据' (Get block transaction data) states the action ('获取' - get) and resource ('大宗交易数据' - block transaction data), providing a basic purpose. However, it's vague about scope (e.g., historical vs. real-time, specific markets) and doesn't distinguish from siblings like 'capital_flow' or 'capital_history', which might overlap in financial data contexts.
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. With many sibling tools for financial data (e.g., 'capital_flow', 'kline', 'report'), the description lacks context on use cases, prerequisites, or exclusions, leaving the agent to guess based on the tool name alone.
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 provided, the description carries the full burden of behavioral disclosure. It describes a data retrieval operation ('获取' - get/fetch) which implies read-only behavior, but doesn't mention authentication requirements, rate limits, error conditions, or what format the data returns. For a tool with no annotation coverage, this leaves significant behavioral questions unanswered.
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 efficiently structured with a clear purpose statement followed by parameter explanations. Each sentence serves a purpose: the first states what the tool does, and the next three lines explain each parameter. There's no wasted text, though it could be slightly more polished in 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?
For a data retrieval tool with 3 parameters and no output schema, the description covers the basic purpose and parameters adequately. However, it doesn't explain what 'F10 dividend financing data' actually contains, what format it returns, or how to interpret the results. With no annotations and no output schema, users need more context about what they're getting and how to use it.
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 provides clear semantic explanations for all 3 parameters: 'stock_code: 股票代码' (stock code), 'page: 第几页默认1' (which page, default 1), and 'size: 每页含有多少数据默认10' (how much data per page, default 10). With 0% schema description coverage, the description fully compensates by explaining what each parameter means and their defaults, adding significant value beyond the bare 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 '获取F10分红融资数据' which translates to 'Get F10 dividend financing data' - this provides a clear verb ('get') and resource ('F10 dividend financing data'). However, it doesn't distinguish this tool from its many siblings (like 'balance', 'cash_flow', 'income', etc.) which also appear to be financial data retrieval tools. The purpose is clear but lacks sibling 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?
The description provides no guidance on when to use this tool versus alternatives. With 50+ sibling tools on the server (including 'balance', 'cash_flow', 'income', 'holders', etc.), there's no indication of what makes this tool distinct or when an agent should choose it over other financial data tools. The description is purely functional 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 are provided, so the description carries the full burden of behavioral disclosure. It mentions retrieving data but doesn't specify whether this is real-time or historical, if there are rate limits, authentication requirements, error conditions, or what the output format looks like. For a data retrieval tool with zero annotation coverage, this leaves significant gaps in understanding its 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 appropriately concise with a clear purpose statement followed by parameter explanations. The two-sentence structure is efficient, though the parameter section could be slightly more integrated. There's no unnecessary verbosity, and the information is front-loaded with the main function.
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 complexity of financial data tools, no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't explain what 'main business composition data' includes, how results are structured, or any limitations. For a tool that presumably returns structured business data, more context about the output would be necessary for effective use.
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 description adds basic semantics for both parameters: 'stock_code: 股票代码' (stock code) and 'count: 返回数据数量,默认5条' (return data quantity, default 5 items). This provides meaning beyond the schema's titles ('Stock Code', 'Count') and default values. However, with 0% schema description coverage, it doesn't fully compensate - it lacks details like format requirements for stock_code or constraints on count values.
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's purpose: '获取主营业务构成数据' (Get main business composition data). It specifies the verb ('获取' - get) and resource ('主营业务构成数据' - main business composition data), making the function unambiguous. However, it doesn't differentiate from sibling tools like 'income' or 'report' that might also provide financial data, preventing a perfect score.
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. With many sibling tools related to financial data (e.g., 'income', 'report', 'balance'), there's no indication of what makes this tool unique or when it should be preferred over others. The only usage context is implicit from the parameters.
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 the full burden of behavioral disclosure. While it states what the tool does, it provides no information about authentication requirements, rate limits, error conditions, response format, or whether this is a read-only operation. For a data retrieval tool with no annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but adequately structured with a purpose statement followed by parameter documentation. However, the formatting with 'Args:' on a separate line creates some visual clutter, and the single-sentence purpose could be more front-loaded with critical information.
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?
For a data retrieval tool with no annotations and no output schema, the description is incomplete. It doesn't explain what '业绩表现数据' (performance data) includes, the time period covered, the format of returned data, or any limitations. Given the complexity of financial data and the lack of structured documentation, this leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only one parameter and 0% schema description coverage, the description provides the essential semantic meaning of 'fund_code' as '基金代码' (fund code). This compensates well for the lack of schema documentation, though it doesn't provide format examples or validation rules beyond what's implied by the parameter name.
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's purpose as '获取基金业绩表现数据' (get fund performance data), which is a specific verb+resource combination. It doesn't explicitly differentiate from sibling tools like 'fund_detail', 'fund_growth', or 'fund_info', but the focus on '业绩表现' (performance) provides some 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?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools related to funds (fund_asset, fund_detail, fund_growth, fund_info, fund_manager, fund_nav_history), there's no indication of what makes this tool unique or when it should be preferred over others.
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 for behavioral disclosure. The description only states what data is retrieved without mentioning any behavioral traits like whether this is a read-only operation, what format the data returns in, whether there are rate limits, authentication requirements, or potential side effects. For a data retrieval tool with zero annotation coverage, this is inadequate.
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 appropriately concise with two sentences - one stating the purpose and one documenting the parameter. It's front-loaded with the main purpose first. However, the English translation 'Args:' followed by Chinese text creates minor structural inconsistency.
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 no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't explain what 'asset allocation data' includes, what format it returns, whether there are limitations or prerequisites, or how this differs from other fund tools. For a data retrieval tool in a context with many similar tools, more completeness is needed.
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 description explicitly documents the single parameter 'fund_code' with a brief explanation, but with 0% schema description coverage, the schema provides no parameter documentation. The description adds basic semantic meaning ('基金代码' means fund code), but doesn't provide format requirements, examples beyond the default, or validation rules. This partially compensates for the schema gap but not fully.
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's purpose as '获取基金资产配置数据' (get fund asset allocation data), which is a specific verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'fund_detail', 'fund_info', or 'fund_achievement', which might also provide fund-related data but with different focus areas.
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. With multiple sibling tools related to funds (fund_detail, fund_info, fund_achievement, fund_growth, fund_manager, etc.), there's no indication of what makes this tool unique or when it should be preferred over other fund-related 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 carries the full burden of behavioral disclosure. It only states that it '获取基金详细信息' (gets fund detailed information), which implies a read-only operation, but doesn't specify what '详细信息' (detailed information) includes, whether there are rate limits, authentication requirements, error conditions, or the format of returned data. For a tool with no annotations, this leaves significant behavioral gaps.
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: a brief purpose statement followed by a clear Args section. There's no unnecessary information, and it's front-loaded with the main functionality. However, the lack of additional context (e.g., usage guidelines, behavioral details) makes it feel slightly under-specified rather than optimally concise.
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 complexity (a tool for retrieving financial data with many sibling alternatives), no annotations, no output schema, and low parameter documentation (0% schema coverage), the description is incomplete. It doesn't explain what 'detailed information' includes, how it differs from other fund-related tools, or provide enough context for an AI agent to use it effectively without trial and error.
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 description adds minimal parameter semantics: it lists 'fund_code: 基金代码' (fund code) in the Args section, which matches the single parameter in the input schema. However, with 0% schema description coverage, the schema provides no details about the parameter (e.g., format, examples, constraints). The description doesn't compensate by explaining what a fund code is, its format, or where to find it, leaving the parameter poorly documented.
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 the purpose clearly: '获取基金详细信息' (Get fund detailed information). It specifies the verb ('获取' - get) and resource ('基金详细信息' - fund detailed information), making it easy to understand what the tool does. However, it doesn't distinguish itself from sibling tools like 'fund_info', 'fund_asset', or 'fund_manager', which all appear to be related to fund 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. With many sibling tools related to funds (e.g., fund_info, fund_asset, fund_manager), there's no indication of what makes this tool unique or when it should be preferred over others. The only context is the parameter requirement, but no usage scenarios or exclusions are mentioned.
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 the full burden of behavioral disclosure. It only states what data is retrieved ('基金增长数据') without mentioning any behavioral traits such as read-only status, potential rate limits, authentication needs, or what the output might look like. This is inadequate for a tool with no annotation coverage.
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 front-loaded with the main purpose, followed by a brief Args section. It avoids unnecessary verbosity, though the structure could be slightly improved by integrating the parameter info more seamlessly rather than as a separate section.
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 complexity (a data retrieval tool with no annotations, no output schema, and low schema coverage), the description is incomplete. It doesn't explain what 'fund growth data' entails, how it's returned, or any usage constraints, leaving significant gaps for an AI agent to understand and invoke the tool correctly.
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 description adds minimal parameter semantics by listing 'fund_code' in the Args section, but with 0% schema description coverage, it doesn't provide details like format, examples beyond the default, or constraints. Since there's only one parameter, the baseline is higher, but the description doesn't fully compensate for the lack of schema documentation.
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's purpose as '获取基金增长数据' (get fund growth data), which is a specific verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'fund_achievement', 'fund_asset', or 'fund_detail', which might also provide related fund data, so it doesn't reach the highest score.
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. With many sibling tools related to funds (e.g., fund_achievement, fund_asset), there's no indication of what makes 'fund_growth' unique or when it should be preferred over other fund-related 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 carries the full burden of behavioral disclosure. While '获取' implies a read operation, the description doesn't mention whether this requires authentication, has rate limits, returns structured data, or handles errors. For a tool with zero annotation coverage, this represents a significant gap in behavioral context.
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 appropriately concise with just two lines: a purpose statement followed by parameter documentation. There's no wasted text, and the structure is clear. However, the separation between purpose and parameters could be slightly cleaner, and the Chinese-only text might limit accessibility in some contexts.
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 complexity of financial data tools, no annotations, no output schema, and 0% schema description coverage, the description is inadequate. It doesn't explain what 'basic information' includes, how results are formatted, whether there are authentication requirements, or how this differs from similar tools. The agent would struggle to use this effectively without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly documents the single parameter (fund_code) and provides its Chinese name, which adds value beyond the schema's English title. However, with 0% schema description coverage, the description doesn't explain the parameter's format, constraints, or the meaning of the default value 'SZ000002'. It compensates partially but not fully for the schema's lack of documentation.
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's purpose with a specific verb ('获取' meaning 'get') and resource ('基金基本信息' meaning 'fund basic information'). It distinguishes itself from siblings like fund_asset, fund_detail, or fund_nav_history by focusing on basic information rather than specific aspects. However, it doesn't explicitly differentiate from fund_derived or fund_growth, which might also provide basic 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. With many sibling tools like fund_detail, fund_asset, and fund_nav_history, there's no indication of what makes this tool unique or when it should be preferred over others. The lack of context leaves the agent guessing about appropriate 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 provided, the description carries full burden but offers minimal behavioral insight. It implies a read operation but doesn't disclose rate limits, authentication needs, data freshness, or response format. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but front-loaded with the purpose. The Args section is redundant with the schema and could be omitted for better conciseness. It's efficient but not optimally structured.
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?
For a tool with no annotations, no output schema, and minimal parameter documentation, the description is incomplete. It lacks details on return values, error handling, and behavioral traits, making it insufficient for reliable agent use.
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 meaningful context for the single parameter 'fund_code' by explaining it's a fund code, which compensates for the 0% schema description coverage. However, it doesn't specify format constraints (e.g., 'SZ000002' example in schema) or optionality, keeping it from a perfect score.
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's purpose as '获取基金历史净值数据' (Get fund historical NAV data), which is a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'nav_daily' or 'fund_detail' that might provide related data, preventing a perfect score.
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 doesn't mention prerequisites, context, or comparisons to sibling tools like 'nav_daily' or 'fund_detail', leaving the agent without usage direction.
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 for behavioral disclosure. While '获取' (get) implies a read operation, the description doesn't address important behavioral aspects like whether this requires authentication, rate limits, what format the details are returned in, or potential error conditions. The description is too minimal to adequately inform an agent about how this tool behaves.
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 just two lines - a purpose statement and parameter documentation. While this is efficient, the parameter documentation could be better integrated rather than appearing as a separate 'Args:' section. There's no wasted text, but the structure feels slightly disjointed.
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?
For a tool with no annotations, no output schema, and multiple similar sibling tools, the description is inadequate. It doesn't explain what '详细信息' (detailed information) includes, how it differs from other index tools, what the return format looks like, or any behavioral constraints. The minimal description leaves too many questions unanswered for effective agent use.
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 description explicitly documents the single parameter 'index_code' with a brief explanation, which adds value beyond the schema's 0% description coverage. However, it doesn't provide additional context about valid index code formats, examples beyond the default, or what happens if an invalid code is provided. The parameter documentation is minimal but exists.
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's purpose as '获取指数详细信息' (get index details/information), which is a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'index_basic_info' or 'index_perf_30', leaving some ambiguity about what specific details this provides versus those other index-related 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?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools related to indices (index_basic_info, index_perf_30, index_perf_7, index_perf_90, index_weight_top10), there's no indication of what distinguishes this tool's functionality from those others or when each should be selected.
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 provided, the description carries full burden for behavioral disclosure. It only states what data is retrieved ('最近30天收益数据') but doesn't describe the return format, data structure, potential rate limits, authentication requirements, or error conditions. For a data retrieval tool with zero annotation coverage, this leaves significant behavioral gaps.
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 appropriately concise with two sentences: a clear purpose statement followed by parameter documentation. It's front-loaded with the main functionality. However, the Args section formatting could be cleaner, and there's some redundancy between the Chinese and English parameter documentation.
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?
For a data retrieval tool with no annotations, no output schema, and minimal schema documentation, the description is incomplete. It doesn't explain what '收益数据' (performance data) includes (returns, percentages, dates?), the data format, or how results are structured. The agent would have insufficient context to understand what this tool actually returns.
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 description includes an Args section that documents the single parameter 'index_code' and provides a brief explanation in Chinese. However, with 0% schema description coverage, the schema provides minimal context (just a default value and title). The description adds basic semantic meaning ('指数代码' - index code) but doesn't explain format requirements, valid values, or provide examples beyond the default.
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's purpose: '获取指数最近30天收益数据' (Get index's recent 30-day performance data). It specifies the verb ('获取' - get) and resource ('指数收益数据' - index performance data) with a time scope (30 days). However, it doesn't explicitly differentiate from sibling tools like 'index_perf_7' or 'index_perf_90' beyond the implied time frame difference.
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. It doesn't mention sibling tools like 'index_perf_7' (7-day performance) or 'index_perf_90' (90-day performance), nor does it explain why one would choose 30-day data over other time frames. There's no context about prerequisites or when-not-to-use 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 the full burden of behavioral disclosure. While it indicates this is a read operation ('获取' - get), it doesn't describe what the tool returns (e.g., data format, structure, or specific metrics), whether there are rate limits, authentication requirements, or any error conditions. For a data retrieval tool with zero annotation coverage, this leaves significant behavioral gaps.
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 appropriately concise with two sentences: one stating the purpose and another listing the parameter. It's front-loaded with the core functionality. While efficient, the parameter documentation could be slightly more informative given the lack of schema descriptions.
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's complexity (data retrieval with time-based filtering), absence of annotations, and no output schema, the description is incomplete. It doesn't explain what '收益数据' (performance data) entails, the return format, or how the 7-day period is calculated. For a tool that likely returns financial metrics, more context is needed for effective use.
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 description explicitly documents the single parameter 'index_code' and provides a brief explanation ('指数代码' - index code). However, with 0% schema description coverage, the schema only provides a default value and title without semantic context. The description adds basic meaning but doesn't elaborate on parameter format, valid values, or examples beyond what's implied by the default 'SZ000002'.
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's purpose: '获取指数最近7天收益数据' (Get index recent 7-day performance data). It specifies the verb '获取' (get) and resource '指数收益数据' (index performance data) with a time scope of '最近7天' (recent 7 days). However, it doesn't explicitly differentiate from sibling tools like 'index_perf_30' or 'index_perf_90', which appear to serve similar functions with different timeframes.
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. It doesn't mention sibling tools like 'index_perf_30' or 'index_perf_90' that likely provide similar data for different time periods, nor does it specify any prerequisites, exclusions, or contextual constraints for usage.
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 provided, the description carries full burden for behavioral disclosure. It states what data is retrieved but doesn't describe the return format, whether it's paginated, if there are rate limits, authentication requirements, or error conditions. For a data retrieval tool with zero annotation coverage, this leaves significant behavioral aspects undocumented.
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 appropriately concise with a clear purpose statement followed by parameter documentation. The two-sentence structure is efficient with minimal waste, though the parameter documentation could be more informative given the lack of schema descriptions.
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?
For a data retrieval tool with no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't explain what format the performance data returns, what metrics are included, or how the 90-day period is calculated. The context signals indicate this tool needs more comprehensive documentation to be fully usable.
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 description includes an 'Args' section that documents the single parameter 'index_code' and provides a brief explanation. However, with 0% schema description coverage, the description doesn't fully compensate by explaining the parameter format, valid values, or the default value 'SZ000002' shown in the schema. It adds some value but leaves important details unspecified.
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's purpose: '获取指数最近90天收益数据' (Get index performance data for the last 90 days). It specifies the verb ('获取' - get) and resource ('指数最近90天收益数据' - index performance data for last 90 days). However, it doesn't explicitly differentiate from siblings like 'index_perf_30' or 'index_perf_7', which appear to provide similar data for different timeframes.
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. It doesn't mention sibling tools like 'index_perf_30' or 'index_perf_7' that likely serve similar purposes with different timeframes, nor does it specify any prerequisites or contextual constraints for usage.
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 provided, the description carries full burden for behavioral disclosure. It mentions the tool retrieves data but doesn't specify whether this is a read-only operation, what format the data returns, whether there are rate limits, authentication requirements, or any side effects. The description is minimal and lacks important behavioral context for a data retrieval tool.
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 appropriately concise with a clear purpose statement followed by parameter explanations. The two-sentence structure is efficient, though the parameter explanations could be better integrated. There's no wasted text, and the information is front-loaded with the core purpose first.
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?
For a 3-parameter tool with no annotations, 0% schema description coverage, and no output schema, the description is insufficient. It doesn't explain what 'performance report data' actually contains, what format it returns, or provide examples. The tool appears to retrieve financial data but lacks critical context about the data structure, potential limitations, or error conditions.
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?
With 0% schema description coverage, the description provides basic parameter explanations in Chinese: stock_code (股票代码), is_annals (只获取年报,默认为1 - annual reports only, default 1), and count (返回数据数量,默认5条 - number of returned data items, default 5). This adds meaningful context beyond the schema's bare field names, but doesn't fully compensate for the complete lack of schema descriptions, especially for the ambiguous 'is_annals' parameter.
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's purpose as '按年度、季度获取业绩报表数据' (Get performance report data by year/quarter), which specifies both the verb (获取/get) and resource (业绩报表数据/performance report data). It distinguishes from siblings like 'balance' or 'income' by focusing on performance reports rather than specific financial statements. However, it doesn't explicitly differentiate from 'report' which might be similar.
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. With many sibling tools like 'balance', 'income', 'cash_flow', and 'report', there's no indication of when this performance report tool is appropriate versus those other financial data tools. The description only states what it does, not when to choose 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 provided, the description carries full burden for behavioral disclosure. It only mentions the date parameter format but doesn't describe what the tool returns, whether it's a read-only operation, any rate limits, authentication requirements, or error conditions. For a data retrieval tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately brief but could be better structured. The purpose statement is clear, but the parameter documentation is presented in a somewhat informal 'Args:' format. While efficient, it lacks the polished structure of more formal documentation.
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 annotations and output schema, the description is incomplete. It documents the single parameter adequately but fails to describe what data is returned, the format of results, or any behavioral characteristics. For a data retrieval tool, users need to know what to expect in response.
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 input schema, which has 0% description coverage. It explains the 'date' parameter's purpose (日期 - date), default behavior (默认当天 - defaults to current day), and format requirements (格式：'2022/01/19'). This compensates well for the schema's lack of documentation for the single parameter.
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's purpose as '获取沪港通北向数据' (Get Northbound Stock Connect data), which specifies both the verb ('获取' - get) and resource ('沪港通北向数据' - Northbound Stock Connect data). It distinguishes from sibling tools like 'northbound_shareholding_sh' by specifying the Shenzhen exchange focus. However, it doesn't explicitly mention this is for shareholding data specifically.
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. While it distinguishes from 'northbound_shareholding_sh' by context, there's no explicit comparison or guidance about when to choose one over the other, nor any mention of 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions '实时' (real-time) and '当前' (current), it doesn't specify data freshness, rate limits, authentication requirements, error conditions, or response format. For a real-time data tool with zero annotation coverage, this lack of behavioral detail is inadequate.
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 front-loaded with the core purpose in a single sentence. There's no wasted text, and it efficiently communicates the main function. However, it could be slightly more structured by separating purpose from details, but this is minor.
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 complexity of real-time financial data, no annotations, no output schema, and 0% schema coverage, the description is incomplete. It lacks details on data format, latency, error handling, and parameter usage, making it insufficient for reliable tool invocation in this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate for undocumented parameters. It doesn't mention the 'stock_code' parameter at all, nor does it explain its format, constraints, or examples. With 1 parameter and no coverage, the description adds no value beyond the schema, resulting in a baseline score of 3.
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's purpose: '获取实时分笔数据' (get real-time tick data) and specifies it retrieves '股票当前报价和成交信息' (current stock quotes and transaction information). This is a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'quotec' or 'quote_detail' that might also provide quote-related data, preventing a score of 5.
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. It doesn't mention any prerequisites, exclusions, or comparisons to sibling tools like 'quotec' or 'quote_detail', leaving the agent with no context for tool selection. This is a significant gap in usage guidance.
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 provided, the description carries the full burden of behavioral disclosure. It implies a read operation ('获取' - get) but doesn't specify if it requires authentication, returns real-time or cached data, has rate limits, or details the response format. This is inadequate for a tool with zero annotation coverage.
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 a single, efficient phrase ('获取用户自选列表') with zero wasted words. It's front-loaded and appropriately sized for its purpose, earning full marks for 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 complexity (a user-specific data retrieval tool), no annotations, and no output schema, the description is incomplete. It lacks details on authentication needs, return format, data scope, or how it differs from siblings, making it insufficient for effective agent use.
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 tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add param info, but that's acceptable here. Baseline is 4 for zero parameters, as it avoids unnecessary details.
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 '获取用户自选列表' (Get user watch list) states a clear verb ('获取' - get) and resource ('用户自选列表' - user watch list), but it's vague about what constitutes a 'watch list' (e.g., stocks, funds, other assets) and doesn't distinguish it from sibling tools like 'watch_stock' or 'suggest_stock', which might have overlapping purposes. It avoids tautology but lacks specificity.
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. It doesn't mention prerequisites (e.g., user authentication), exclusions, or compare it to sibling tools like 'watch_stock' or 'suggest_stock', leaving the agent with no context for selection.
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 the full burden. It mentions retrieving details but doesn't disclose behavioral traits such as whether it's a read-only operation, authentication requirements, rate limits, error conditions, or what format the details are returned in. For a tool with no annotation coverage, this leaves significant gaps in understanding its 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 concise and front-loaded with the main purpose in the first line. The additional parameter explanation is brief and directly relevant. There's no unnecessary verbosity, though it could benefit from more structured formatting.
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 annotations and output schema, the description is incomplete. It doesn't explain what '详情' (details) includes, potential return values, or error handling. For a tool with no structured metadata, more context is needed to fully understand its operation and results.
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 description adds minimal semantics: it states 'pid: 自选列表ID' (pid: watchlist ID), which clarifies that 'pid' refers to a watchlist identifier. However, with 0% schema description coverage and only 1 parameter, this provides basic but insufficient context. It doesn't explain valid ranges, examples, or how to obtain the ID, leaving room for improvement.
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's purpose: '获取用户自选列表详情' (Get user watchlist details). It specifies the verb '获取' (get) and resource '自选列表详情' (watchlist details). However, it doesn't explicitly differentiate from sibling tools like 'watch_list' or 'suggest_stock', which might have related 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 guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context, or comparisons to sibling tools like 'watch_list' or 'suggest_stock'. It only states what the tool does without indicating appropriate usage 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 the full burden of behavioral disclosure. While '获取' (get) implies a read operation, the description doesn't specify data format, source, freshness, rate limits, authentication requirements, or what happens when parameters are invalid. For a data retrieval tool with zero annotation coverage, this is a significant gap.
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 efficiently structured with a clear purpose statement followed by parameter explanations. Each sentence earns its place, though the parameter explanations could be slightly more detailed. The bilingual presentation (Chinese purpose, English parameter names) is slightly inconsistent but doesn't significantly impact clarity.
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?
For a financial data tool with 3 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what balance sheet data fields are returned, the data format, time periods covered, or how the tool handles errors or missing data. The parameter explanations help but don't provide full operational 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?
With 0% schema description coverage, the description provides essential semantic context for all three parameters: 'stock_code' identifies the security, 'is_annals' controls annual report filtering (with default 1), and 'count' determines result quantity (default 5). This compensates well for the schema's lack of descriptions, though it doesn't explain parameter constraints or 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 clearly states the tool's purpose as '获取资产负债表数据' (get balance sheet data), which is a specific verb+resource combination. It distinguishes itself from sibling tools like 'income' or 'cash_flow' by focusing specifically on balance sheet data. However, it doesn't explicitly differentiate from all possible financial data 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?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools like 'income', 'cash_flow', 'indicator', and 'main_indicator' that might provide related financial data, there's no indication of when balance sheet data specifically is needed versus other financial statements or metrics.
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 tool '获取' (gets/retrieves) data, implying a read-only operation, but doesn't disclose important behavioral aspects like authentication requirements, rate limits, data freshness, error conditions, or response format. For a financial data tool with no annotation coverage, this is insufficient.
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 efficiently structured with a clear purpose statement followed by parameter explanations. Every sentence serves a purpose: the first states what the tool does, and the subsequent lines document each parameter with default values. There's no wasted text.
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?
For a financial data retrieval tool with 3 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the returned income statement data looks like (structure, fields, time periods), doesn't mention data sources or reliability, and provides no error handling context. The parameter explanations help, but overall context is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by explaining all three parameters in Chinese: 'stock_code: 股票代码' (stock code), 'is_annals: 只获取年报,默认为1' (only get annual reports, default is 1), and 'count: 返回数据数量,默认5条' (return data count, default 5 items). This adds crucial semantic meaning beyond the schema's minimal titles.
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's purpose: '获取利润表数据' (Get income statement data). It specifies the verb ('获取' - get) and resource ('利润表数据' - income statement data), making the function unambiguous. However, it doesn't differentiate from sibling tools like 'balance' or 'cash_flow', which likely provide different financial statements.
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. With sibling tools like 'balance' (likely for balance sheet data) and 'cash_flow' (likely for cash flow statement data), there's no indication of when income statement data is specifically needed or how this tool relates to other financial data 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions what data is retrieved ('深港通北向数据') and basic parameter information. It doesn't describe what the tool returns (format, structure), whether it requires authentication, rate limits, error conditions, or any other behavioral characteristics beyond the minimal functional 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 appropriately concise with two sentences that each serve a clear purpose: the first states what the tool does, the second explains the parameter. There's no wasted language, though the structure could be slightly improved by more clearly separating the functional description from parameter documentation.
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?
For a data retrieval tool with no annotations and no output schema, the description is incomplete. It doesn't explain what format the northbound data returns, what fields are included, or how to interpret the results. Given the complexity of financial data and the lack of structured output documentation, the description should provide more context about the returned data structure.
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 input schema, which has 0% description coverage. It explains that the 'date' parameter defaults to the current day and specifies the required format ('2022/01/19'). This provides crucial semantic information that the schema alone doesn't convey, though it doesn't cover all potential parameter behaviors (like what happens with invalid dates).
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's purpose: '获取深港通北向数据' (Get Shenzhen-Hong Kong Stock Connect northbound data). It specifies the verb ('获取' - get) and resource ('深港通北向数据' - northbound data), making the purpose understandable. However, it doesn't explicitly differentiate from its sibling 'northbound_shareholding_sz' (which likely gets southbound data), so it doesn't reach the highest clarity level.
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. It doesn't mention the sibling tool 'northbound_shareholding_sz' or explain the difference between northbound and southbound data. There's no context about when this specific tool is appropriate versus other financial data tools in the sibling list.
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 provided, the description carries the full burden of behavioral disclosure. It only states what data is retrieved without mentioning whether this is a read-only operation, if it requires authentication, rate limits, error conditions, or what format the data returns. For a data retrieval tool with zero annotation coverage, this is insufficient behavioral context.
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 appropriately concise with a clear purpose statement followed by parameter explanations. The two-sentence structure is efficient, though the parameter section could be slightly better formatted. Every sentence adds value without unnecessary elaboration.
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 has no annotations, no output schema, and 2 parameters, the description is incomplete. It explains what data is retrieved and parameters but doesn't cover return format, error handling, authentication needs, or how this differs from similar tools like 'holders'. For a data retrieval tool in a financial context, more completeness is needed.
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 provides meaningful parameter information beyond the schema: it explains that 'stock_code' is for stock codes and 'circula' controls whether to get circulating shares only (with default 1). Since schema description coverage is 0%, this description compensates well by adding semantic context that the schema lacks through its titles and defaults alone.
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's purpose as '获取十大股东数据' (Get top ten shareholder data), which is a specific verb+resource combination. However, it doesn't explicitly differentiate this tool from the 'holders' sibling tool, which appears to be related. The purpose is clear but lacks sibling 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?
The description provides no guidance on when to use this tool versus alternatives like the 'holders' tool. It mentions parameters but gives no context about appropriate use cases, prerequisites, or when other tools might be more suitable. This leaves the agent without usage direction.
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:

[![xueqiu_mcp MCP server](https://glama.ai/mcp/servers/liqiongyu/xueqiu_mcp/badges/card.svg)](https://glama.ai/mcp/servers/liqiongyu/xueqiu_mcp)

Score Badge

Copy to your README.md:

[![xueqiu_mcp MCP server](https://glama.ai/mcp/servers/liqiongyu/xueqiu_mcp/badges/score.svg)](https://glama.ai/mcp/servers/liqiongyu/xueqiu_mcp)

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/liqiongyu/xueqiu_mcp'

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