iwencai-mcp

Server Quality Checklist

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

Latest release: v0.2.1
Disambiguation3/5
Most tools are clearly separated by asset class or action, but there is notable overlap: query_market_data explicitly includes indices alongside query_index_data, and query_insresearch_data overlaps with search_reports around research coverage. The consistent query/select/search prefixes help, but a few boundaries remain fuzzy.
Naming Consistency5/5
All tool names follow a clear, consistent lowercase snake_case pattern: query_*_data for data lookups, select_* for screening, and search_* for searching. The naming makes the intended action and domain immediately recognizable, with no style mixing or vague verbs.
Tool Count3/5
25 tools is at the heavy end of the acceptable range for a broad financial data platform. The count is justified by the wide scope covering market data, fundamentals, screening, and search, but it still feels like a large surface for an agent to navigate.
Completeness4/5
The tool set covers an impressively broad range: market, industry, macro, fund, futures, research, event, and basic data, plus screeners and searches. Minor gaps exist, such as no dedicated bond market data tool beyond basics and convertible bonds, but core workflows for Chinese financial data querying and screening are well supported.
Average 3.6/5 across 25 of 25 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
With no annotations, the description carries full behavioral disclosure burden. It mentions the data source (Tonghuashun iwencai) but does not state whether the operation is read-only, what the output format is, whether the query gets rewritten, or any rate limits or authentication requirements.
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 leads with the core purpose and then gives the data source. It is compact and free of filler, though it lacks structured sections such as examples or alternative routing, which prevents a 5.
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?
The description is minimal for a tool with no output schema and no annotations. It lacks an example query, expected output format, differentiation from select_fund/select_fundcompany/select_fundmanager, and any explanation of how the optional page/limit parameters affect results. This leaves an agent under-informed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already documented. The description only restates the natural-language input concept already present in the schema and adds no additional semantic meaning for page or limit parameters.
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 a specific action: comprehensive analysis of funds covering performance, holdings, risk, ratings, awards, fund managers, and fund companies, with natural language input. However, it does not differentiate from sibling tools like select_fund or query_finance_data, so it stops short of a 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?
No guidance is provided on when to use this tool versus alternatives such as select_fund or query_finance_data. The only usage hint is that input should be a natural-language question, but there are no exclusions, examples, or decision criteria for selecting among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full transparency burden. It discloses that input is a natural-language question and cites the data source, but it does not state read-only behavior, response format, pagination behavior, limits, or error characteristics. These are meaningful gaps for a query 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 compact and front-loaded: it lists the data scope first, then input mode, then source. All three sentences contribute useful information with no filler. It earns a 4 rather than 5 because it partially repeats the title's scope and does not add structure like usage examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, no nested objects), the description is minimally viable: an agent can invoke it with a natural-language query and understand the topic area. However, the absence of output schema, pagination guidance, and sibling differentiation leaves notable gaps, especially among many overlapping query_* tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description only reinforces that the query is a natural-language sentence, adding no new semantic detail about page, limit, or query formatting. Baseline 3 applies.
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 specifies a clear action ('查询') and a detailed resource scope: research report ratings, earnings forecasts, ESG, credit ratings, issuer ratings, fund ratings, and broker gold stocks. This makes the tool's purpose identifiable. However, it does not explicitly distinguish itself from sibling tools like query_fund_data or search_reports, so it falls short of a 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 gives no guidance on when to use this tool versus the many sibling query/search tools. It does not mention alternatives, exclusions, or conditions. The natural-language input and data source are context, but not 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 exist, so the description must carry the burden of behavioral disclosure. It adds the data source and the supported screening dimensions, but it does not disclose output format, whether the operation is read-only, pagination behavior, or any query limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler; the purpose is stated first and the data source second. It is appropriately concise, though at the cost of missing usage and behavior 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?
For a tool with no output schema and no annotations, the description leaves important gaps: return value shape, how page/limit affect results, and when to use this tool vs. data-query siblings. The source link helps but does not make this complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's mention of multi-condition screening aligns with the 'query' parameter but adds no detail beyond the schema, which already documents query, page, and limit.
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 identifies the tool as a screening/selection tool for futures and options using multiple conditions such as quotes, volatility, production/sales, member positions, and exercise data. It distinguishes itself from generic query siblings by the 'select' verb and 'futures/options' scope, but it does not explicitly compare itself to related tools like query_futures_data or select_astock.
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 when-to-use guidance or alternatives are provided. The description only restates what the tool does and its data source; an agent must infer when to choose this over query_futures_data or the other select_* 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. It identifies the data source (同花顺问财) and describes the screening behavior, but it does not disclose return format, pagination behavior, whether the operation is read-only, or any limitations.
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 focused sentence, lists meaningful examples without filler, and includes the relevant data source URL. Everything present earns its place.
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?
There is no output schema and no annotation coverage, so the description should compensate by explaining what the tool returns and how it behaves regarding pagination and scope. It does not, and it also lacks guidance relative to the many sibling screening and query tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds useful meaning beyond the schema by enumerating the kinds of dimensions the natural-language query can cover, which helps an agent construct an effective query.
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 a specific verb ('筛选') and resource ('公募基金'), and lists concrete screening dimensions such as fund type, performance, fund manager, risk, holdings, and asset allocation. It is clear but does not explicitly differentiate itself from sibling tools like query_fund_data or select_etf.
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 gives no guidance on when to use this tool versus alternatives. It implies a screening use case but does not mention exclusions, prerequisites, or when query_fund_data or other selective tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only states that the tool aggregates reports and returns certain data; it does not disclose behavioral details such as whether the external source is queried live, any rate limits, pagination behavior, or scope limitations beyond 'mainstream institutions'. The data source URL is helpful but not behavioral.
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 two sentences with the core purpose front-loaded and no redundant filler. The inclusion of the data source URL is useful context, though not strictly needed for invocation, which keeps it from a perfect score.
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 two-parameter tool with fully described schema, the description is mostly adequate: it names the resource, the data source, and the type of returned content. However, with no output schema, it would benefit from stating search result structure or any constraints (e.g., date range, source coverage), and it lacks any mention of alternatives.
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 already documents both query and size with 100% coverage, so the baseline is 3. The description adds no additional parameter semantics beyond what the schema provides, so it neither improves nor detracts.
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 a clear verb and resource: it searches research reports (研报) and returns investment decision information such as analysis logic, investment ratings, and target prices. It does not explicitly differentiate itself from sibling tools like query_insresearch_data, but the focus on mainstream institutional reports and specific output fields makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: if an agent needs research reports or investment ratings, this is the tool. However, the description provides no explicit when-to-use/when-not-to-use guidance or mention of alternatives like search_news or query_insresearch_data, leaving the choice to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral transparency burden. It does disclose the data source (同花顺问财) and input modality (natural language), but does not mention limitations, error behavior, pagination defaults, or whether results are delayed or real-time in a strict sense.
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 compact, front-loaded with the core purpose and returned data fields, and contains no redundant filler. Every sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter read tool, the description covers the essentials: what data is returned and how to ask. However, given the large sibling set and no output schema/annotations, it would benefit from stating boundaries versus related query_* tools and the expected response shape.
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 already documents all three parameters with 100% coverage. The description adds that queries are natural-language questions, but does not meaningfully elaborate on page or limit semantics beyond what the schema provides.
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 a specific action ('获取实时行情') and a concrete resource set (stocks, ETFs, indices), and lists the returned fields. However, it does not differentiate from sibling tools like query_index_data or query_fund_data, which overlap in 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?
No usage guidance is provided. The description does not state when to prefer this tool over siblings, what types of questions are appropriate, or any exclusions. The only hint is that natural language queries are accepted.
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 data source (同花顺问财) and that input is a natural-language question; it does not disclose what the returned data looks like, whether the call is read-only, how pagination behaves, or any external-service limitations. This is a significant gap for an unannotated tool.
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 compact and front-loaded: the first sentence immediately enumerates the data domains, and the second gives input style and source. Every sentence earns its place with no filler or redundant restatement of the tool name.
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?
With no output schema and no annotations, the description is too sparse to fully prepare an agent. It does not explain the response format, pagination semantics, or the trade-offs between query_futures_data and the many sibling query/select tools. The listed data categories and source are useful, but not sufficient for robust tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3; the schema already documents query, page, and limit. The description's mention of natural-language input merely restates the query parameter's purpose and adds no meaningful semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('查询') and a clearly scoped resource: futures and options data, with explicit subcategories such as quotes, volatility, production/sales, member positions, member rankings, and exercise data. The domain focus distinguishes it from broader siblings like query_market_data or query_basicinfo_data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through '输入自然语言问句' and the futures/options data scope, but it never tells the agent when to prefer this tool over siblings such as select_futures or query_market_data. There are no exclusions or alternative routing hints, so usage guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 for behavioral disclosure. It adds the data source and criteria categories, but it does not describe return format, pagination behavior, data freshness, error conditions, or limitations of the underlying 同花顺问财 data.
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 two concise clauses: the first states the tool's purpose and filtering dimensions, the second identifies the data source. It is front-loaded, uses no filler, and every element contributes to agent understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple selection tool, the description gives the core purpose and data source, and the schema covers page and limit. However, with no output schema and no behavioral annotations, it leaves return-value structure and operational details implicit, which is a noticeable gap for an agent deciding how to present or post-process results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds real value by expanding the meaning of 'query': it tells the agent that queries can incorporate market conditions, index fundamentals, size, style types, and similar criteria, which goes beyond the schema's generic natural-language description.
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 identifies a specific verb ('筛选') and resource ('ETF'), and names the filtering dimensions: market conditions, index fundamentals, size, and style. It does not explicitly contrast with sibling tools, but 'ETF' distinguishes it from stock, fund, and other selection tools well enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The implied usage is clear: use this tool when the user wants to filter ETFs by various financial criteria. However, there is no explicit guidance about when to choose this over select_fund, select_astock, or query_fund_data, and no stated exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It does disclose the external data source (同花顺问财) and the natural-language input style, which is useful. But it does not mention output shape, pagination behavior, error handling, or whether the query is executed live against the external service.
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 three short sentences, each with a clear purpose: scope, input format, and data source. There is no filler or redundant phrasing, and the most identifying information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple one-required-param tool with clearly listed data domains. However, there is no output schema and no annotations, and the description does not cover what the result looks like, whether pagination applies to the natural-language query results, or how to handle ambiguous queries. It also relies on the reader to infer how this differs from nearby siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains all three parameters. The description adds only a redundant restatement of the natural-language input requirement and does not provide any deeper meaning about page or limit beyond what the schema already states.
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 a clear verb+resource: query business operating data, and enumerates concrete categories (主营业务构成、主要客户、供应商、参控股公司、股权投资、重大合同). It is fairly distinguishable from siblings like query_market_data or query_finance_data, though it could more explicitly separate itself from query_management_data and query_basicinfo_data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when business operating data such as major clients, suppliers, or equity investments is needed. It also instructs that input should be a natural-language question. However, it gives no explicit guidance about when not to use it or which sibling tools are better alternatives for adjacent data types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses the data source (同花顺问财) and the natural-language modality, but it does not describe the output format, pagination behavior, or any limitations of the underlying service.
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 compact: one sentence for scope, one for input mode, and one for data source. Every sentence contributes non-redundant information, and the core action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and its parameters are fully documented, but there is no output schema and the description does not explain what the response looks like. In a family of many sibling data-query tools, the lack of explicit differentiation also weakens completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds no meaningful parameter semantics beyond what the schema states about natural-language queries and page/limit defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('查询') on a distinct resource ('行业数据') and enumerates concrete content categories such as 估值、财务、盈利、行情、板块排名. It is clear overall, but the catch-all '等数据' and overlap with sibling tools like query_finance_data and query_market_data keep it from fully distinguishing itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The scope statement implies use for industry-level data questions and the natural-language input mode is clear. However, no explicit when-to-use, when-not-to-use, or sibling alternatives are given, so an agent must infer the choice among many similar query_*data tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses that data comes from an external source (同花顺问财) and that input should be a natural-language question. However, it does not mention return format, pagination behavior, potential rate limits, or the fact that the query may be rewritten into a standard financial question.
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 two concise sentences with no filler: the main purpose is front-loaded and the data source is appended in a separate line. Every phrase contributes useful 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?
Because there is no output schema and no annotations, the description should explain what the tool returns or how results are presented, but it only states what is queried and the data source. It also does not provide an example query or clarify pagination behavior, leaving the agent under-informed for a real external data-query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so page, limit, and query are already documented in the input schema. The tool description adds no parameter-specific meaning beyond restating natural-language input, which the schema already covers. Thus the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (查询) and a specific resource (全市场个股财务指标), and lists concrete example indicators such as 营业收入, 净利润, ROE, 负债率, and 现金流. This clearly differentiates it from sibling query_* tools that target market, industry, macro, index, fund, or futures data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by saying natural-language questions are accepted and giving example metric categories, so an agent can infer when to invoke it. However, it does not explicitly name alternatives or state when not to use this tool, leaving the agent to guess among the many query_* and select_* siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds useful context by stating the data source and that natural-language input is supported, but it does not describe return format, pagination behavior, or any limitations.
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 compact and front-loaded: it states what data is covered, then the input style, then the data source. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a natural-language query tool, the description covers domain, input style, and provenance, and the schema fully documents parameters. It could be improved by stating what the response looks like, since there is no output schema, but the core selection and invocation context is clear.
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 already covers all three parameters with descriptions, including the fact that 'query' can be rewritten into a standard financial question. The tool description adds little beyond confirming natural-language input, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete action ('查询') and a specific resource: equity/capital-structure data, including shareholding structure, shareholder counts, top shareholders, major holders, and actual controllers. This distinguishes it from market, industry, macro, and fund siblings, though it does not explicitly cite an alternative sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it clear that the tool is for natural-language equity/shareholder questions and identifies the data source, so the intended context is inferable. However, it gives no explicit when-to-use/when-not-to-use guidance or named alternatives among the many query_* siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry behavioral disclosure. It discloses return fields (title, URL, summary, source, publication time) and data source, but does not mention ordering, pagination, or any access limitations. This is moderate but not comprehensive.
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?
Three short sentences deliver purpose, coverage, output, and provenance with no filler. The most important function (financial news search) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple 2-parameter tool with no output schema, the description covers the essential invocation facts: query type, return fields, and source. It lacks detail on result ordering or behavior beyond the schema default, but this is not critical for successful invocation.
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 already fully describes both parameters: query as a natural-language question and size with a default of 10. The description adds no parameter-level semantics, so it meets but does not exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific resource: a financial news/information search engine, listing coverage and return fields. It does not explicitly name sibling tools or exclusion criteria, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The text implies use for financial news queries by describing content coverage (official media, financial media, vertical sites, company websites), but it does not state when to prefer this over search_announcements, search_reports, or query_* tools. No exclusions or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It does disclose that data comes from 同花顺问财 and that the operation is a screening/selection task, which implies a read-only query behavior. However, it does not describe the return shape, possible latency, external dependency risks, or any limitations.
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 two tight sentences, front-loading the core purpose and then adding the essential data-source context. There is no redundant wording or repetition of the title or parameter names.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple select-style tool, the description covers purpose and data source, and the schema covers all parameters. However, with no output schema and no annotations, the description does not explain what the tool returns (e.g., a list of manager names, detailed profiles, or rankings) or how to interpret failures. This leaves a meaningful gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by enumerating the semantic dimensions that should be encoded in the natural-language query (historical performance, management scale, investment style, risk control), which helps the agent construct a better query parameter. It does not explain page/limit, but those are already described in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('筛选公募基金经理') and its filtering dimensions (historical performance, management scale, investment style, risk control). It is distinct from sibling tools like select_fund and select_fundcompany because it names '基金经理' as the target resource, though it does not explicitly contrast itself with those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: use this tool when the user wants to screen public fund managers by various qualitative and quantitative criteria. However, it provides no explicit guidance on when to prefer this tool over siblings such as select_fund or query_fund_data, nor any exclusion criteria.
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 bears the full burden of behavioral disclosure. It only reveals the data source and screening criteria; it does not mention output format, pagination behavior, side effects, rate limits, or whether the operation is read-only. This is a significant gap for a no-annotation, no-output-schema tool.
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 two concise sentences, with the core action front-loaded and the source attribution provided without redundancy. Every sentence earns its place.
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 that there is no output schema and no annotations, the description does not explain what the tool returns or how results are presented. It also omits usage guidance relative to sibling tools, leaving the agent with enough to invoke the tool but not enough to fully plan follow-up actions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by specifying what kinds of conditions the natural-language query should support (industry valuation, capital flow, price change, sector type), which helps the agent construct a valid query. It does not add detail on page/limit, but those are already fully documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('筛选') and resource ('市场板块'), and enumerates the condition types (valuation, capital flow, price change, sector type). This clearly distinguishes it from sibling tools like select_astock and select_etf, which target different asset classes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for screening sectors by multiple conditions, but it never explicitly states when to use it over alternatives such as query_market_data or query_industry_data. No exclusion criteria or alternative routing is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It usefully discloses the data source (同花顺问财) and the natural-language input style. However, it does not describe pagination behavior, response format, or any limitations such as data coverage or query constraints.
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 two concise sentences with no filler. The core scope and examples are front-loaded, and the data-source URL is useful supplementary context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's domain, examples, input style, and source, which is adequate for a simple query tool. However, with no output schema and no annotations, it would benefit from describing what the returned data looks like and how page/limit affect 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?
Schema description coverage is 100%, so the baseline is 3. The description repeats the natural-language aspect already in the query parameter and adds no additional parameter-level meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb '查询' and the specific resource '指数行情' with concrete examples (上证指数、沪深300、创业板指、恒生指数、纳斯达克指数). It also lists the kinds of data covered (涨跌幅/成交量/点位), which distinguishes it from sibling data-query tools by domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended usage—querying index market data via natural language—is implied by the resource scope. However, there is no explicit guidance on when to prefer this tool over alternatives like query_market_data, nor any 'when not to use' statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It usefully discloses that data comes from 同花顺问财 (iwencai.com) and that selection is condition-based. However, it does not describe expected output shape, result behavior, external dependency risks, or whether any side effects occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and efficient: one sentence defines what the tool does and another gives the data source. There is no redundant phrasing or filler, and the main purpose appears first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter query tool, the description is reasonably complete regarding purpose and data source, but there is no output schema and the description does not explain what the returned result contains. It also lacks guidance on query formulation beyond the schema's note about rewriting into standard financial queries.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds some context about what the query may contain (multiple filter conditions), but it does not add meaningful detail beyond the schema's descriptions for page, limit, or query.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: selecting convertible bonds via multiple financial criteria, and the title specifies the asset class. It is distinct from sibling select_* tools by explicitly targeting 可转债 (convertible bonds), so an agent can tell it apart from select_astock, select_etf, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use this tool when filtering convertible bonds using conditions like conversion premium, underlying stock performance, rating, and remaining maturity. However, there are no explicit when-to-use versus alternatives instructions, nor any mention of when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden; it does disclose the data source (同花顺问财 with URL) and the filtering dimensions, which adds useful context. However, it does not describe the return shape, pagination behavior, or any limits, and does not explicitly confirm there are no side effects, so full transparency is not achieved.
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 two short sentences with the core function and criteria front-loaded, and only a useful data-source attribution after. Every sentence earns its place, with no redundancy or irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter read tool, the description covers the core purpose and data source, and the schema fully documents parameters. However, there is no output schema and the description never states what the result set looks like, so an agent is left guessing about the tool's return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds domain context by listing selection dimensions that a natural-language query may include, but it does not add any page/limit semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific action (筛选, screen/filter) and a specific resource (公募基金公司, public fund companies), and names concrete criteria. This clearly distinguishes it from sibling tools like select_fund or select_fundmanager, which target funds and managers respectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied rather than stated: an agent can infer it should use this tool when the user wants to screen public fund companies. However, there is no explicit when-to-use guidance, no exclusions, and no reference to alternative select_* tools, leaving routing decisions mostly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does disclose the natural-language screening behavior, supported multi-condition combinations, and data source. However, it does not describe the return format, pagination behavior, rate limits, or error conditions, which are relevant for an agent invoking the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences that front-load the tool's purpose and capabilities, then cite the data source. There is no redundancy with the tool name or title, and every sentence adds meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter tool with one required parameter, the description covers the core use case and data source. However, with no output schema and no annotations, the description should ideally clarify what the agent will receive after a successful query, such as the structure or fields of the returned stocks, making completeness adequate but not strong.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents query, page, and limit. The description reinforces that query is a natural-language screening statement and adds that multiple conditions can be combined, but it does not provide additional parameter-level syntax or format details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: '通过自然语言查询进行美股筛选' (filter US stocks via natural-language queries). It also lists concrete screening dimensions such as market indicators, financial indicators, industry concepts, earnings forecasts, and research ratings, which clearly distinguishes it from sibling tools like select_astock and select_hkstock by market scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: use this when the user wants to screen US stocks using natural language, and the data source is provided. However, there is no explicit when-to-use/when-not-to-use guidance, nor mention of alternatives such as select_astock or select_hkstock, leaving sibling selection to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that the input is natural language and that the data comes from 同花顺问财, and the verb '查询' implies a read-only operation. However, it does not describe return shape, pagination behavior, or what happens when the query is rewritten.
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 two sentences with no filler. The first sentence front-loads the core purpose and event types; the second adds the data source and input mode. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description distinguishes the tool well among many siblings and covers the core input behavior, but without an output schema or annotations it should ideally say more about what the agent can expect in the result and how pagination works. The gaps are not fatal, but they are noticeable for a tool backed by an external data source.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description reinforces the meaning of 'query' by stating that it is a natural-language question, but it adds no additional semantic context for 'page' or 'limit' beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('查询') and a specific resource ('个股...事件数据') with concrete examples such as 业绩预告、增发、质押、解禁、调研、监管函. This clearly distinguishes it from sibling tools like query_market_data and query_finance_data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes clear that this tool is for event data expressed as natural-language questions, which gives the agent strong situational context. It does not explicitly name alternatives or say when not to use it, but the boundary is reasonably clear from the event-data examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the transparency burden. It does disclose that the tool accepts natural language questions and that data comes from a specific external source (同花顺问财). However, it omits output format, pagination behavior, error handling, and any explicit read-only/non-destructive statement.
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 two tightly written sentences: it front-loads the core purpose and examples, then adds input style and data source. No filler or redundant restatement of the title appears.
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 low-complexity query tool with complete schema coverage, the description covers the domain, input style, and data source. However, there is no output schema and no annotations, and the description does not describe what the tool returns or what result format to expect, leaving a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all three parameters, so the baseline is 3. The description adds little beyond the schema; it restates that input is a natural-language question but does not enrich page, limit, or query semantics further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb '查询' (query) and a concrete resource: GDP, CPI, PPI, interest rates, exchange rates, social financing, M2, and other macroeconomic indicators. This clearly distinguishes it from sibling tools like query_market_data and query_industry_data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the tool's context clear: it is for macroeconomic indicator queries, with examples of covered indicators. It does not explicitly name alternatives or state when not to use it, but the domain is distinct enough from sibling tools to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the disclosure burden. It does add useful context by noting that input is a natural-language question and that data comes from 同花顺问财. However, it does not mention pagination behavior, response format, data freshness, rate limits, or any side effects, leaving behavioral coverage partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main purpose, and each clause adds useful scope: asset categories, example information types, input format, and data source. The URL and category list are informative rather than redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-style query tool with one required parameter and no output schema, the description covers what data is returned, what input is expected, and where the data comes from. It could be stronger by explicitly routing the agent among the many sibling query tools, but '静态信息' provides enough differentiation for correct invocation in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents query, page, and limit. The description's statement about natural-language input largely restates the query parameter's schema description and adds no new parameter-level meaning, so it meets the baseline without exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific verb ('查询') and resource: basic/static information across all asset classes, listing concrete fields such as '基础信息、发行主体、机构资料、费率、上市地点/日期'. The phrase '静态信息' clearly differentiates this from sibling tools focused on market, finance, industry, or macro data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: use this tool when needing static fundamental/basic information about a wide range of instruments, and provide a natural-language question. It does not explicitly name sibling alternatives or give when-not-to-use exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It discloses the data source and the return fields, which is useful, but it does not mention limitations such as coverage time range, result completeness, potential delays, or behavior when no announcements match.
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 compact and well-structured: the first sentence covers scope, types, and return fields, while the second cites the source. No filler or redundant phrasing is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter search tool with no output schema, the description provides the essential contract: scope, announcement types, returned fields, and data source. A short example query or caveats about result limits would improve it, but nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters ('query' and 'size'), so the schema already documents their meaning. The description adds no extra parameter-level detail, which is acceptable given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation ('查询') and the resource ('公告'), and goes further by listing the supported markets, announcement categories, and returned fields. This makes it straightforward to distinguish from sibling tools like search_news and search_reports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this tool for announcements of A-shares, HK stocks, funds, ETFs, and similar financial instruments. It does not explicitly name alternatives or exclusions, but the resource type and category list are specific enough to enable correct tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does disclose the data source (同花顺问财) and that the tool performs natural-language screening across multiple condition types. However, it does not mention limitations, failure modes, pagination behavior, or whether the result is a list of securities, which would improve 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 dense sentence with a source URL appended. Every element is useful: the operation, the input style, the supported condition types, and the data provenance. No redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple: one required string parameter and two optional pagination parameters. Thedescription plus schema covers what the tool does and what to pass. It lacks a stated return format, but 'A 股筛选' strongly implies a list of stocks, so the gap is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents query, page, and limit. The description confirms the query is a natural-language question but adds no format examples, default behavior, or nuance beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: screening A-shares via natural language queries, with explicit mention of supported condition types (market indicators, technical patterns, financial metrics, industry concepts). This distinguishes it from sibling tools like select_hkstock and select_usstock by focusing on the A-share market.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use case is clear: screen A-shares using natural language. However, it does not explicitly explain when to choose this tool over alternatives such as select_etf or query_* data tools. The distinction is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It usefully discloses the data source (同花顺问财) and the natural-language query style, implying a read-only screening operation. However, it does not describe output format, pagination behavior, or error/rate-limit characteristics.
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 two sentences with no redundancy. It front-loads the core purpose and follows with the data source and supported filter categories, making it efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity screening tool with three documented parameters and no output schema, the description covers the essential purpose, query categories, and data source. It omits explicit sibling routing and output details, but these are not critical given the simple, read-only nature of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters themselves are documented. The description adds meaningful semantic context by enumerating supported query dimensions and multi-condition combination, helping the agent craft an appropriate natural-language query value beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: screening Hong Kong stocks via natural language queries. It lists concrete filter dimensions (行情指标、财务指标、行业概念、陆港通), making it clearly distinguishable from siblings like select_astock and select_usstock by asset class and query style.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: when a user wants Hong Kong stock screening with natural language and multi-condition filters. It does not explicitly name sibling alternatives or state when not to use it, so it stops short of a 5.
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:

[![iwencai-mcp MCP server](https://glama.ai/mcp/servers/homeant/iwencai-mcp/badges/card.svg)](https://glama.ai/mcp/servers/homeant/iwencai-mcp)

Score Badge

Copy to your README.md:

[![iwencai-mcp MCP server](https://glama.ai/mcp/servers/homeant/iwencai-mcp/badges/score.svg)](https://glama.ai/mcp/servers/homeant/iwencai-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/homeant/iwencai-mcp'

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