AgentLadle MCP AKShare
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation4/5
Most tools target distinct data types (block trades, yield curves, candlesticks, etc.), and overlapping areas like financial reports and holdings are differentiated by granularity. However, with 54 tools, some may be confused (e.g., get_fund_holding vs get_institutional_holding) despite clear descriptions.
Naming Consistency5/5All tool names follow a consistent verb_noun snake_case pattern (e.g., get_candlesticks, get_market_status). No mixing of styles or abbreviations, making the API highly predictable.
Tool Count3/554 tools is high but justified for a comprehensive financial data API covering stocks, bonds, funds, macro, etc. However, some tools could be merged (e.g., multiple valuation tools), and the count slightly exceeds the typical well-scoped range.
Completeness5/5The tool surface covers a wide range of financial data: market quotes, fundamentals, macro indicators, IPOs, filings, sector info, and more. There are no obvious gaps for the server's stated purpose of providing AKShare financial data.
Average 4.1/5 across 54 of 54 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
This server has been verified by its author.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true. The description adds no behavioral context beyond the basic function, such as data freshness, scope of currencies, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with one sentence and a parameter definition. The inclusion of strategy and examples tags adds structure but is not excessive. Each part serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and an output schema, the description adequately explains the function and parameter. However, it omits details about the output structure, which is covered by the output schema per rules, but additional context like 'major' currency definition would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'base' is described as 'Base currency (default CNY)', which adds meaning beyond the schema's default value. However, no valid values or constraints are provided, and schema description coverage is 0%, so the description only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get major currency exchange rates' which clearly indicates the tool's purpose. However, it does not differentiate from the sibling tool 'get_forex_quote', which likely provides similar data, reducing clarity on when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a strategy tag suggesting direct invocation for FX rates, but no explicit guidance on when to use this tool versus alternatives like 'get_forex_quote'. There is no mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, and idempotentHint. The description adds minimal behavioral context (language support, example) but lacks details on result ordering, sources, or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear purpose, strategy, example, and argument list. No redundant sentences, but the strategy and example tags are additional but not excessive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, return values are covered. However, the description lacks details such as maximum results, data freshness, or search logic, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It adds basic descriptions: keyword is 'Search keyword' (circular), count is 'Number of articles (default 10)'. This adds some meaning but is insufficient for full understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches financial news by keyword. However, it does not differentiate from the sibling tool 'get_news', which likely provides similar functionality without search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an example and suggests using English or Chinese keywords, but it does not specify when to use this tool versus other news tools or offer exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint as true, which cover safety and idempotency. The description adds no further behavioral context (e.g., what the time series contains, data source, or limits). Minimal value added beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear purpose sentence, but it includes redundant elements like a strategy tag that adds no new information. The args block repeats schema info. Overall efficient but could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of many sibling tools (e.g., get_quote, get_candlesticks) and no output schema details shown, the description fails to define what 'capital flow' is or how it should be interpreted. For a simple two-parameter tool, it lacks necessary context for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It provides an example for 'symbol' and lists allowed values for 'period' ('1d/3d/5d/10d') beyond the schema's default. However, it does not explain the meaning of 'period' (e.g., aggregation granularity).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get capital flow time series for a stock' with a specific verb and resource. It distinguishes from many sibling tools by name, but does not explain the unique nature of capital flow vs other time series tools (e.g., get_quote, get_candlesticks).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The strategy tag says 'Directly invoke with stock symbol' but that is trivial and not comparative. No exclusions or context for selection among siblings are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, openWorld, and idempotent hints. The description adds 'history' implying time-series data, which is consistent but not disclosing additional behavioral traits beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear main sentence, a separate strategy hint, and an example. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (1 param), annotations, and presence of output schema, the description is adequate but lacks details on what the history data includes (e.g., dates, count breakdowns).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description repeats the schema with 'symbol: Security symbol', adding no extra meaning. With 0% schema description coverage and only one common parameter, the description provides no added value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get shareholder count history' clearly states the verb (Get) and resource (shareholder count history). The strategy tag adds context. While the name alone is clear, no explicit differentiation from siblings like get_shareholder_top.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The <strategy> tag gives a use case: 'track retail vs institutional concentration trends.' This provides some guidance on when to use, but there is no mention of when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety and nature. The description adds minor context about it being a 'quick snapshot' but doesn't elaborate on data freshness, availability, or potential empty results. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no wasted words. It includes a strategy hint and a usage example, which are valuable. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (1 param) and has an output schema (not shown). The description covers the core purpose and basic parameter. It lacks guidance on edge cases like missing data, but overall sufficient for a low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% coverage, so description must compensate. It only states 'symbol: Security symbol' which is generic. The example shows a format (000001.SZ) but doesn't explain the pattern or exchange suffixes. More detail is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the latest financial report summary and lists specific metrics (revenue, net profit, EPS, ROE). The verb 'Get' and resource 'latest financial report summary' are specific. However, it does not explicitly differentiate from siblings like get_financial_metrics or get_financial_statement, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The strategy tag 'Quick snapshot of latest quarterly/annual results' implies usage context, but no explicit when-to-use or when-not-to-use guidance is provided. Given the many sibling tools, more specific direction would be beneficial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, openWorld, and idempotent. The description adds parameter details but does not disclose data freshness, rate limits, or the meaning of 'search' vs 'hot'. It adds some value but not extensive beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear heading, strategy, example, and parameter list. The use of XML tags adds structure, though it is non-standard. No wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with three optional parameters and an output schema. The description covers the core purpose and parameter choices but omits details on the two rank_type options and does not explain the return format (though output schema exists). It is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so the description carries the burden. It lists possible values for market and rank_type, but does not explain the semantics of 'hot' vs 'search' or validate the formats. Partially compensates but incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets a hot stock ranking and strategy says 'Use to find trending stocks'. However, it only mentions 'hot' while the tool also supports a 'search' rank_type, which is not explained, causing slight ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The strategy tag provides a clear usage hint ('find trending stocks'), but there is no guidance on when to use this tool versus alternatives (e.g., get_industry_rank or get_limit_up_pool) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety and idempotency. The description adds no additional behavioral context (e.g., data lag, pagination), so it provides minimal extra value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loads the main purpose. The <strategy> and <examples> tags add minor clutter but do not severely impact conciseness. Every sentence is functional, though the XML-like tags could be considered unnecessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only one parameter and an existing output schema, the description is minimally adequate. However, it does not explain what insider trading records contain, how results are sorted, or any filtering options, leaving some gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should add meaning to the 'symbol' parameter. It only restates 'symbol: Security symbol', which is already evident from the schema title. No format, examples, or constraints are provided, failing to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get insider trading records' with a specific verb and resource. The Chinese translation and strategy note add clarity. Among many sibling 'get_*' tools, this one uniquely targets insider trading, distinguishing it effectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a <strategy> tag ('Use to track management buying/selling'), providing some context on when to use the tool. However, it lacks explicit guidance on when not to use it or alternatives among sibling tools like get_institutional_holding or get_shareholder_top.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true. Description merely restates the purpose without adding behavioral details beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is extremely concise, front-loaded with the main purpose, and includes a strategy and example with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite missing explicit sibling differentiation, the description combined with annotations and output schema provides sufficient completeness for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description explicitly defines the market parameter with values CN/HK and default CN, adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get IPO calendar (upcoming and recent IPOs)' with a strategy tag emphasizing listing newly listed or upcoming stocks. It distinguishes from sibling get_ipo_detail implicitly by focusing on a calendar, not individual details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Strategy tag provides usage guidance ('Use to find newly listed or upcoming stocks'), but lacks explicit when-not-to-use or alternative tools like get_ipo_detail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds minimal behavioral context beyond specifying the exchanges (SSE/SZSE). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences plus a strategy and example. Every part is front-loaded and useful with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to explain return values. It covers the basic purpose and parameter usage but could be more complete by mentioning if the quote is real-time or the specific exchange details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage. The description adds meaning by explaining the exchange parameter is optional and providing valid values (SSE/SZSE) via the example and strategy. It could be more explicit about the parameter's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets option quotes for SSE and SZSE exchanges. The name and context distinguish it from sibling quote tools like get_quote and get_futures_quote, though it does not explicitly differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a strategy ('Leave exchange empty for all options') and an example, providing basic guidance on when to use the exchange parameter. However, it does not compare to sibling tools or specify when this tool should be preferred over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is clear. The description adds that it returns treasury yield curve data but does not disclose additional behavior like the structure of the response or potential rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a single line of purpose, an embedded usage hint, and a clear parameter list. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 optional parameters, output schema exists), the description covers the essential information: what it does, arguments, and defaults. It could be improved by noting that it returns multiple maturities, but the output schema compensates for that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by listing the parameters 'country' with allowed values 'CN/US' and default, and 'date' with format and default. This adds meaningful context beyond the schema's empty descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get treasury yield curve' and mentions 'bond yield data', so the purpose is specific. However, it does not differentiate from the sibling tool 'get_interest_rate', which could also retrieve yield-related data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a direct invocation phrase and an example, but it does not provide explicit guidance on when to use this tool versus alternatives like 'get_interest_rate'. No when-not conditions are given.
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?
Annotations already indicate readOnly, openWorld, and idempotent. The description adds no additional behavioral context (e.g., no mention of rate limits, authentication, or return format), so it does not add value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the purpose, followed by a strategy and example. However, it could be more structured (e.g., separating the Args section).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists the returned fields (name, industry, listing date, shares) and has an output schema (though not detailed here). It is fairly complete for a simple read operation, but could mention any limitations (e.g., supported exchanges).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description provides examples and format guidance for the symbol parameter (e.g., '000001.SZ', 'AAPL.US'), adding meaningful context beyond the schema's type string.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool retrieves a company overview with specific fields (name, industry, listing date, shares), clearly distinguishing it from sibling tools like get_quote or get_financial_metrics that serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a strategy 'Directly invoke with symbol' and an example, but lacks explicit guidance on when to use this tool over alternatives (e.g., get_financial_metrics) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint, openWorldHint) already indicate safe read behavior. The description adds 'real-time' which implies data freshness, slightly enhancing transparency. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the purpose. The strategy tag and example add value without redundancy. Could be slightly more structured, but efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown), the description need not detail return values. However, it could mention depth levels or typical fields. The simple parameter and single sibling context make this adequate but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It only states 'symbol: Security symbol,' adding minimal meaning. While the parameter is simple, the description does not specify format, exchange, or examples beyond a single snippet.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the order book (bid/ask depth) for a symbol. The verb 'Get' and resource 'order book' are specific, and the tool is distinct from siblings like get_quote or get_candlesticks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The <strategy> tag advises 'Directly invoke for real-time bid/ask,' providing clear when-to-use guidance. However, it does not explicitly exclude alternatives or mention context where other tools might be better, so it's not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, so the description does not need to restate safety. It adds behavioral context about direction and required parameters but does not disclose pagination behavior or output format beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with strategy tags, critical rules, examples, and an Args list. It is front-loaded with purpose. The Args section is somewhat redundant with the schema but provides clarity. Minor verbosity, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters and an output schema, the description covers the key parameters (direction, scope, symbol, dates) and usage rules. It does not discuss pagination parameters (count, offset) but the output schema likely documents return values. The description is fairly complete for a data retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description's Args section adds meaning for 5 out of 7 parameters (direction, scope, symbol, start, end). However, it omits count and offset, which are also in the schema. This partially compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves northbound/southbound capital flow for Stock Connect. It distinguishes itself from sibling tools like get_capital_flow by specifying the Stock Connect context. The verb 'Get' and resource 'capital flow' are precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit guidance on using direction=north or south, and a critical rule for when scope=stock requiring symbol. While it doesn't explicitly mention when not to use the tool, the strategy tags provide clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, so the description's addition of specific metrics adds value but does not exceed the baseline behavioral disclosure beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with a clear verb+resource statement, followed by strategy, example, and args. Slightly redundant (strategy and example) but still concise overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and the tool has one required parameter, the description lists the specific metrics returned, which is sufficient for a simple snapshot tool without needing further details on return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds a brief 'Security symbol' explanation for the 'symbol' parameter, which is minimal but provides some semantic value beyond the schema's type definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches current valuation metrics (PE, PB, PS, dividend yield, market cap), with a specific verb 'Get' and resource 'valuation metrics', distinguishing it from siblings like get_valuation_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes a <strategy> tag directly guiding to 'Directly invoke for current valuation snapshot', plus an example call, providing clear context for when to use, though missing explicit when-not-to-use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, openWorldHint=true, idempotentHint=true, indicating safe, idempotent read operation with variable results. The description adds no behavioral details beyond the purpose. It does not contradict annotations but adds minimal value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence) and uses structured XML tags for strategy and example. It is front-loaded with the core purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (as per context signals), the description does not need to detail return values. The description covers the basic purpose and usage. It lacks details like date range or dividend types, but completeness is adequate for a straightforward tool with good annotations and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one required parameter 'symbol'. Schema description coverage is 0% (only title 'Symbol' in schema), but the description provides 'Security symbol' which adds minimal clarification. With only one parameter, the schema combined with the description gives adequate meaning, but no further semantic detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get dividend history for a stock.' This is a specific verb+resource combination that distinguishes it from sibling tools like get_quote or get_financial_metrics. The strategy tag reinforces direct use with symbol.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a strategy tag: 'Directly invoke with symbol.' This tells when to use it (for dividend history) and how (directly). It does not explicitly mention when not to use or provide alternatives, but among many sibling tools the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint. Description adds no additional behavioral insights beyond stating it returns holdings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise, using XML tags for strategy and example. Every sentence is necessary and no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Has output schema, so return values are covered. Missing potential error conditions or behavior when report_date is omitted, but sufficiently complete for a simple read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description adds minimal meaning: 'symbol: Fund symbol', 'report_date: Report period (optional)'. It clarifies purpose but lacks format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Get' and resource 'fund holdings (stocks held by the fund)'. It is distinct from sibling tools like get_fund_nav_history and get_fund_quote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Strategy tag says 'Use to see what stocks a fund holds', providing clear context. No explicit when-not-to-use or alternatives, but adequate for a simple read tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the description does not need to repeat those. It adds no further behavioral context beyond retrieving a quote. Since annotations cover safety and idempotency, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a main line, a strategy tag, an example, and an Args list. It is well-structured and each part adds value. Slightly verbose due to the strategy tag, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to explain return values. It covers the optional parameters and usage strategy well. For a simple read tool with two optional parameters, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage). The description adds meaningful explanations for both parameters: 'symbols: Fund codes (optional; empty = all ETFs)' and 'fund_type: etf/open (default etf)'. This clarifies allowed values and behavior, significantly enhancing the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get fund/ETF quote', specifying it retrieves quotes for funds or ETFs. It distinguishes from sibling tools like get_quote or get_futures_quote by focusing on fund/ETF context. However, it doesn't explicitly clarify if it returns a single quote or a list, leaving minor ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a <strategy> tag with explicit guidance: 'Leave symbols empty for ETF overview; specify for specific funds.' It also provides an example. This gives clear context on when to use the tool but lacks explicit mention of when not to use alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. Description adds context about data type (GDP, CPI, PMI) and that indicator_code comes from list_macro_indicators, but does not disclose additional behavioral traits beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with strategy, critical rules, examples, and args sections. Front-loaded with purpose. Relatively concise, though some redundancy in listing args after the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has 5 parameters with output schema present. Description covers key parameters but omits count and offset (pagination). Given complexity, the description could be more complete to guide agent usage, especially for non-required parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description carries full burden. It describes indicator_code ('From list_macro_indicators'), start, and end (both optional with date format), but does not explain count and offset parameters. Provides partial value, not fully compensating for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves macro indicator history (GDP, CPI, PMI), distinguishing it from sibling list_macro_indicators which lists available indicators. Provides verb+resource and examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call list_macro_indicators first to obtain indicator_code, and mandates that indicator_code must come from that source. This provides clear when-to-use context and necessary prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, reducing the burden. The description adds that it returns 'recent trade ticks' and a max count, but lacks details on data freshness, pagination, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three clear parts: purpose, strategy/example, and parameter details. No wasted words; information is front-loaded and efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown) and low complexity, the description covers the essential behavior: symbol required, count optional with limits. It could mention data scope (e.g., exchange) or error cases, but it's adequate for a simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema coverage at 0%, the description compensates by explaining each parameter: 'symbol: Security symbol' and 'count: Number of trades (default 100, max 1000)'. This adds meaning beyond the schema's type and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get recent trade ticks for a symbol,' specifying the verb 'get', the resource 'trade ticks', and the scope 'for a symbol'. It distinguishes from siblings like get_depth (market depth) and get_intraday (intraday bars) by explicitly mentioning tick-level data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
A <strategy> tag advises 'Directly invoke for tick-level trade data,' providing some usage context. However, it does not explicitly state when not to use this tool or suggest alternatives, leaving the agent to infer from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety and idempotency. The description adds some behavioral context like returning three statement types and parameter effects, but does not disclose additional traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an intro, strategy, example, and Args list. It is concise with no filler, though it could be slightly tighter by blending the strategy inline. The front-loaded purpose and strategy are effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to cover return values. It adequately covers purpose, parameters, and usage strategy. It lacks error condition details but is complete for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description fully compensates by detailing each parameter in the Args section, including defaults and allowed values (e.g., kind: IS/BS/CF/ALL, report: annual/semi_annual/quarterly). This adds meaningful semantics beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get financial statements (Income Statement / Balance Sheet / Cash Flow),' specifying the exact resource and verb. This distinguishes it from sibling tools like get_financial_metrics or get_valuation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The <strategy> tag explains when to use different kind values ('Use kind=ALL for all three statements, or IS/BS/CF individually'), and the <examples> tag provides a concrete usage example. However, it does not explicitly state when not to use this tool or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds no additional behavioral details beyond the inherent nature of accessing historical data, but does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and includes a structured strategy and example. It is front-loaded with the main action and avoids excess verbiage, though the XML tags add slight noise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no schema description coverage, and an existing output schema, the description sufficiently covers usage with parameter explanations and an example. It is complete enough for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining each parameter: symbol with example, start/end with date format, count with default value. This adds necessary meaning beyond the schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get fund NAV history', a specific verb and resource. Among sibling tools, no other directly targets fund NAV history, so it's well-distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes a strategy ('Directly invoke with fund symbol') and an example call, providing clear guidance on when to use. Does not explicitly exclude alternatives, but the tool name and context make it obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint as true, so the description's behavioral disclosure is limited. The description adds a usage strategy but not significant behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one line for purpose, a <strategy> block, an <examples> block, and an Args section. Every sentence is necessary and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, annotations (readOnlyHint, etc.), and existence of an output schema, the description is adequately complete. It provides a clear example and parameter explanation without missing critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description compensates by explaining the 'symbol' parameter with an example ('000300.INDEX'). This adds meaning beyond the schema's type-only definition, but could be more precise on format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get index constituent stocks (e.g. CSI 300 constituents)', using a specific verb and resource. It differentiates well from sibling tools like get_sector_constituent by focusing on index constituents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a strategy and example for providing the index symbol, but lacks explicit guidance on when to use this tool versus alternatives. No exclusions or condition advice given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true. The description adds that this is a time series tool, which is valuable context beyond annotations. No contradictions are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: one sentence followed by a strategy tag and example call. Every element is useful and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description does not need to explain return values. It covers key aspects: time series nature, included metrics, and example usage. The annotations further ensure completeness for behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description repeats parameter names from the schema but adds minimal clarification: 'symbol: Security symbol' and 'count: Recent N periods (default 10)'. This is slightly better than the schema titles alone, but schema description coverage is 0%, and the added value is limited.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly uses the verb 'Get' with the resource 'financial metrics time series' and lists specific metrics (ROE, ROA, margins, debt ratio). This effectively distinguishes it from sibling tools like 'get_financial_statement' or 'get_valuation'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The <strategy> tag explicitly states 'Use for fundamental analysis over multiple periods,' providing clear context for when to use the tool. However, it does not mention when not to use or compare to alternatives like 'get_financial_report_latest'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, and idempotentHint. The description correctly states the read-only nature (getting a quote) and does not contradict annotations. However, it adds minimal behavioral detail beyond what annotations convey, such as potential rate limits or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for purpose, a strategy tag, and an example tag. Every element serves a purpose with no wasted words, and the structure is front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate given the tool's simplicity (one optional parameter) and robust annotations. However, it lacks explicit mention of what the output contains (e.g., multiple futures quotes when exchange is empty). Since an output schema exists, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the 'exchange' parameter. The description compensates by listing the valid exchange codes and explaining the optional behavior with an example. This adds significant meaning beyond the raw schema's type and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get futures quote' and lists the specific exchanges (SHFE, DCE, CZCE, CFFEX, INE), which differentiates it from sibling tools that retrieve quotes for other asset types (e.g., get_option_quote, get_forex_quote, get_quote for stocks).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a strategy: 'Leave exchange empty for all; specify for a single exchange.' This provides clear guidance on parameter usage. However, it does not explicitly mention when not to use this tool or direct users to alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, and idempotentHint. The description adds no behavioral details beyond the basic purpose, though it does not contradict annotations. No added context about results variability, pagination, or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is succinct: one-line purpose, structured <strategy> and <examples> tags, and a parameter list. Every element adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters, no required ones, and an output schema exists, the description is largely complete. It explains what data is returned (rankings by change rate) and how to use parameters. Missing explicit detail on sorting direction (ascending/descending), but strategy implies top/bottom.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description provides clear parameter definitions: sector_type (default 'industry') and count (default 20), plus an example. This meaningfully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get industry/concept ranking by change rate.' The example shows usage with specific parameters, and the strategy tag clarifies the purpose: 'find top/bottom performing sectors.' This is specific and distinguishable from siblings like get_hot_rank.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The <strategy> tag explicitly says 'Use to find top/bottom performing sectors,' providing clear context. However, it lacks explicit exclusion or alternative tool references, though the sibling list suggests other ranking tools exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds context by listing the specific rate types (LPR, SHIBOR, LIBOR) and parameter behavior, consistent with annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one-line purpose, strategy, example, arg list) and well-structured. It could be slightly more streamlined, but every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters (one required), no enums in schema, but description clarifies allowed values and date format. Output schema exists, so return values need not be explained. The description is sufficient for a simple data retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates by explaining rate_type values ('lpr/shibor/libor'), start/end date format ('YYYY-MM-DD'), and optionality. This adds significant meaning beyond the schema's property names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get interest rate data (LPR, SHIBOR, LIBOR),' specifying the exact resource and scope. It is clear but does not explicitly differentiate from sibling tools like get_macro_data or get_exchange_rate, which could also contain interest-related data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a strategy ('Directly invoke with rate_type') and a concrete example, guiding when to use. However, it does not mention when not to use or provide alternatives, though no sibling tool covers the same domain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint, openWorldHint) already indicate a safe, read-only operation. The description does not contradict annotations but adds no further behavioral details (e.g., rate limits, pagination), so it meets baseline expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: a single sentence for purpose, XML tags for strategy and example, and a brief Args section. It is front-loaded with the key action and contains no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no nested objects, with output schema), the description covers the main need: getting intraday data for a symbol on a date. It doesn't explain timezone or range limits, but with existing annotations and output schema, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds 'Date YYYY-MM-DD (default: today)' and explicitly lists parameters, providing format and default information beyond the schema titles. This compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get intraday time-share data for a symbol', using a specific verb and resource. It distinguishes from siblings like get_quote (snapshot) and get_candlesticks (candlestick data) by focusing on intraday tick data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes '<strategy>Directly invoke for intraday price ticks.</strategy>', implying when to use. It provides an example but does not explicitly mention when not to use or alternatives, though the context of sibling tools implies them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds no additional behavioral context beyond stating the tool retrieves reports. With annotations covering safety profile, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a strategy tag, example, and parameter list. Every sentence adds value, no redundancy. Front-loaded with core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters and an output schema, the description covers the purpose and parameters adequately. It does not explain return values, but output schema fulfills that. Minor gap: no mention of pagination or freshness, but acceptable for a simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden. It explains 'symbol' as security symbol and 'count' as number of reports with default 10, providing meaning beyond the schema titles. This compensates for lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves analyst research reports for a stock, with strategy tag specifying use for analyst ratings and target prices. This is a specific verb+resource combination that distinguishes it from siblings like get_news or get_quote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The strategy tag provides explicit context for when to use: for analyst ratings and target prices. It lacks exclusions or alternative recommendations but effectively guides usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds no behavioral disclosures beyond explaining parameters and usage. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with sections for strategy, examples, and args. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description does not need to explain return values. It covers purpose, parameters, and usage adequately, though more detail on holder_type values could be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description includes an 'Args:' section that explains each parameter (symbol, holder_type, count) with meaning and defaults, thus compensating for the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get top 10 shareholders history', which is a specific verb+resource. It distinguishes from sibling tool 'get_shareholder_count' (which likely gets total count) by focusing on top shareholders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a <strategy> tag instructing to 'Directly invoke with symbol' and provides an example. While it doesn't explicitly say when not to use, the context and example give clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnly, openWorld, and idempotent hints. The description adds the time-series nature and example, but does not elaborate on return format or pagination. With annotations covering safety, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, strategy, example, and args list. It is concise with no fluff, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool and the presence of an output schema (not shown), the description covers the key aspects. It could mention default date ranges, but overall it is complete enough for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains each parameter: symbol (security symbol), metric (pe/pb/ps/dividend_yield with default pe), start and end (dates YYYY-MM-DD). This adds value beyond the schema's type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves valuation metric history (PE, PB, PS, dividend yield) over time, which distinguishes it from sibling 'get_valuation' (current metrics). The verb 'Get' and resource 'valuation metric history' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The strategy explicitly says 'Use to check if current valuation is high/low historically,' providing clear context. No alternatives or when-not-to-use are given, but the sibling tools are diverse enough that this guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description need not repeat safety traits. It adds context about date range and symbol optionality but does not disclose details about output format or any side effects. This is adequate given the annotations, but no additional behavioral details are provided beyond what is already indicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a single sentence for purpose, a strategy hint, an example, and a bulleted list of parameters. Every element serves a purpose without redundancy. It is front-loaded with the core purpose and immediately usable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description does not need to explain return values. It covers all input parameters, provides usage strategy, and includes a concrete example. For a read-only retrieval tool with three optional parameters, the description is complete and self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage (no descriptions in input schema), so the description must compensate. It provides brief but clear explanations for each parameter: 'symbol: Stock symbol (optional)', 'start: Start date YYYY-MM-DD', 'end: End date YYYY-MM-DD'. This adds meaning beyond the schema's defaults and titles, though it could include more constraints (e.g., date format exactly as shown).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get block trade (大宗交易) records' and includes a strategy and example that differentiate it from sibling tools like get_trades. The verb 'Get' and specific resource 'block trade' make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The strategy 'Leave symbol empty for all market block trades' provides clear guidance on when to use the tool with or without a symbol. The example shows typical usage with date parameters. However, it does not explicitly state when not to use this tool or mention alternative tools for other trade types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint, openWorldHint, and idempotentHint, so the description does not need to restate these. The description adds that it provides bond price, premium, and YTM, but does not disclose other behavioral aspects like data freshness or limitations. With annotations present, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and efficient: a one-line purpose, a strategy tag, an example, and a parameter definition. No wasted words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and an output schema, the description adequately explains the input format and the contents of the analysis (bond price, premium, YTM). Combined with annotations, it provides sufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for the single parameter symbol. The description adds a clear description with format and example ('Convertible bond symbol (e.g. 113527.BOND)'), providing meaning beyond the schema's minimal 'Symbol' title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (get) and resource (convertible bond value analysis), listing specific outputs like bond price, premium, and YTM. It distinguishes from siblings which are other financial data tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a strategy tag directing direct invocation with convertible bond symbol and provides an example. It clearly indicates the context for use, but does not explicitly mention when not to use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety and retry behavior. The description adds context that the list contains 'major institutional trades' but does not disclose other behavioral traits like pagination or limits. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the purpose, and includes a strategy and example without unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description does not need to explain return values. It fully covers the tool's use with all three optional parameters explained and annotations providing safety context. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description's 'Args' section adds meaning by explaining start/end as YYYY-MM-DD dates and symbol as an optional stock filter, which compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the 'dragon-tiger list', also explained as 'major institutional trades', which is a specific resource with a clear verb. Among siblings like get_block_trade or get_trades, this is uniquely identified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs to provide a date range and optionally filter by symbol, which gives clear context. However, it does not explicitly differentiate when to use this tool versus other trade-related siblings or mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, indicating safe, read-only behavior. The description adds no further behavioral traits beyond stating the data type (filings/announcements), so it does not significantly enhance transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a title, strategy, example, and parameter list. Every element adds value: the strategy guides usage, the example illustrates invocation, and parameter definitions are brief yet informative. No redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two parameters, one required) and the presence of an output schema, the description sufficiently explains what the tool does, how to use it, and what parameters are needed. The strategy and example complete the picture for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by briefly defining both parameters: 'symbol: Security symbol' and 'count: Number of filings (default 20)'. Though minimal, it provides essential meaning missing from the schema, including a default value via the example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get company filings/announcements (公告)', specifying both the action and resource. The strategy further distinguishes it as for 'official company announcements', differentiating it from sibling news tools like get_news or get_news_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The strategy explicitly says 'Directly invoke with symbol for official company announcements', providing clear context for when to use this tool. However, it does not specify when not to use it or mention alternatives, leaving a slight gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, covering safety. The description adds no behavioral details beyond these, such as response structure or rate limits, but the presence of an output schema mitigates the need for some return format explanation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no fluff. It uses XML tags (strategy, example) for structure, presents purpose first, then usage context, then parameter list. Every element adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has well-documented annotations, a clear purpose, and an output schema (not shown but expected). The description, combined with structured fields, provides sufficient context for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides meaningful explanations: 'symbol: Security symbol' and 'report_date: Report period (optional)'. The example '000001.SZ' clarifies symbol format, but report_date format is unspecified, which could be improved.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get institutional holdings for a stock' with a specific verb and resource. The strategy tag reinforces the purpose ('use to see which institutions hold the stock'), and it is distinct from sibling tools like get_fund_holding or get_shareholder_top.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a <strategy> tag providing context on when to use ('to see which institutions hold the stock') and a concrete example. However, it does not explicitly compare to alternative tools or state when not to use, leaving minor ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety. The description adds minimal behavioral context (date default behavior) but is not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: purpose, strategy, example, arguments. Every sentence adds value and is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and an output schema present, the description covers all necessary usage aspects: purpose, parameter, and example.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema lacks parameter descriptions (0% coverage). The description compensates with 'Args: date: Date YYYY-MM-DD (default: today)', specifying format and default behavior clearly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Get limit-up stock pool (涨停板)', using a specific verb and resource. It is clearly differentiated from sibling tools like get_limit_down_pool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to leave date empty (today) versus specify a date (historical). However, it does not explicitly state when not to use this tool or suggest alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and openWorldHint. The description adds context that it returns trading status (open/closed) for specific markets, which is consistent with annotations. It does not contradict and enhances transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence plus a strategy and an example. It is front-loaded with the main purpose and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0 parameters, annotations covering safety/idempotency, and an existing output schema, the description provides complete guidance. The strategy and example further clarify usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so description need not add param info. Schema coverage is 100% (trivially). Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Get current trading status for all markets (CN/HK/US)' with a specific verb and resource, and the strategy further clarifies it is for checking if markets are open. The name and scope distinguish it from sibling tools focused on market summary or anomaly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The strategy says 'Directly invoke to check if markets are open,' implying when to use it, but it does not provide when-not-to-use or alternatives like 'get_market_summary' or 'get_market_anomaly'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint. Description adds return content counts but does not disclose additional behavioral traits beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (2-3 sentences) with strategy and example. Front-loaded purpose. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with one optional parameter, output schema exists, annotations cover safety. Description sufficiently explains purpose, parameters, and usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has only one parameter with type and default. Description adds valid values (CN/HK/US) and default, improving agent understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Get' and resource 'market summary' with specific data points (up/down/flat counts, limit counts, total turnover). Distinct from siblings like get_market_status and get_market_anomaly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Strategy tag explicitly states 'Use for overall market breadth snapshot.' Example provided. No exclusions or when-not-to-use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds the distinction between symbol and market modes but does not elaborate on pagination, rate limits, or data completeness. Given the annotations, the description provides adequate but not rich additional behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence followed by a strategy tag and an example. It is front-loaded with the main purpose, uses tags for structure, and contains no unnecessary words. Every sentence provides value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 optional parameters, no required params), the description covers the necessary context: what the tool does, how to use parameters, and an example. An output schema exists, so return values are not required. The tool is well-defined for an AI agent to select and invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the full burden for parameter semantics. It explains that 'symbol' is optional and that leaving it empty fetches market headlines, and 'count' defaults to 10. It also includes an example with a concrete symbol format. This adds meaningful semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get news for a symbol or market,' specifying the action and the two distinct modes (symbol-specific or market headlines). This distinguishes it from sibling tools like 'get_news_search' which likely searches news.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a 'strategy' tag that explicitly instructs when to provide a symbol (for stock news) and when to leave it empty (for market headlines). It also provides an example. It does not explicitly exclude alternatives but gives clear context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, openWorldHint, idempotentHint. Description adds 'Returns real-time or latest close,' which clarifies timing behavior and is consistent with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with a main statement, strategy, critical rule, and example. No fluff. Slightly longer than minimal but each part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with one parameter and output schema present. Description covers how to invoke, what it returns (real-time/latest close), and critical formatting rules. Adequate for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage but description adds critical format rule for symbols ('<code>.<market> format'), which adds meaning beyond the schema's array of strings. Example further clarifies usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get latest quote snapshot for one or more symbols.' This specifies the verb, resource, and scope, distinguishing it from sibling tools like get_candlesticks or get_depth.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes strategy ('Directly invoke with symbol list') and critical rule about symbol format ('must be .<market>'). Provides example. Missing explicit guidance on when not to use or alternatives, but sufficient for most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint. The description adds a key behavioral constraint: sector_name must be Chinese, which is not covered by annotations. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a brief phrase, then XML-like guidance and an Args list. It is somewhat verbose but front-loaded with the core purpose. Each section adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, output schema exists) and annotations, the description is adequately complete. It explains the input constraints and provides examples. The return value is covered by the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden. The Args section provides basic semantics: sector_type is 'industry/concept' and sector_name is 'Sector name (Chinese, e.g. '小金属')'. This adds some meaning but is not very detailed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get stocks within a sector', which is a specific verb and resource. It differentiates from siblings like get_sector_quote (which gets quotes) and get_index_constituent (index constituents).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides when-to-use guidance via <strategy> and <critical_rules>, stating that sector_name must be Chinese and that get_sector_quote should be used to find names. This effectively guides the agent on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds that it returns real-time quotes and specifies sector_type values. This adds some context but does not describe potential errors or rate limits. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a strategy, example, and args list. Every sentence adds value; no redundancy. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, 1 required) and presence of an output schema, the description adequately covers what is needed: it explains the two parameters, usage strategy, and return type (sector list and real-time quotes). No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds meaning by listing allowed values for sector_type ('industry/concept') and explaining the optional sector_name and its default behavior. This compensates for lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get sector list and real-time quotes', specifying the resource (sectors) and action (get quotes). It distinguishes from siblings like get_sector_constituent by focusing on quotes and listing. The strategy and example further clarify.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly guides usage: 'Leave sector_name empty for all sectors; specify for a single sector.' It also provides an example. However, it does not explicitly state when not to use this tool compared to siblings, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and openWorldHint. The description adds specific data fields returned (issue price, PE, etc.), which aligns with the read-only nature. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a single core sentence, a brief strategy tag, an example, and parameter docs. Every element serves a purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description covers the tool's purpose, usage context, and parameter adequately. The example provides concrete usage. Could potentially mention the required suffix convention, but it's implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description clarifies the parameter as 'New stock symbol', adding domain-specific meaning beyond the bare schema. The example with '301389.SZ' further clarifies the expected format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get IPO detail for a symbol' and lists specific fields (issue price, PE, industry, sponsor). It distinguishes from the sibling 'get_ipo_calendar' by suggesting use after that tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The strategy tag explicitly advises using this tool after finding an IPO from get_ipo_calendar, providing clear context for when to use it. No explicit when-not-to-use guidance, but the positive directive is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, and idempotentHint. The description adds context about the anomaly types and default behavior (count default, type default). No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using a short sentence plus structured tags (strategy, critical_rules, examples) that are front-loaded. Every element adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 optional parameters, read-only, idempotent, open-world), the description covers all necessary aspects: what it returns, how to filter, default behavior, and example. An output schema exists but is not shown; the description does not need to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has no descriptions (0% coverage). The description fully explains both parameters: anomaly_type with valid values and count with default. This compensates completely for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves intraday anomaly alerts with specific types (rocket/dive/large_buy/large_sell). The purpose is specific and distinguishable from siblings, though no explicit comparison is made.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on how to use the tool: leave anomaly_type empty for all or specify a single type. An example is given. However, it does not explicitly discuss when not to use it or alternatives, but given the sibling tools are distinct, this is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the description need not restate these. It adds no additional behavioral context beyond parameter optionality and format, which is adequate but not extensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using only three lines plus a strategy hint and example. It is front-loaded with the core purpose, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 optional parameters, explicit output schema), the description covers purpose, parameters, usage strategy, and an example. It is complete for the agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description fully explains all three parameters: symbol (optional; empty = all market), start and end dates in YYYY-MM-DD format. The example further clarifies usage, compensating for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get restricted share release (解禁) schedule,' using a specific verb and resource. The Chinese term disambiguates from other financial data tools, distinguishing it from sibling tools like get_ipo_calendar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a strategy hint ('Leave symbol empty for market-wide upcoming releases') and an example, giving clear direction on usage. It lacks explicit when-not-to-use or alternatives, but the purpose is self-contained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, openWorld, idempotent. Description adds pagination limits and board constraints, enhancing 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Structured with strategy, rules, examples, and args. Slightly verbose but front-loaded with key purpose. Consistent with param docs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers input well; output shape not described but output schema exists. Annotations and rules provide sufficient context for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description fully documents all 4 parameters: markets, board options, count default/max, offset default. Compensates effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists securities for a market and helps discover valid symbol codes. Distinct from siblings like get_quote or get_candlesticks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Strategy section explicitly says to use for discovering symbol codes. Critical rules provide valid market and board values. Lacks explicit when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint. Description adds that it covers 'major currency pairs' and behavior when pairs empty. No contradictions, and adds value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short, with first line summary, strategy tag, example, and parameter description. Every sentence is purposeful, well-structured, and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one optional parameter, rich annotations, and an output schema indicated, the description covers purpose, usage strategy, and parameter behavior. No missing critical information for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. Description explains 'pairs: Currency pairs (optional; empty = all)' and includes example with format 'USD/CNY'. This adds meaning beyond schema type, though format specifics could be more detailed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get forex quote for major currency pairs', with a specific verb and resource. Among siblings like get_quote, get_futures_quote, it distinguishes itself for forex/currency pairs, making selection unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Strategy tag and example provide explicit guidance: 'Leave pairs empty for all major pairs.' This tells when to omit the parameter. No explicit distinction from similar get_exchange_rate, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint. Description adds default behavior for date, which is consistent and useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with front-loaded purpose, a strategy line, and an example. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with one parameter; description explains the date behavior and provides an example. Output schema exists, so return values need not be explained. Complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (date) with no schema description. The description explains format YYYY-MM-DD and default behavior, adding meaning beyond the schema type and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves the limit-down stock pool (跌停板), using a specific verb and resource. Sibling tool get_limit_up_pool exists, so the name and description effectively distinguish it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes a strategy to leave date empty for today and an example call. Provides clear context for when to use it, though no explicit exclusion of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Disclosures beyond annotations: symbol is optional, empty returns all REITs. Annotations already indicate readOnly, openWorld, idempotent. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences plus an Args section. No wasted words; essential information front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, description need not explain returns. It covers usage for a simple optional parameter. Could add more context on REITs, but sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 0%, but description fully describes the single parameter 'symbol: REITs symbol (optional; empty = all)', adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get REITs quote', a specific verb and resource. The strategy differentiates it from sibling tools like 'get_quote' by focusing on REITs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: 'Leave symbol empty for all REITs.' Includes an example call. Lacks explicit when-not-to-use or alternatives, but the context implies it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint. Description adds context about returning revenue breakdown, consistent with read-only nature. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Highly concise: one-line purpose, strategy tag, example, and brief parameter descriptions. No unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, description doesn't need return details. Covers purpose, usage, and parameters completely for a simple 2-param tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully explains both parameters: symbol as 'Security symbol' and by as 'product/region (default product)'. Compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states specific verb 'Get', resource 'business segment breakdown', and scope 'by product/region'. Clearly distinguishes from sibling tools like get_valuation or get_financial_metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes strategy tag 'Use to understand revenue composition' and an example call. Provides clear context for when to use, though lacks explicit when-not-to-use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations by explaining the meaning of an empty symbol parameter and that the tool returns financing and short selling data. Annotations already declare readOnly, openWorld, and idempotent, so the description complements them without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured, using a format tag, an example, and parameter arguments. Every sentence adds value, and the most critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with 3 parameters and an output schema, the description covers purpose, parameter usage, and provides an example. No additional context is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema documentation coverage, the description fully compensates by explaining each parameter: symbol is optional with aggregate behavior, start and end are dates in YYYY-MM-DD format, and an example usage is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves margin trading data (financing + short selling), which is specific and distinct from sibling tools that cover other data types like block trades, bond yields, or financial metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear usage instructions: leaving symbol empty for market aggregate or providing a symbol for an individual stock. It also includes an example call. However, it does not explicitly contrast with alternative tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is clear. The description adds behavioral constraints (market must be CN/HK/US, dates YYYY-MM-DD) and implies a read-only lookup, consistent with annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with comments, strategy, critical rules, examples, and an 'Args' section. However, the 'Args' section largely duplicates the parameter descriptions, making it slightly redundant. Still, it is clear and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (though not shown in full), the description need not explain return values. The description covers all necessary aspects: purpose, valid inputs, and usage strategy. It is complete for a parameter-rich tool with high annotation coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must fully explain parameters. It does: market as 'Market code: CN / HK / US', start as 'Start date YYYY-MM-DD', end as 'End date YYYY-MM-DD'. This adds meaning beyond the raw schema, but could be improved by explicitly listing allowed values for market.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get trading days for a market between dates.' This is a specific verb+resource combination that distinguishes it from siblings like 'get_quote' or 'get_candlesticks' which return different financial data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a <strategy> section that tells the AI to directly invoke with market and date range, <critical_rules> specifying valid market codes and date format, and an <examples> section showing exact usage. This provides comprehensive guidance on when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint as true, so safety is clear. The description adds useful context (preparatory step for get_macro_data) but does not disclose any additional behavioral traits beyond what annotations cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise and front-loaded with purpose. The embedded strategy and example tags are unconventional but add value without excessive length. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 optional parameters, no required fields, and an output schema exists, the description fully covers what an agent needs: what the tool does, how to use it, and how it fits into a workflow (paired with get_macro_data).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no param descriptions in schema), so description must compensate. It clarifies 'country' values (CN/US/HK/JP/EU), 'count' default and max behavior, and 'keyword' as optional filter. Adds meaning beyond schema types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists available macro indicators such as GDP, CPI, PMI, and explicitly connects to get_macro_data by suggesting discovery of indicator_code. Distinguishes from siblings like get_macro_data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides strategy: 'Use first to discover indicator_code, then pass to get_macro_data.' Also includes an example invocation with 'country' parameter, guiding correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, open-world, and idempotent behavior. Description adds operational constraints (symbol format, parameter precedence, default/max count) that go beyond annotations, providing comprehensive behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections (strategy, critical rules, examples, Args). Front-loaded with purpose and usage. Slightly verbose but all content is valuable given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, description focuses appropriately on input parameters and usage rules. Covers all necessary details for correct invocation, including defaults, constraints, and examples. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so description carries full burden. It explains all parameters with default values, allowed values (period), and meaning (symbol format). Adds significant value beyond the schema's titles and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states 'Get candlestick (OHLCV) data for any asset class', using a specific verb and resource. It clearly distinguishes from sibling tools which cover different financial data types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit strategy for use (directly invoke with symbol, infer asset_class) and critical rules (symbol format, parameter precedence). Includes examples. Does not explicitly exclude alternative tools but gives enough context for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/agentladle/mcp-akshare'
If you have feedback or need assistance with the MCP directory API, please join our Discord server