deepq-financial-toolkit

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
The tools are organized by asset types (A-share, ETF, fund, stock, sector) and analysis dimensions (basic info, performance, technical, fundamental, news), which helps distinguish them. However, there is notable overlap within categories, such as 'etfBasicInfo' and 'etfLatestPrice' both covering similar ETF data, and 'stockFunAnalysis' and 'stockValuation' both addressing valuation metrics, which could cause confusion in tool selection.
Naming Consistency4/5
Most tools follow a consistent snake_case pattern with clear prefixes indicating the asset type (e.g., 'aShare', 'etf', 'fund', 'stock', 'sector'), which aids readability. Minor inconsistencies include 'guessFundCode' and 'guessStockCode' using 'guess' instead of a more standard verb like 'parse', and 'mktForwardLook' abbreviating 'market' differently than other tools, but overall the naming is predictable and well-structured.
Tool Count2/5
With 44 tools, the count is excessive for a single server, leading to potential overwhelm and redundancy. While the domain of financial analysis is broad, the tools could be consolidated or split into more focused servers (e.g., separate servers for A-shares, ETFs, funds, stocks, and sectors) to improve usability and reduce overlap.
Completeness5/5
The tool set comprehensively covers the financial analysis domain, offering CRUD-like operations across multiple asset types (A-shares, ETFs, funds, stocks, sectors) and analysis dimensions (basic info, performance, technical, fundamental, news, research). There are no obvious gaps; tools address data retrieval, entity parsing, market events, and various analytical perspectives, ensuring agents can handle diverse financial queries without dead ends.
Average 2.3/5 across 44 of 44 tools scored.
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 ISC License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure, but it adds nothing beyond the tool's name. It doesn't describe whether this is a read-only operation, what data format it returns, any rate limits, authentication requirements, or side effects. For a tool with no annotation coverage, this lack of behavioral information is a critical gap that leaves the agent guessing about 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is extremely concise (a single repeated phrase), this brevity stems from under-specification rather than effective communication. It fails to front-load critical information about the tool's purpose or usage, and the single sentence doesn't earn its place by providing any actionable insights. The structure is minimal but not helpful.
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's an output schema (which helps), no annotations, and a simple input schema, the description is incomplete. It doesn't explain what the tool returns (e.g., index values, timestamps, or metadata) or how to interpret results, leaving gaps despite the output schema's existence. For a tool with no behavioral context, more descriptive content is needed to guide 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 input schema has 100% description coverage, with the single parameter 'date' clearly documented as '指定日期，默认当天' (specified date, defaulting to today). The description adds no additional parameter information beyond what the schema provides. Since schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't need to compensate but also doesn't add value regarding parameters.
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?
Tautological: description restates name/title.
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. It doesn't mention any context, prerequisites, or exclusions for usage, nor does it reference sibling tools like 'aShareMarketEvents' or 'aShareTemperature' that might serve related purposes. Without any usage instructions, the agent is left with no information to make informed decisions about tool selection.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure but provides none. It doesn't indicate whether this is a read-only operation, what permissions might be required, whether it has rate limits, what format the output takes, or any behavioral characteristics. The description is merely a restatement of the title with no operational information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise (a single phrase), this represents under-specification rather than effective conciseness. The description doesn't front-load important information or provide any meaningful structure - it's just a repetition of the title. Every sentence should earn its place, but here there's essentially no sentence, just a label restatement.
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 this tool has no annotations, a single parameter with good schema coverage, and an output schema exists, the description is incomplete. For a tool that presumably returns detailed asset holdings data, the description should at minimum clarify what '重仓' (heavy holdings) means, what time period the data covers, and the scope of the returned information. The existence of an output schema helps, but the description itself is inadequate for understanding the tool's purpose and behavior.
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 100% with the single parameter 'query' well-documented as 'ETF基金代码或ETF基金名称' (ETF fund code or ETF fund name). The description adds no parameter information beyond what's already in the schema. With high schema coverage, the baseline score of 3 is appropriate since the schema does the heavy lifting, though the description provides zero additional parameter context.
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?
Tautological: description restates name/title.
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 absolutely no guidance about when to use this tool versus alternatives. There's no mention of when this tool is appropriate, what distinguishes it from similar tools like 'fundUnderAssets' or 'etfBasicInfo', or any prerequisites or context for its use. The description is identical to the title and offers zero usage context.
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. However, it offers no information about behavioral traits such as whether this is a read-only operation, if it requires authentication, rate limits, data freshness, or what the output entails (e.g., textual analysis, numerical scores, or structured data). The description merely states the purpose without any 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase that repeats the title, making it under-specified rather than concise. It lacks structure and fails to front-load critical information, such as the tool's specific function or key usage notes. While brief, it does not earn its place by adding value beyond what is already implied by the name and title.
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 (likely involving market analysis) and the presence of an output schema (which reduces the need to describe return values), the description is incomplete. It does not address behavioral aspects, usage guidelines, or differentiate from siblings, leaving significant gaps for an agent to understand when and how to use this tool effectively. The output schema may cover return structure, but the description fails to provide necessary context for proper 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?
The input schema has 100% description coverage, with the 'date' parameter documented as '指定日期，默认当天' (specify date, default today). The description adds no additional meaning beyond this, as it does not mention parameters at all. Given the high schema coverage, the baseline score of 3 is appropriate, as the schema adequately handles parameter documentation without need for description compensation.
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?
Tautological: description restates name/title.
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. It does not mention any context, prerequisites, or exclusions, nor does it differentiate from sibling tools such as 'macroResearch' or 'sectorReportAnalysis' that might offer related market insights. Without any usage instructions, an agent cannot determine appropriate scenarios for invocation.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure but fails completely. It doesn't indicate whether this is a read-only operation, what permissions might be required, rate limits, pagination behavior, or what happens when parameters are omitted. The description provides no behavioral context beyond the basic action implied by '检索' (search).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise (a single phrase), this is an example of under-specification rather than effective conciseness. The description doesn't earn its place - it provides no useful information beyond what's already in the tool name and title. Good conciseness balances brevity with information density, which this description lacks entirely.
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 this tool has 5 parameters, no annotations, and operates in a domain with many similar sibling tools, the description is woefully incomplete. While an output schema exists (which reduces the need to describe return values), the description fails to provide essential context about when to use this tool, what makes it unique, or any behavioral characteristics. For a search/retrieval tool with multiple parameters and no annotations, this description is inadequate.
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 100%, meaning all parameters are documented in the input schema itself. The description adds no additional parameter semantics beyond what's already in the schema. According to the scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no parameter information in the description.
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?
Tautological: description restates name/title.
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 absolutely no guidance on when to use this tool versus alternatives. With multiple sibling tools that retrieve financial information (etfRelatedNews, sectorNewsAnalysis, weMediaSecuNews, etc.), there's no indication of what makes this tool unique or when it should be preferred over those alternatives. No context, exclusions, or prerequisites 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?
With no annotations provided, the description carries full burden for behavioral disclosure but offers none. It doesn't indicate whether this is a read-only operation, what permissions might be required, whether it has rate limits, what format the attribution messages come in, or how the data is sourced. The description provides zero behavioral context beyond the basic function stated in the title.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise (a single sentence), this is under-specification rather than effective conciseness. The description fails to front-load critical information and doesn't earn its place by adding value beyond the title. It's too brief for a tool with three parameters and no annotations, leaving the agent with insufficient guidance.
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 sector analysis with attribution), lack of annotations, and presence of an output schema, the description is inadequate. While the output schema may document return values, the description should still explain the tool's purpose, behavioral characteristics, and usage context more thoroughly. For a financial analysis tool with attribution capabilities, this minimal 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?
Schema description coverage is 100%, so the schema already documents all three parameters (endDate, query, startDate) with basic descriptions. The description adds no additional parameter semantics beyond what's in the schema - it doesn't clarify date format requirements, what constitutes valid 'query' values, or how the parameters interact. Baseline 3 is appropriate when schema does the documentation work.
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?
Tautological: description restates name/title.
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 absolutely no guidance about when to use this tool versus alternatives. With multiple sibling tools available (sectorPriceChangeRank, sectorCapAnalysis, sectorFunAnalysis, etc.), there's no indication whether this tool is for historical analysis, current status, or comparative purposes, nor any prerequisites or exclusions 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 the full burden of behavioral disclosure. However, it fails to describe any behavioral traits such as whether this is a read-only operation, if it requires specific permissions, potential rate limits, or what the output entails (e.g., scores as numerical values or ratings). The description only lists output components without explaining the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise but under-specified, consisting of a single phrase that mirrors the title. While it avoids verbosity, it fails to provide essential information, making it inefficient in conveying purpose or usage. Conciseness should not come at the cost of clarity, so this scores low due to lack of substantive content.
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 implied by analyzing multiple scores for stocks, the description is incomplete. No annotations are provided to clarify behavior, and while an output schema exists (which might explain return values), the description doesn't adequately cover the tool's purpose, usage, or behavioral aspects. For a tool that likely involves data retrieval or analysis, more context is needed to guide 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 input schema has 100% description coverage, with the parameter 'query' clearly documented as 'A股股票名称或代码' (A-share stock name or code). The description adds no additional meaning beyond this, as it doesn't mention parameters at all. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema adequately handles parameter semantics without need for description enhancement.
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?
Tautological: description restates name/title.
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. It doesn't mention any context, prerequisites, or comparisons to sibling tools like stockFunAnalysis or stockTechAnalysis, which might offer overlapping or complementary functionality. This leaves the agent with no basis for selection among similar tools.
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. However, it only states the tool's purpose without describing any behavioral traits. It doesn't mention whether this is a read-only operation, what data sources are used, potential rate limits, authentication requirements, error conditions, or the format of returned risk information. For a tool with no annotations, this lack of behavioral context 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise (one sentence), the description is under-specified rather than efficiently informative. It repeats the title without adding any meaningful content that would help an AI agent understand or use the tool effectively. Every sentence should earn its place, and this single sentence fails to provide value beyond what's already in the tool name and title.
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 annotations are absent and the tool has an output schema (which reduces the need to describe return values), the description should still provide more context about what constitutes 'risk information' and how this tool differs from other stock analysis tools. The description is too minimal for a tool that presumably provides important risk assessment functionality. It doesn't establish the tool's role within the broader ecosystem of sibling 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% with one parameter ('query' described as 'A股股票名称或代码' - A-share stock name or code). The description adds no parameter semantics beyond what the schema already provides. Since schema coverage is high, the baseline score of 3 is appropriate - the schema adequately documents the parameter, and the description doesn't need to compensate but also adds no extra value.
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?
Tautological: description restates name/title.
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. It doesn't mention any prerequisites, context for application, or comparison to sibling tools like 'stockBizHighlight', 'stockRepInsight', or 'stockValuation' that might also provide risk-related insights. There's no indication of when this tool is preferred or what its limitations are, leaving the agent with no usage direction.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure but provides none. It doesn't indicate whether this is a read-only operation, whether it has rate limits, authentication requirements, what format the results come in, or any behavioral characteristics. The description is purely functional without any 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise (a single phrase), this represents under-specification rather than effective conciseness. The description doesn't front-load critical information and fails to provide any meaningful context. Every word in the description merely repeats information already available in the name and title, making it inefficient despite its brevity.
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 this is a 5-parameter tool with no annotations, the description is woefully incomplete. While there is an output schema (which reduces the need to describe return values), the description fails to provide essential context about what this tool actually does, when to use it, or how it behaves. For a tool with multiple parameters and no annotation coverage, this minimal description is inadequate.
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 100% description coverage, with all 5 parameters clearly documented in the schema itself. The description adds no additional parameter information beyond what's already in the schema. According to the scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no parameter information in the description.
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?
Tautological: description restates name/title.
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 multiple sibling tools dealing with securities information (officialSecuNews, etfRelatedNews, sectorNewsAnalysis, etc.), there's no indication of what makes this tool unique - whether it's for unofficial sources, specific content types, or particular use cases. The description offers zero contextual guidance.
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. However, it offers no information about what the tool does operationally (e.g., whether it fetches, computes, or displays data), its data sources, update frequency, or output format. This lack of detail leaves the agent with no understanding of the tool's behavior beyond its vague name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise but under-specified, not efficient. It consists of a single phrase that repeats the title without adding value, failing to use its limited space effectively. While it's front-loaded, it lacks any meaningful structure or informative content, making it inadequate rather than appropriately brief.
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 low complexity (one optional parameter) and the presence of an output schema (which handles return values), the description's inadequacy is partially mitigated. However, with no annotations and a vague purpose, it still falls short of being complete. The output schema helps, but the description should clarify the tool's action and context to fully guide the agent.
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 100% description coverage, with one parameter ('date') clearly documented in the schema. The description adds no parameter semantics beyond what the schema provides, but since schema coverage is high (>80%), the baseline score is 3. The description doesn't compensate for any gaps, but none exist due to the comprehensive schema.
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?
Tautological: description restates name/title.
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. It doesn't mention any context, prerequisites, or exclusions, nor does it reference sibling tools (e.g., aShareFearGreedIndex for sentiment or aShareMarketQuotes for price data). Without such information, an AI agent cannot determine appropriate usage scenarios.
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. However, it only states what the tool does at a high level without revealing any behavioral traits such as data freshness, rate limits, authentication requirements, pagination, error handling, or what the output contains (though an output schema exists). 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, redundant sentence that repeats the title without adding value. While concise, it's under-specified rather than efficiently informative—it fails to front-load useful information or structure content to aid understanding. Every sentence should earn its place, but this one merely restates the obvious.
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 moderate complexity (4 parameters, 1 required) and the presence of an output schema (which reduces the need to describe return values), the description is minimally adequate but incomplete. It lacks context on usage, behavioral traits, and differentiation from siblings, which are crucial for an agent to operate effectively. The output schema mitigates some gaps, but overall completeness is limited.
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 100% description coverage, with clear documentation for all four parameters (query, startDate, endDate, maxCnt). The description adds no parameter-specific information beyond what the schema already provides, so it meets the baseline of 3 where the schema does the heavy lifting. No additional semantic context (e.g., date format examples, query syntax details) is offered.
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?
Tautological: description restates name/title.
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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention any prerequisites, constraints, or comparative context with sibling tools (e.g., 'researchRatingStats' for aggregated ratings or 'industryResearch' for sector-level analysis). This leaves the agent with no basis for selecting this tool over others in similar domains.
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. However, it offers no information beyond the purpose, such as whether this is a read-only operation, if it requires authentication, rate limits, or what the output entails (e.g., statistical summaries, time-series data). This is inadequate for a tool with parameters and potential data retrieval implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, repetitive phrase that mirrors the title, lacking any structure or front-loaded information. While concise, it is under-specified and fails to convey useful details efficiently. Every sentence should earn its place, but this one adds minimal value beyond the title, making it ineffective rather than appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which reduces the need to describe return values), 100% schema coverage for inputs, and no annotations, the description is minimally complete but with significant gaps. It identifies the resource but misses behavioral context and usage guidelines. For a statistical tool with three parameters, this is barely adequate, scoring at the lower end of viable.
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%, meaning the input schema fully documents the parameters (endDate, query, startDate) with descriptions. The description adds no additional meaning beyond what the schema provides, such as examples or constraints on the 'query' field (e.g., format for stock codes vs. industry names). The baseline score of 3 reflects adequate coverage by the schema alone.
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?
Tautological: description restates name/title.
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. Given siblings like 'stkResearch', 'industryResearch', and 'sectorReportAnalysis' that might overlap with research-related functions, the absence of usage guidelines leaves the agent uncertain about tool selection.
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. The description only states what the tool does ('获取ETF基金最近相关新闻资讯') without revealing any behavioral traits such as data freshness, rate limits, authentication needs, error handling, or what '最近' (recent) means temporally. 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 that directly states the tool's function. It's appropriately sized and front-loaded with the core purpose. While concise, it could be more structured by including usage context, but it doesn't waste words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which likely defines the return values), the description doesn't need to explain outputs. However, with no annotations and a simple parameter set, the description is minimally complete but lacks behavioral details and sibling differentiation. It's adequate for basic understanding but has clear gaps in guidance and transparency.
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 100% description coverage, with the 'query' parameter documented as 'ETF基金代码或ETF基金名称' (ETF fund code or ETF fund name). The description doesn't add any parameter semantics beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate.
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?
Tautological: description restates name/title.
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 any prerequisites, exclusions, or specific contexts for usage. With sibling tools like 'officialSecuNews' and 'weMediaSecuNews' available, the absence of differentiation leaves the agent without clear selection 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 carries the full burden of behavioral disclosure. The description only states what data is returned, not how the tool behaves. It doesn't mention whether this is a read-only operation, whether it requires authentication, potential rate limits, error conditions, or the format/structure of the output (though an output schema exists). For a tool with no annotations, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (a single sentence that mirrors the title), but this conciseness comes at the cost of being under-specified rather than efficient. While it's front-loaded with the core purpose, it lacks the additional context needed for effective tool selection. The structure is minimal but doesn't provide the necessary completeness for a tool with no annotations.
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 no annotations are provided and there's an output schema, the description should do more to explain the tool's behavior and usage context. While the output schema will handle return values, the description fails to address key aspects like when to use this versus other stock tools, what makes it unique, or any behavioral characteristics. For a tool in a crowded namespace with 40+ sibling tools, this minimal description is insufficient.
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 100% with a single parameter 'query' described as 'A股股票名称或代码'. The description adds no additional parameter information beyond what's in the schema. Since the schema already fully documents the parameter, the baseline score of 3 is appropriate - the description doesn't add value here but doesn't need to compensate for gaps either.
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?
Tautological: description restates name/title.
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 focused on stock analysis (stockCapAnalysis, stockFunAnalysis, stockTechAnalysis, stockValuation, etc.), there's no indication of when this specific tool for '主营业务与亮点' is appropriate versus other stock data tools. No prerequisites, alternatives, or usage context 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 mentions retrieving and interpreting events, but doesn't specify whether this is a read-only operation, how it handles authentication, rate limits, or what the interpretation entails (e.g., AI-generated insights, structured data). For a tool with no annotations, this leaves significant gaps in understanding its behavior and constraints.
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 directly states the tool's purpose. It's front-loaded with no wasted words, making it easy to parse. However, it could be slightly more structured by separating the retrieval and interpretation aspects, but it remains appropriately concise for its content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (event retrieval and interpretation), no annotations, and an output schema (which exists but isn't provided here), the description is minimally adequate. It covers the basic purpose but lacks details on behavior, usage context, and how interpretations are generated. With an output schema, it doesn't need to explain return values, but the gaps in behavioral transparency and guidelines make it incomplete 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 input schema has 100% description coverage, with clear documentation for all four parameters (endDate, maxCnt, query, startDate). The description doesn't add any meaning beyond what the schema provides—it doesn't explain parameter interactions, default behaviors beyond schema hints, or how the query parameter maps to events. With high schema coverage, the baseline is 3, and the description doesn't compensate with extra insights.
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?
Tautological: description restates name/title.
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 'officialSecuNews' (official securities news), 'sectorNewsAnalysis' (sector news analysis), and 'stockBizHighlight' (stock business highlights), there's clear potential for overlap, but the description doesn't indicate how this tool differs in context, timing, or focus. It's a generic statement with no exclusions or alternatives 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 states the tool '获取' (gets/fetches) quotes, implying a read-only operation, but doesn't describe authentication needs, rate limits, error conditions, or the format/scope of returned data. While the output schema exists, the description adds 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that repeats the title verbatim, making it front-loaded but redundant. While concise, it wastes space by not adding value beyond the title. Every sentence should earn its place, and this one merely restates existing 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?
Given the tool's low complexity (1 optional parameter) and the presence of an output schema, the description is minimally adequate. However, with no annotations and rich sibling tools, it lacks context on differentiation, behavioral traits, or usage scenarios. The output schema reduces the need to explain return values, but the description doesn't address other gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% (the 'date' parameter is fully documented in the schema with type, format, and default). The description mentions '指定日期' (specified date) but adds no meaning beyond what the schema provides. With high schema coverage, the baseline score of 3 is appropriate—the description doesn't compensate but doesn't need to.
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?
Tautological: description restates name/title.
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 'sectorLatestPrice' (for sector indices) or 'stockLatestPrice' (for individual stocks), nor does it specify use cases or exclusions. The agent must infer usage from the title/description alone without 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 mentions retrieving '关键数据与解读' (key data and interpretation), which implies a read-only operation, but does not specify details like data freshness, rate limits, authentication requirements, or error handling. 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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core function, though it could be slightly more structured (e.g., separating data retrieval from interpretation). Overall, it earns its place with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which likely covers return values), no annotations, and a simple input schema with full coverage, the description is moderately complete. It clarifies the type of data retrieved but lacks behavioral context and usage guidance. For a basic read operation, it meets minimum viability but has clear gaps in transparency and guidelines.
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 100% description coverage, with the parameter 'query' documented as 'ETF基金代码或ETF基金名称' (ETF fund code or ETF fund name). The description does not add any additional meaning beyond this, such as format examples or validation rules. With high schema coverage, the baseline score of 3 is appropriate.
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?
Tautological: description restates name/title.
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 prefer this over other ETF-related tools (e.g., 'etfLatestPrice' for price data, 'etfPerformance' for performance metrics) or general fund tools like 'fundBasicInfo'. Usage is implied by the title and description but not explicitly stated.
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 describes what data is retrieved but lacks behavioral details: it doesn't specify data freshness (e.g., real-time vs. delayed), rate limits, authentication needs, error handling, or output format. For a data retrieval 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently lists the key metrics, but it's repetitive with the title and could be more front-loaded. It wastes no words but lacks structural clarity (e.g., not separating purpose from details). It's adequate but not exemplary in conciseness or organization.
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 moderate complexity (1 parameter, no annotations, but with an output schema), the description is partially complete. It specifies the data retrieved, which is helpful, but since an output schema exists, it doesn't need to explain return values. However, it misses behavioral context (e.g., data sources, limitations), making it just adequate for basic 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?
Schema description coverage is 100% (the 'query' parameter is fully described in the schema as 'ETF基金代码或ETF基金名称'), so the baseline is 3. The description adds no additional parameter information beyond what's in the schema—it doesn't clarify format (e.g., code syntax), validation rules, or examples. Thus, it meets the minimum viable level without enhancing parameter understanding.
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?
Tautological: description restates name/title.
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 when to choose etfFunAnalysis over etfBasicInfo, etfLatestPrice, or other ETF tools, nor does it differentiate from stockFunAnalysis or sectorFunAnalysis for non-ETF assets. Usage is implied by the tool name and description but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions '实时行情' (real-time quotes), implying up-to-date data, but doesn't specify data freshness, rate limits, authentication needs, or error handling. For a tool with no annotations, this is a significant gap, as it leaves key operational aspects undefined.
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 directly states the tool's purpose without unnecessary words. It's front-loaded with the key action and resource, making it easy to parse. However, it could be slightly more structured by separating usage context or behavioral details, but it remains concise and to the point.
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 complexity (a read operation with one parameter) and the presence of an output schema (which likely defines return values), the description is minimally adequate. It covers the basic purpose but lacks behavioral details (e.g., real-time implications, error cases) and usage guidelines. With no annotations and incomplete contextual info, it meets the minimum threshold but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'query' parameter documented as 'ETF基金代码或ETF基金名称' (ETF fund code or ETF fund name). The description doesn't add any additional meaning beyond this, such as format examples or constraints. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema adequately handles parameter semantics without extra help from the description.
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?
Tautological: description restates name/title.
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 such as 'etfBasicInfo' (which might provide similar basic info) or 'etfPerformance' (which could include performance metrics), nor does it specify any context or exclusions for usage. This lack of comparative guidance limits its effectiveness in helping an AI agent choose the right 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 the full burden of behavioral disclosure. While it mentions what data is retrieved, it doesn't describe behavioral traits such as whether this requires authentication, rate limits, error conditions, or the format/timing of the response. For a data retrieval tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves operationally.
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 a single, dense sentence that efficiently lists the time periods and metrics. However, it's front-loaded with redundant information (repeats the title) and could be structured more clearly, such as by separating the action from the data details. While concise, it lacks optimal readability for quick scanning.
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 moderate complexity (retrieving multiple performance metrics), no annotations, and an output schema present (which likely covers return values), the description is minimally adequate. It specifies what data is fetched but omits operational context like prerequisites, limitations, or error handling. The output schema reduces the need to explain return values, but behavioral gaps remain.
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%, with the single parameter 'query' documented as 'ETF基金代码或ETF基金名称' (ETF fund code or ETF fund name). The description adds no additional parameter semantics beyond what the schema provides—it doesn't clarify format requirements, examples, or handling of ambiguous inputs. Baseline 3 is appropriate since the schema adequately covers the parameter.
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?
Tautological: description restates name/title.
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 'fundPerformance' (for general funds) and 'etfBasicInfo' (for basic ETF data), there's no indication of how this tool differs or when it should be preferred. The description merely restates what the tool does without contextual usage instructions.
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 information is retrieved without describing how the tool behaves—e.g., whether it's a read-only operation, if it requires authentication, its response format, or any rate limits. This leaves significant gaps in understanding the tool's operational traits.
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 a single, concise sentence that matches the title, but it is overly terse and lacks front-loaded value. While it avoids redundancy, it under-specifies by not elaborating on purpose or usage, making it less helpful than it could be with minimal additional 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?
Given the tool's simplicity (1 parameter, 100% schema coverage, and an output schema exists), the description is minimally adequate but incomplete. It covers the basic purpose but fails to provide necessary behavioral context or usage guidelines, which are crucial for effective tool invocation despite the structured data support.
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 100%, with the parameter 'query' clearly documented as accepting a fund code or name. The description does not add any semantic details beyond this, such as examples or constraints, but since the schema already provides adequate coverage, the baseline score of 3 is appropriate.
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?
Tautological: description restates name/title.
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?
There is no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or comparisons to sibling tools such as 'fundPerformance' or 'fundUnderAssets', leaving the agent without context for tool selection in this domain.
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 describes what data is returned but lacks behavioral details such as whether this requires authentication, rate limits, error handling, or how results are formatted (e.g., JSON structure, units). For a data retrieval tool with no 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that lists all metrics and time periods, making it information-rich but somewhat cluttered. It could be more structured (e.g., separating purpose from details) for better readability, though it avoids unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (retrieving multiple performance metrics across time periods), the description is reasonably complete in specifying what data is returned. With an output schema present, it doesn't need to detail return values, and the single parameter is well-documented in the schema. However, it lacks usage context and behavioral transparency, which are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'query' documented as '基金代码或基金名称' (fund code or fund name). The description adds no additional parameter information beyond what's in the schema, so it meets the baseline of 3 for high schema coverage.
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?
Tautological: description restates name/title.
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 available (e.g., 'fundBasicInfo', 'etfPerformance', 'fundRecentViews'), there's no indication of context, prerequisites, or comparisons to help an agent choose appropriately.
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 content includes investment strategy, operation analysis, and macro outlook, but doesn't disclose behavioral traits like whether this is a read-only operation, requires authentication, has rate limits, or what the output format entails. 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, consisting of a single sentence that directly states the purpose. There's no wasted text, but it could be slightly more structured by explicitly stating the action verb. Overall, it's efficient but minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is an output schema (which should cover return values), no annotations, and simple parameters with high schema coverage, the description is minimally complete. However, it lacks details on behavioral aspects and usage context, making it adequate but with clear gaps for effective tool 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 description coverage is 100%, with the parameter 'query' documented as 'fund code or fund name'. The description doesn't add any meaning beyond this, such as examples or constraints. Since schema coverage is high, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.
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?
Tautological: description restates name/title.
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 such as 'fundBasicInfo' or 'fundPerformance', 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?
With no annotations, the description carries full burden but only states the transformation behavior without disclosing traits like error handling, rate limits, or authentication needs. It doesn't add meaningful context beyond the basic operation, leaving gaps in behavioral understanding.
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 front-loads the core purpose without waste. It could be slightly more structured by separating input/output details, but it's appropriately sized and clear.
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 moderate complexity (parsing aliases), no annotations, and an output schema (which covers return values), the description is minimally complete. It states what the tool does but lacks context on limitations or integration with siblings, making it adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the 'query' parameter. The description adds no additional meaning beyond implying it accepts fund names or codes, matching the schema. Baseline 3 is appropriate as the schema handles parameter documentation adequately.
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?
Tautological: description restates name/title.
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. It doesn't mention when to choose it over 'guessStockCode' for stocks or 'fundBasicInfo' for pre-known codes, leaving usage context implied at best.
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 'gets' views, implying a read-only operation, but doesn't specify whether it requires authentication, has rate limits, returns paginated results, or what the output format is. The description is minimal and lacks behavioral details beyond the basic action.
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 directly states the tool's function without unnecessary words. It's appropriately sized for a simple tool, though it could be more front-loaded with key details. There's no wasted text, but it might be too concise given the lack of behavioral 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?
Given that an output schema exists (as indicated in context signals), the description doesn't need to explain return values. However, with no annotations and a tool that involves fetching potentially complex research data, the description is minimal and lacks context about authentication, rate limits, or data freshness. It's adequate as a basic descriptor but has clear gaps in completeness for a research 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%, with all four parameters well-documented in the input schema (e.g., 'query' for industry names, date ranges, max count). The description adds no additional parameter semantics beyond what's already in the schema. According to guidelines, when schema coverage is high (>80%), the baseline score is 3 even with no param info in the description.
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?
Tautological: description restates name/title.
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 any prerequisites, exclusions, or comparison to sibling tools like 'macroResearch' (which might cover broader economic research) or 'sectorReportAnalysis' (which could analyze sector reports). Usage context is implied but not explicit.
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 what the tool does but doesn't describe how it behaves: e.g., whether it returns real-time or historical data, pagination or rate limits, authentication requirements, or error handling. For a tool with no annotations, this leaves significant gaps in understanding its operational characteristics.
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 a single sentence that restates the title verbatim, making it concise but lacking in structure. It doesn't front-load critical information or expand on the title's meaning. While it avoids unnecessary words, it doesn't add value through organization or emphasis on key aspects.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is an output schema (which handles return values), no annotations, and high schema coverage, the description is minimally adequate. However, for a tool with 4 parameters and no annotations, it should provide more context about usage scenarios, limitations, or behavioral traits to be fully complete. It meets the baseline but doesn't excel in compensating for the lack of annotations.
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 parameters (endDate, maxCnt, query, startDate) with descriptions. The tool description doesn't add any parameter-specific information beyond what's in the schema. According to guidelines, when schema coverage is high (>80%), the baseline score is 3 even with no param info in the description.
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?
Tautological: description restates name/title.
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 compare it to sibling tools such as 'industryResearch' (for industry-specific research) or 'officialSecuNews' (for official securities news). Users must infer usage from the name and description 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 states the tool retrieves data, implying a read-only operation, but doesn't cover critical aspects like whether it requires authentication, has rate limits, returns real-time or historical data, or handles errors. For a data retrieval tool with no 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence in Chinese that matches the title. While it's not verbose, it lacks front-loaded clarity and doesn't structure information to guide usage effectively. It's minimal but under-specified rather than efficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description doesn't need to explain return values. However, for a tool with no annotations and multiple siblings, it fails to provide sufficient context on behavior, usage, or differentiation. The high schema coverage helps, but the description is too sparse to be fully complete 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 schema description coverage is 100%, with clear descriptions for both parameters ('date' and 'query'). The description adds no additional parameter semantics beyond what's in the schema, such as format examples or constraints. Given the high schema coverage, the baseline score of 3 is appropriate, as the schema adequately documents the parameters.
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?
Tautological: description restates name/title.
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 available (e.g., 'stockCapAnalysis', 'sectorFunAnalysis', 'sectorPriceChangeRank'), the description fails to indicate scenarios where this tool is preferred, such as for sector-level capital analysis versus stock-level or other sector 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 describes the tool as a data retrieval operation ('获取' - get), implying it is likely read-only and non-destructive, but does not confirm this or address other behavioral aspects such as rate limits, authentication needs, error handling, or data freshness. The description adds minimal context beyond the basic operation.
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 a single, concise sentence that front-loads the purpose. However, it is repetitive with the title and could be more structured by separating key points (e.g., data types, usage context). It avoids waste but lacks elaboration that might aid clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, fundamental data retrieval), the description is reasonably complete. It outlines the data types returned (PE, ROE, etc.), and with an output schema present, detailed return value explanations are not needed. However, it could improve by addressing behavioral aspects (e.g., data sources, update frequency) since annotations are absent.
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%, with clear descriptions for both parameters ('date' and 'query'). The description mentions '概念或行业板块名称' (concept or industry sector name), which aligns with the 'query' parameter, but does not add significant meaning beyond what the schema provides. With high schema coverage, the baseline score of 3 is appropriate as the description compensates minimally.
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?
Tautological: description restates name/title.
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 sibling tools like 'sectorCapAnalysis' or 'stockFunAnalysis' (for individual stocks), nor does it specify prerequisites, exclusions, or contextual cues for selection. Usage is implied by the tool's name and description but not explicitly stated.
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 '获取' (get) which implies a read operation, but doesn't disclose traits like rate limits, authentication needs, pagination, or what happens if no news is found. The description is minimal and lacks behavioral context beyond the basic operation.
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 directly states the tool's function without waste. It is appropriately sized and front-loaded, making it easy to parse. However, it could be slightly more structured by separating purpose from 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?
Given the tool's moderate complexity (4 parameters, 1 required), no annotations, and the presence of an output schema (which handles return values), the description is minimally adequate. It covers the basic purpose but lacks behavioral details and usage guidelines. The output schema likely compensates for return value explanation, but the description should do more to address gaps in behavioral transparency.
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%, with all parameters well-documented in the input schema (e.g., 'query' as concept/industry sector name, date defaults). The description adds no additional meaning beyond the schema, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
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?
Tautological: description restates name/title.
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 siblings such as 'etfRelatedNews' for ETF-related news or 'officialSecuNews' for official securities news, nor does it specify prerequisites or exclusions. Usage is implied by the description but not explicitly stated.
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 provides '相关消息' (related messages), which adds some context beyond basic ranking. However, it doesn't describe important behaviors like whether this is a read-only operation, what format the output takes, whether there are rate limits, or what authentication might be required. The description is too minimal for a tool with 5 parameters.
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 - essentially repeating the title in Chinese. While this is efficient, it's arguably too brief for a tool with 5 parameters and no annotations. However, it's front-loaded with the core purpose and doesn't contain unnecessary verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which should document return values), the description doesn't need to explain outputs. However, for a tool with 5 parameters, no annotations, and moderate complexity (ranking with date ranges and sector types), the description is minimal. It states the basic purpose but lacks context about when to use it, behavioral characteristics, or relationship to sibling 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 5 parameters with their types and descriptions. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it doesn't explain relationships between parameters, provide examples, or clarify edge cases. Baseline 3 is appropriate when the schema does the heavy lifting.
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?
Tautological: description restates name/title.
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, appropriate contexts, or comparisons to sibling tools like 'sectorPriceChangeReason' (which might explain reasons for changes) or 'sectorLatestPrice' (which might provide current prices rather than historical rankings).
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 only states what the tool does without behavioral details. It lacks information on rate limits, authentication needs, error handling, or data freshness, which are critical for an AI agent to use it effectively in real-world scenarios.
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 front-loads the core functionality. It avoids redundancy and waste, though it could be slightly more structured by separating purpose from sorting options for better readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and full parameter coverage, the description is minimally adequate. However, as a data retrieval tool with no annotations, it should ideally include more context on response format or limitations to be fully complete for 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?
Schema description coverage is 100%, so the input schema already documents all parameters thoroughly. The description adds no additional meaning beyond the schema, such as examples or edge cases, but doesn't contradict it either, meeting the baseline for high coverage.
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?
Tautological: description restates name/title.
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 mentions sorting by metrics like market value or change ratio, but it doesn't clarify scenarios where this is preferred over other sector tools, leaving usage context implied at best.
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 the tool does ('获取...研报观点') without detailing behavioral traits like rate limits, authentication needs, error handling, or output format. For a tool with no annotations, this leaves significant gaps in understanding how the tool behaves in practice, such as whether it returns structured data or raw text.
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 directly states the tool's purpose without unnecessary words. It's front-loaded with the core functionality, making it easy to parse. However, it could be slightly more structured by explicitly mentioning key parameters or usage context, but it avoids redundancy and waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (implied by 'Has output schema: true'), the description doesn't need to explain return values. However, with no annotations and a tool that likely returns complex data (research report viewpoints), the description is minimal and lacks context about the tool's scope, such as data sources or limitations. It's adequate as a basic summary but incomplete for guiding an AI agent in complex scenarios without additional structured data.
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 input schema fully documents all four parameters (query, startDate, endDate, maxCnt) with descriptions. The description adds no additional meaning beyond what the schema provides, as it doesn't explain parameter interactions, formatting examples (e.g., date format), or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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?
Tautological: description restates name/title.
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 such as 'sectorNewsAnalysis' or 'sectorFunAnalysis'. Without this context, an AI agent must infer usage based on the tool name and parameters alone, which is insufficient for optimal 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 only lists data types without mentioning permissions, rate limits, data freshness, or output format. For a tool fetching financial data, this lack of behavioral context (e.g., real-time vs. historical, authentication needs) 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase that repeats the title, making it concise but under-specified. It front-loads the purpose but lacks structure or elaboration that could add value. While not verbose, it fails to use its limited space effectively to enhance understanding beyond the title.
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 complexity (financial data analysis with one parameter), the description is minimally complete. It identifies data types but lacks behavioral details, and with an output schema present, it doesn't need to explain return values. However, without annotations and with vague usage guidelines, it leaves gaps in contextual understanding 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?
Schema description coverage is 100%, with the parameter 'query' documented as 'A股股票名称或代码' (A-share stock name or code). The description adds no additional parameter semantics beyond this, such as format examples or constraints. Since the schema already provides adequate coverage, the baseline score of 3 is appropriate.
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?
Tautological: description restates name/title.
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 lists data types but doesn't specify use cases, prerequisites, or exclusions. With siblings like 'stockFunAnalysis' and 'sectorCapAnalysis' that might offer similar or complementary data, this omission leaves 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. It describes the tool as retrieving data, implying a read-only operation, but lacks details on behavioral traits such as rate limits, data freshness, authentication needs, or error handling. This is insufficient 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 a single sentence that repeats the title verbatim, making it concise but lacking in structure. It is front-loaded with the purpose but does not earn its place with additional useful information, resulting in a mediocre 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?
Given the tool has an output schema, the description does not need to explain return values. However, with no annotations and a simple input schema, the description is minimal and does not fully address the tool's complexity or usage context, leaving gaps in 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%, with the parameter 'query' documented as 'A股股票名称或代码'. The description does not add any additional meaning beyond this, such as examples or constraints, so it meets the baseline score of 3 for high schema coverage without extra value.
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?
Tautological: description restates name/title.
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 does not mention prerequisites, exclusions, or specific contexts, leaving the agent to infer usage based on the tool name and sibling tools without explicit 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 the full burden of behavioral disclosure. While it mentions what data is returned (price, change percentage, trading volume), it lacks critical behavioral details such as data freshness (e.g., real-time vs. delayed), rate limits, authentication requirements, error handling, or whether this is a read-only operation. The description is minimal and doesn't compensate for the absence of annotations.
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 a single, efficient sentence that directly states the tool's purpose. However, it's essentially a restatement of the title with minor elaboration, lacking front-loaded critical information about scope or limitations. While concise, it could be more structured to prioritize key usage details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which should document return values), the description doesn't need to explain output details. However, for a tool with no annotations and multiple similar siblings, the description is too minimal—it doesn't address behavioral aspects like data sources, latency, or error cases. It's adequate for a simple lookup tool but leaves gaps in contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage (the 'query' parameter is documented as 'A股股票名称或代码' - A-share stock name or code), so the schema already provides adequate parameter semantics. The description adds no additional parameter information beyond what's in the schema, which meets the baseline expectation when schema coverage is high.
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?
Tautological: description restates name/title.
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 that seem related (e.g., 'sectortLatestPrice', 'etfLatestPrice', 'aShareMarketQuotes'), there's no indication of scope boundaries, prerequisites, or comparative use cases. The tool name 'stockLatestPrice' implies it's for stocks, but this isn't clarified in the description.
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 but lacks behavioral details. It doesn't disclose rate limits, authentication needs, data freshness, or output format (though output schema exists). The description only repeats the purpose without adding 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, stating the core function in a single sentence without unnecessary details. However, it could be more structured by explicitly separating indicators from analysis, but it efficiently communicates the tool's intent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and high input schema coverage, the description is minimally adequate. However, for a technical analysis tool with no annotations, it should add more context like data sources, timeframes, or interpretation hints to be fully complete for 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 no parameter semantics beyond the input schema, which has 100% coverage and clearly describes the 'query' parameter as 'A股股票名称或代码'. With high schema coverage, the baseline is 3, as the description doesn't compensate or provide additional meaning.
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?
Tautological: description restates name/title.
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. It doesn't mention prerequisites, exclusions, or compare to siblings such as 'stockFunAnalysis' for fundamental analysis or 'etfTechAnalysis' for ETFs, leaving the agent to infer usage 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 states the tool retrieves valuation data but doesn't describe the response format, potential rate limits, authentication requirements, or data freshness (e.g., whether it's real-time or historical). For a data retrieval tool with zero annotation coverage, 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 a single sentence that efficiently lists the valuation metrics. However, it's somewhat repetitive with the title and could be more front-loaded with key usage information. While concise, it lacks structural elements like bullet points or prioritization of information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (retrieving valuation data), 100% schema coverage, and the presence of an output schema, the description is reasonably complete. It clearly states what data is returned, and the output schema will handle return values. The main gap is the lack of behavioral context, but overall it provides enough information for basic 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 schema description coverage is 100%, with both parameters ('date' and 'query') well-documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., it doesn't clarify the 'query' format or 'date' handling). Since the schema does the heavy lifting, the baseline score of 3 is appropriate.
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?
Tautological: description restates name/title.
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 compare it to sibling tools such as 'stockFunAnalysis' (which might include valuation metrics) or 'stockLatestPrice' (which provides price data). The agent must infer usage from the tool name and description 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 retrieving data and interpretation, but does not specify whether this is a read-only operation, requires authentication, has rate limits, or details the output format. For a tool with no annotations, this leaves significant gaps in understanding its behavior and constraints.
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 a single sentence that repeats the title verbatim, which is concise but lacks front-loading of key information. It does not waste words, but it also doesn't add value beyond the title, making it under-specified rather than efficiently informative.
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 complexity (technical analysis with interpretation), no annotations, and the presence of an output schema, the description is minimally adequate. It covers the basic purpose but fails to address behavioral aspects or usage context. With an output schema, return values are documented elsewhere, but the description should do more to explain the tool's role and limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 100% coverage, describing 'query' as 'ETF基金代码或ETF基金名称' (ETF fund code or ETF fund name). The description does not add meaning beyond this, but with high schema coverage and only one parameter, the baseline is 4. The description implicitly supports the parameter by focusing on ETFs, but no extra details are provided.
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?
Tautological: description restates name/title.
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 is provided on when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or compare it to sibling tools such as 'etfBasicInfo', 'etfLatestPrice', or 'etfPerformance'. Usage is implied by the title and description focusing on technical analysis for ETFs, but there is no clear direction on context or alternatives.
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 states what data is retrieved but doesn't disclose behavioral traits such as whether this requires network calls, potential rate limits, data freshness (e.g., real-time vs. cached), error conditions, or authentication needs. For a tool with zero 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that mirrors the title, but it's under-specified rather than concise. It front-loads the purpose but lacks any additional context that would earn its place, making it feel sparse rather than optimally structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, output schema exists), the description is minimally complete. It states what data is returned, and the output schema can handle return values, but it doesn't address behavioral aspects or usage context. For a no-param tool with output schema, this is adequate but leaves gaps in guidance and transparency.
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% (since there are no parameters to describe). With no parameters, the baseline is 4, as there's nothing for the description to compensate for. The description doesn't need to add parameter semantics beyond what the empty schema already provides.
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?
Tautological: description restates name/title.
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. It doesn't mention siblings like 'currentDatetime' (which might provide general date/time without trading context) or 'aShareMarketEvents' (which could include trading calendar events), leaving the agent with no explicit when-to-use or when-not-to-use instructions.
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 date, time, day of week, and holiday, but doesn't specify behavioral traits such as whether it's read-only (implied by '查询' meaning query), real-time accuracy, data sources, rate limits, or error handling. This leaves significant gaps 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 front-loads the core purpose. It avoids unnecessary words and directly states what the tool does, making it appropriately sized for a simple query tool. However, it could be slightly more structured by separating key output elements for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, output schema exists), the description is minimally complete. It covers the basic purpose but lacks details on behavioral aspects like timezone handling or holiday data sources. With an output schema, it doesn't need to explain return values, but the absence of annotations means more context would be beneficial for full transparency.
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, with schema description coverage at 100%. Since there are no parameters, the description doesn't need to add semantic details beyond the schema. It appropriately focuses on the tool's output, meeting the baseline for zero parameters without compensation needed.
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?
Tautological: description restates name/title.
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 lacks explicit context, exclusions, or references to sibling tools, which include various financial and market data tools but no obvious date/time alternatives. Usage is implied only by the purpose statement, with no further instructions.
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 tool extracts entities and returns specific data, but lacks details on behavioral traits like error handling, rate limits, authentication needs, or whether it's read-only or mutative. This is a significant gap 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 front-loads the core functionality. It avoids redundancy but could be slightly more structured by separating key points, though it remains appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (extracting multiple entity types with varied returns), the description covers the purpose and output details well. With an output schema present, it doesn't need to explain return values, and the single parameter is fully documented in the schema, making it reasonably complete despite gaps in usage guidelines and behavioral transparency.
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%, with the parameter 'query' documented as '包含股票代码、名称的自然语言问句'. The description adds no additional parameter semantics beyond this, so it meets the baseline of 3 where the schema does the heavy lifting.
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?
Tautological: description restates name/title.
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 prerequisites, exclusions, or compare it to siblings such as guessStockCode or guessFundCode, 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. It mentions '穿透分析' (penetrating analysis) but doesn't disclose behavioral traits like whether it's read-only, requires authentication, has rate limits, or what the output format is. The description is too vague to inform the agent about how the tool behaves beyond its 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 that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy for the agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which handles return values) and the input schema has full coverage, the description's job is reduced. However, for a tool with no annotations and potential complexity in analysis, the description could better explain scope (e.g., depth of analysis, data recency) or limitations. It's minimally adequate but lacks context about behavioral aspects.
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 100% description coverage for the single parameter 'query', which is documented as '基金代码或基金名称' (fund code or fund name). The description doesn't add any meaning beyond this, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate.
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?
Tautological: description restates name/title.
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, context, or compare with sibling tools such as 'etfUnderAssets' (for ETFs) or 'fundBasicInfo' (for general fund info). The agent must infer usage based on the name and description 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 the time frame (90 days) and limit (3 reports), which are useful, but does not cover other critical aspects such as data source, update frequency, error handling, or authentication needs. For a tool with no annotations, this leaves significant gaps in understanding its behavior and 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 extremely concise and front-loaded, consisting of a single sentence that directly states the tool's purpose without any unnecessary words. It efficiently communicates the key information (action, resource, time frame, limit) in a compact form, making it easy for an AI agent to parse quickly.
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 moderate complexity (1 parameter, no annotations, but with an output schema), the description is minimally adequate. It covers the basic purpose and scope but lacks details on usage guidelines, behavioral traits, and output interpretation. The presence of an output schema reduces the need to describe return values, but overall completeness is limited, leaving room for improvement in contextual information.
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 100% description coverage, with the 'query' parameter documented as 'A股股票名称或代码' (A-share stock name or code). The description does not add any additional semantic details beyond this, such as examples or formatting requirements. Given the high schema coverage, the baseline score of 3 is appropriate, as the schema adequately handles parameter documentation.
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?
Tautological: description restates name/title.
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 'stkResearch' or 'industryResearch', which might offer similar or related functionality. This lack of contextual usage information limits its effectiveness for an AI agent in selecting the appropriate 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 the full burden of behavioral disclosure. It states the tool retrieves '最新实时' (latest real-time) data, implying it's a read-only operation with current information, but doesn't cover aspects like rate limits, authentication needs, data freshness guarantees, or error handling. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It directly mirrors the title, which is acceptable given the tool's straightforward function. Every part of the sentence contributes to understanding, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, read-only operation), the description is complete enough for basic use. It clearly states what data is retrieved. With an output schema present, the description doesn't need to explain return values. However, the lack of annotations and usage guidelines leaves some contextual gaps, preventing a perfect score.
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 100%, with both parameters ('date' and 'query') fully documented in the schema. The description adds no parameter-specific information beyond what's in the schema (e.g., it doesn't clarify format for 'query' or examples). With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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?
Tautological: description restates name/title.
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 (e.g., 'sectorPriceChangeRank' for rankings or 'sectorCapAnalysis' for capitalization) or specify contexts where this tool is preferred. Usage is implied by the purpose but lacks explicit when/when-not instructions 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 full burden. It describes the transformation behavior (parsing abbreviations to standardized formats) but doesn't disclose important behavioral traits like error handling (e.g., what happens with unrecognized inputs), performance characteristics, rate limits, or authentication requirements. For a 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 sentence that front-loads the core purpose and includes all essential information. Every element (what it does, what it accepts, what it returns) earns its place with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (natural language parsing), 100% schema coverage, and the existence of an output schema (implied by context signals), the description is reasonably complete. It clearly states the transformation purpose and output format. However, it could benefit from mentioning typical use cases or limitations given the parsing nature.
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% (the single parameter 'query' is fully described in the schema as '含A股股票名称或代码的自然语言问句'), so the baseline is 3. The description doesn't add any parameter-specific information beyond what's already in the schema, but doesn't need to compensate for coverage gaps.
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?
Tautological: description restates name/title.
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 provides clear context for when to use this tool: for parsing stock abbreviations/aliases from everyday conversation into standardized formats. It implicitly distinguishes from siblings by focusing on stocks (not funds or other entities), but doesn't explicitly state when NOT to use it or name specific alternatives.
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

deepq-financial-toolkit-mcp-server MCP server

Copy to your README.md:

[![deepq-financial-toolkit-mcp-server MCP server](https://glama.ai/mcp/servers/shenqingtech/deepq-financial-toolkit-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/shenqingtech/deepq-financial-toolkit-mcp-server)

Score Badge

Copy to your README.md:

[![deepq-financial-toolkit-mcp-server MCP server](https://glama.ai/mcp/servers/shenqingtech/deepq-financial-toolkit-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/shenqingtech/deepq-financial-toolkit-mcp-server)

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/shenqingtech/deepq-financial-toolkit-mcp-server'

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