futu-opend-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have clearly distinct purposes, with detailed descriptions differentiating them. However, the pair get_institutional_holdings and get_institution_holdings are very similarly named and require careful reading to avoid confusion, slightly lowering the score.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern (e.g., get_snapshot, search_quote, screen_stocks), making it predictable for agents.
Tool Count2/5
With 53 tools, the server is extremely extensive. While the financial domain is broad, this number is excessive and may overwhelm agents, leading to difficulty in selecting the right tool.
Completeness4/5
The tool set covers a wide range of financial data needs including stocks, options, fundamentals, institutional holdings, and economic calendars. Minor gaps like lack of order book depth or tick data exist, but the core data surface is comprehensive.
Average 3.2/5 across 53 of 53 tools scored. Lowest: 1.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 24 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden to disclose behavioral traits like read-only nature or authentication needs. It fails to mention any such details, leaving the agent uninformed about side effects or requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief but not concise in a useful way; it wastes space listing redundant language translations instead of delivering functional information. The key term 'company profile' is buried, and no essential details are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 param, no output schema, no annotations), the description is critically incomplete. It provides virtually no guidance on input semantics, expected output, or use cases, making it inadequate for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'code' has no description in the schema (0% coverage) and the tool description provides no explanation of what 'code' represents (e.g., stock ticker, company ID). This omission forces the agent to guess the parameter's meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Company profile - 公司概况/公司详情/公司简介/company profile/主营业务.' merely restates the tool name and provides synonyms in multiple languages, lacking a specific verb or resource that distinguishes what the tool does. It does not differentiate from sibling tools like get_stock_info or get_company_executives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines or context are provided. The description does not indicate when to use this tool versus alternatives such as get_stock_info or get_company_executives, which may offer similar company data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose any behavioral traits such as read-only nature, authentication requirements, rate limits, or pagination. The description does not even state that the tool retrieves data; it merely labels the output as 'profile.' For a tool with no annotations, the description carries the full burden, which it fails to meet.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one line plus translation) but fails to be useful. It is under-specified rather than efficiently concise. Important information is missing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, annotations, and parameter descriptions, this tool definition is severely incomplete. An agent cannot determine what data the tool returns, how to interpret the inputs, or any side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%. The description does not explain what 'market' or 'institution_id' represent, what valid values are, or how to construct the required inputs. The schema itself provides no descriptions, so the tool is largely unusable without external knowledge.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description is nearly a tautology: 'Institution profile - 机构概况/机构详情.' It does not specify what the profile contains (e.g., name, address, sector) and does not differentiate from sibling tools like get_institution_holdings or get_institution_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. For example, it does not indicate whether this returns basic static info vs. dynamic holdings or distribution data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not state whether the tool is read-only, destructive, or requires authentication. As a data retrieval tool, it likely does not modify state, but that is not clarified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one phrase), which is concise but insufficiently informative. It sacrifices essential details for brevity, making it under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With two required parameters, no output schema, and many sibling tools, the description lacks completeness. It fails to explain input constraints, output structure, or usage context, making it inadequate for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two required parameters (market, institution_id) with 0% description coverage. The description adds no meaning to these parameters, leaving the agent without guidance on valid values or formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Institution holding industry distribution - 机构持仓行业分布' indicates the tool returns industry distribution data for institutional holdings, clarifying the resource. However, it lacks a clear verb (e.g., 'get', 'retrieve') and largely restates the tool name, providing minimal differentiation from siblings like get_institutional_holdings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings such as get_institutional_holdings or get_holder_detail. There is no mention of prerequisites, context, or alternatives, leaving the agent to guess based on the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must carry the burden. It does not mention read-only nature, side effects, authentication, rate limits, or data range. The brief description gives minimal behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence plus Chinese translation). While concise, it lacks necessary detail; it is under-specified rather than efficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and a single parameter without description, the description is extremely incomplete. It does not explain the output format, time series granularity, or how to interpret the data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'code' has no description in the schema (0% coverage) and the tool description does not explain what 'code' represents (e.g., stock ticker, ISIN). The description adds no semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it produces a 'capital flow time series (main-force in/out)' but the verb 'get' is implied and the term 'main-force' is ambiguous. It does not clearly distinguish from similar siblings like 'get_capital_distribution' or 'get_holder_detail'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, no prerequisites or context provided. The agent is left to infer usage from the name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose behavioral traits such as whether it is read-only, any authentication requirements, or rate limits. It only names metrics, missing opportunities to inform the agent about side effects or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one line) but cryptic. It includes Chinese characters and a dash, which may confuse an English-speaking agent. It is not front-loaded with essential information, requiring the agent to infer meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters and no output schema or annotations, the description is severely incomplete. It does not describe the output format, how to interpret results, or any usage context. Given the complexity of financial metrics, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 3 parameters (num, code, currency_code) with 0% schema description coverage. The description does not explain any parameter semantics, such as what 'code' represents or the meaning of 'num'. The agent cannot determine how to set these parameters based on the description alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Operational efficiency' and lists specific metrics (e.g., headcount per employee, revenue per employee), indicating the tool retrieves operational efficiency metrics. However, it does not explicitly distinguish from sibling tools like get_revenue_breakdown or get_financial_statements, which might also contain efficiency data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description merely lists metrics without any context about when it is appropriate to use or what prerequisites exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility. It discloses that the tool returns price detail and IV crush per earnings day, but does not explain what 'price detail' includes (e.g., open, high, low, close, volume), the time window around earnings, or any rate limits or permissions. The behavioral details are insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes redundant Chinese text that repeats the English meaning. It is not overly verbose, but the inclusion of multiple languages for the same content reduces conciseness. The core message is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description does not fully specify what the tool returns. It mentions 'price detail + IV crush' without defining the structure or format. Additional constraints like number of earnings days or data frequency are missing, making it incomplete for an agent to fully understand the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'code' with no description, and schema coverage is 0%. The description does not explain what 'code' represents (expected to be a stock ticker), leaving the agent to infer from context. This fails to add meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'per-earnings-day price detail + IV crush' for HK/US stocks. It specifies the resource (earnings day data) and the verb (Get), making the purpose understandable. However, it does not explicitly differentiate from sibling tools like get_earnings_calendar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus other related tools such as get_earnings_calendar or get_kline. The only constraint given is 'HK/US stocks only', which is a restriction but not a usage scenario comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose any behavioral traits such as rate limits, required permissions, or side effects. It is likely a read operation but this is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is very short with one sentence and some keywords. It is concise but lacks structure; it does not usefully front-load information for an agent. Could benefit from a clearer explanation of what a Morningstar report contains.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the input schema (one param) and absence of output schema, the description is incomplete. It fails to explain return format or content, leaving the agent guessing about what data will be retrieved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'code' has no description in the schema or the tool description. Description does not clarify that 'code' is a stock or REIT ticker symbol. With 0% schema description coverage, the description adds no value to parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it provides Morningstar research reports including fair value, moat, and bull-bear analysis for stocks and REITs. It distinguishes from siblings by focusing on Morningstar's proprietary research, but does not explicitly differentiate from other research tools like get_analyst_consensus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_company_profile or get_analyst_consensus. Description only states what it is, not when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the basic operation without disclosing any behavioral traits such as read-only vs. mutating, required permissions, rate limits, or whether the tool aggregates data across exchanges. The description is too minimal to provide adequate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence) and includes a bilingual note, which helps with multilingual agents. However, the extreme brevity sacrifices crucial context and parameter guidance. It is concise but not effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and a simple input parameter, the description should at least mention return format (e.g., list of plate names/IDs) and clarify that the input is one or more stock codes. It also fails to differentiate from similar tools like get_industrial_plate. The description is incomplete for an AI agent to use reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The parameter 'codes' is an array of strings, but the description does not explain what codes represent (e.g., stock tickers, internal IDs) or how they should be formatted. The description adds no meaning beyond the schema, leaving the agent to guess valid input values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Get' with the resource 'plates a stock belongs to', clearly indicating the action and resource. It distinguishes from sibling tools like get_plate_stocks (which lists stocks in a plate) and get_industrial_plate (which may focus on industrial sectors). However, 'plates' is ambiguous and could benefit from clarification (e.g., 'industry sectors or concepts').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Sibling tools include get_industrial_plate and get_plate_stocks, but the description does not explain the relationship or when to prefer one over the other. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description offers no behavioral details such as data returned, safety, or authorization needs. It only restates the tool's purpose minimally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence with Chinese synonyms), which is concise but lacks structure. It provides no additional context beyond the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With two parameters and no output schema, the description fails to complete the picture. The tool's complexity is low, but the description is insufficient for an agent to use it correctly without external documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters 'code' and 'period_id'. Their meaning and usage are completely undocumented, forcing reliance on external knowledge.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Shareholding structure summary' with bilingual synonyms, indicating it provides an overview of shareholding. However, it does not distinguish from sibling tools like get_holder_detail or get_institutional_holdings, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. With many sibling tools related to holdings, the description lacks any context about preferred use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only states that the tool returns rating and target price for stocks and REITs. It does not disclose data sources, update frequency, or any limitations such as coverage constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief at two lines, but includes extraneous Chinese characters and slashes that reduce readability. Still, it is efficient and avoids unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has only one parameter and no output schema, the description should provide more context about the returned data. It mentions rating and target price but not structure, units, or examples. The tool is simple, but the description lacks enough detail for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the single required parameter 'code'. The parameter name alone is insufficient for an agent to determine its format or valid values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Analyst consensus rating + target price' and specifies asset types 'Stocks + REITs', making the tool's purpose immediately understandable. However, it does not explicitly differentiate from sibling tools that might also provide ratings, such as get_snapshot or get_stock_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, contexts, or exclusions from usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It mentions order categories but does not state whether data is historical or real-time, nor any side effects or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is very short and to the point, but lacks sufficient detail to be fully informative. It is concise but at the expense of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and minimal description, the tool's return format and meaning of categories are not explained. The agent lacks key information to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter 'code' with 0% schema description coverage. Description adds no meaning beyond the schema; 'code' could refer to a stock ticker or index, but is unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies 'capital distribution' with categorization by order size (super/big/mid/small), and the bilingual text helps clarify. It distinguishes from sibling tools like get_capital_flow and get_institution_distribution by focusing on order sizes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Missing context on prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should disclose behavioral traits. It indicates a read operation (holding changes) but fails to mention any potential side effects, rate limits, data freshness, or required permissions. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes redundant Chinese translation and a fragmented structure. It could be more concise and organized, e.g., grouping parameter explanations. It earns its place but lacks polish.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 3 parameters, no output schema, and no annotations, the description is insufficient. It does not describe the return format, pagination, error handling, or typical use context. The agent would struggle to use this tool correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description only explains filter_type with a mapping. The required parameter 'code' and optional 'num' are not explained at all, leaving ambiguity about their meaning (e.g., stock code format, count limits).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves shareholder holding changes and lists four types (increase, decrease, new, clear), including Chinese translations. It distinguishes from siblings like get_institutional_holdings by focusing on shareholder-level changes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides filter_type options but does not specify when to use this tool versus alternatives like get_holder_detail or get_institutional_holdings. No guidance on prerequisites, use cases, or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits like error handling, rate limits, or authentication needs. It only mentions supported prefixes but does not explain what happens with invalid codes, whether it requires authentication, or if it has any destructive or read-only behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences, front-loaded with the main purpose, and includes a Chinese translation. No redundant information. It efficiently conveys the essential idea.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one required parameter, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't mention the return format, whether it returns a single state or multiple, or any edge cases. A more complete description would include these details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not explain what 'codes' are (e.g., ticker symbols, format) beyond mentioning prefixes. There is no guidance on how to structure the array, case sensitivity, or limits. The description adds no value over the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies that the tool gets market state (open/closed/lunch break) for codes with supported prefixes. It clearly indicates the resource (market state) and action (get). While it doesn't explicitly differentiate from siblings, the context of many financial data tools makes its unique purpose evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There is no mention of when not to use it or which sibling tools might be more appropriate. The description only states what it does, not the best context for invoking it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose behavioral traits such as read-only nature, data freshness, pagination, or error behavior. It only states the basic function, leaving significant gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: one sentence with a list of market codes. It is front-loaded and wastes no words. However, it could still benefit from brief param explanations without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters, no output schema, and zero annotations, the description is incomplete. It does not explain return format, date constraints, or how max_count affects results. The tool's behavior beyond basic listing is unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description only partially compensates by listing allowed market values. The 'date' and 'max_count' parameters are not explained at all, leaving their purpose and format ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves earnings-release calendars for a market, specifying valid market codes (US/HK/CN/SG/MY/JP). The verb 'Get' and resource 'earnings-release calendar' are specific. While it distinguishes from sibling calendar tools (e.g., dividend, economic) by focusing on earnings, 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention conditions like date range or currency, nor does it compare with other similar tools (e.g., get_dividend_calendar). Usage context is only implied by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavioral traits. It indicates the output includes leader_name, which is a read-like behavior. However, it does not mention any side effects, authentication needs, or limitations. The description is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief (two sentences) and to the point. It includes both English and Chinese text, which may be redundant. Despite brevity, it conveys the core purpose and a linked tool. It is not verbose, but structuring with more param details would improve it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and a single undocumented parameter, the description is incomplete. It does not specify the format of the returned data (list, object, etc.) beyond mentioning leader_name. For a tool with such minimal schema coverage, the description should provide more context about inputs and outputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'code' with no description, and schema description coverage is 0%. The description does not explain what 'code' represents (e.g., company ticker or identifier), nor does it provide any guidance on valid values. The description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns company executives and board members, and identifies that the output includes 'leader_name' which can be used in get_executive_background. This distinguishes it from siblings by specifying the output and linking to another tool, but it could be more precise about the exact structure of the returned data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning that the returned leader_name is usable in get_executive_background, suggesting a workflow where this tool is a precursor. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden. It only states the tool is a calendar with optional filters, omitting behavioral details like data freshness, scope (past/future), rate limits, or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. The bilingual inclusion is unnecessary but does not harm conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with 3 optional params and no output schema, the description fails to explain return format, event types, or filter syntax. It does not address how to handle no filters or contrast with sibling calendars.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'market + date filter' for two of the three parameters but does not explain the 'max_count' parameter or provide format details for date/market values. Schema coverage is 0%, so the description adds some but insufficient meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is an economic-event calendar with optional filters, distinguishing it from sibling tools like earnings or dividend calendars. The verb 'get' and resource 'economic calendar' are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance is given. The description does not compare with alternative calendar tools or specify prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states what the tool does, without disclosing any behavioral traits such as read-only nature, authentication requirements, rate limits, or data freshness. For a data retrieval tool, this lack of transparency is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one line) and front-loaded with the tool name. However, it is under-informative; it could benefit from a brief explanation of what each view returns. The conciseness comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema, no annotations), the description is minimally complete. It states the purpose and the two views. However, it lacks details about the output data format, typical response structure, or any example, which would help the agent set expectations. It meets the baseline but does not excel.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% enum coverage for the single parameter, but schema description coverage is 0%. The description mentions the two views ('target_rate' and 'dot_plot') but does not explain their meanings or what data they retrieve. For example, 'target_rate' gives interest rate probabilities; 'dot_plot' provides FOMC dot plot projections. Without this context, the agent cannot infer the parameter semantics beyond the enum names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a CME FedWatch tool providing target rate probability or dot plot data. It specifies the two views, distinguishing it from sibling tools which are not FedWatch related. However, it could be more explicit about what exactly is returned (e.g., probabilities, dot plot points) and the verb (get) is implied rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It is implied that the tool should be used when FedWatch data is needed, but there is no mention of alternative tools or conditions for using a different tool. This is acceptable given no direct sibling competitor, but minimal guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, required permissions, or rate limits. It only states the basic function, leaving the agent uninformed about side effects or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using two short sentences including a Chinese translation and example. It is front-loaded with the main purpose. However, it could include slightly more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, no output schema, and no annotations, the description is too minimal. It fails to explain what the output looks like or provide sufficient context about the 'codes' parameter. For a simple info tool, it is barely adequate but lacks completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'codes' has no schema description (0% coverage). The description adds an example 'SG.CNmain', hinting that codes are futures contract codes, but does not explain the format, valid values, or how to specify multiple codes. This is insufficient for proper usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'futures contract info'. It specifies the type of info (size, last trade day, sessions) and provides an example code 'SG.CNmain'. This distinguishes it from sibling tools like get_stock_info or get_option_chain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention prerequisites, limitations, or when not to use. With many sibling tools, the agent lacks context to choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions request_type codes but does not explain whether the tool is read-only, requires specific permissions, or what the response contains. The default num=10 is implied but not explicitly stated as a limit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and compact, fitting in one line plus a note. The bilingual section may add redundancy but does not waste space. However, it could be more structured (e.g., separate param descriptions).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and few annotations, the description should provide more details on return format, error handling, or use cases. It only covers basic purpose and one parameter's range, leaving gaps for a tool with three parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains request_type (0=default, 1000=all) and hints that num controls the count. However, the required 'code' parameter is not explained, and 'num' semantics are not fully clarified. Some value added, but incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool provides top-10/detailed shareholders, with bilingual naming. It clearly indicates the resource (shareholders) and action (get details). However, it does not explicitly differentiate from sibling tools like get_shareholder_overview or get_institutional_holdings, which might overlap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No prerequisites or context for when it is appropriate. The description only gives request_type values but not usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It mentions views and markets filter but omits details on pagination (count parameter), data freshness, or what happens when markets is null. The count parameter's role is unexplained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence (with Chinese translation) that efficiently conveys core functionality and parameter usage. No fluff, but could benefit from slightly more structure for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no output schema, and no annotations, the description is insufficient. It fails to explain the count parameter's behavior, response format, or how markets filtering interacts with stocks view. The agent would struggle to use this tool correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain all parameters. It only covers 'view' and 'markets' partially, leaving 'plate_id' and 'count' undocumented. The enum values for view are implied but not explicitly listed, and markets format is vague.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves info or constituents for an industrial plate, using 'view' to switch between details and stocks. It distinguishes itself from siblings like get_plate_stocks by specifying 'industrial-plate', though it doesn't explicitly differentiate from similar plate tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on the two views and optional markets filter, but lacks explicit 'when-to-use' vs alternatives or when-not-to-use. Sibling tools exist for similar plate queries (e.g., get_plate_stocks), but no comparisons are made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description fails to disclose any behavioral traits such as read-only nature, rate limits, or pagination. The burden falls entirely on the description, which is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise at two lines, front-loaded with the purpose. Includes redundant Chinese translation but no wasted words overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with 2 params and no output schema, but the description only covers purpose and a parameter example. Missing details on return format, ordering, or pagination.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds meaning for plate_code via an example, but the limit parameter is entirely unexplained. Partial compensation for one parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool retrieves stocks in a plate or index, with examples of plate_code (e.g., hsi or HK.BK1910). Differentiates from sibling tools like get_plate_list which lists plates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives among many sibling tools. Only provides a parameter example, but no when-not or explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It mentions trends, percentiles, and market comparison but does not explain response structure, error handling, or side effects. The parameter value lists are helpful but insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two lines: a summary line and parameter details. The inclusion of Chinese translations may aid Chinese-speaking users but adds slight noise for others. Overall, it is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should elaborate on return values. It only describes input parameters and their codes, leaving the agent uninformed about the structure or content of the output. Essential details are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaning for valuation_type and interval_type by listing their numeric codes. However, the required parameter 'code' is not explained beyond its name in the schema, leaving its expected format or domain unspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Valuation detail (PE/PB/PS trend, percentile, vs market)' indicating the tool provides various valuation metrics. It lists specific valuation types and interval types with numeric codes, but does not explicitly differentiate from sibling tools like get_snapshot get_financial_statements, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_snapshot or get_financial_statements. The description only gives parameter value mappings without contextual usage recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states that the tool 'gets' a list, implying a read-only operation, but does not mention any required authentication, rate limits, or potential side effects. The lack of detail reduces transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences: the first states the purpose, and the second provides a parameter example. It is front-loaded and avoids unnecessary details, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description provides the core functionality and a parameter example. However, it lacks details about the output format, any filtering options, or the meaning of 'cbbc', leaving some ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single parameter, but the description provides an example ('e.g. HK.00700') that clarifies the expected format and value for stock_owner. This adds meaning beyond the basic type definition, but no further semantic details are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'warrants/cbbc list for an underlying', providing a specific example for the stock_owner parameter. It distinguishes from sibling tools like get_analyst_consensus and get_capital_flow, all of which are different data retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, such as get_option_chain or get_snapshot, which might also return underlying-related data. The description lacks any context for appropriate usage or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It fails to disclose what type of IPO list (upcoming, historical) or any behavioral traits like pagination, rate limits, or destruction. Only mentions market codes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short and front-loads the purpose. Every sentence adds value (purpose and market codes). Could be slightly more detailed but remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain what data is returned (e.g., company names, dates). It does not, leaving agent uncertain about the tool's output. Only covers input market codes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has one string parameter 'market' with no description or enum. Description adds meaning by listing allowed market codes (HK/US/SH/SZ/SG/MY/JP), significantly improving over the schema. Without this, agent would have no guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it gets an IPO list for a given market, with specific verb 'Get' and resource 'IPO list'. It lists possible market codes but does not explicitly differentiate from sibling tools like get_corporate_actions or get_earnings_calendar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives or when not to use it. The description only states what it does without context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but discloses minimal behavioral traits: only that it 'lists' expiry dates and is limited to certain asset types. No mention of output format, error handling, authentication, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is very concise (one sentence with Chinese translation), front-loaded with verb. However, it might be too brief, missing potentially useful details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity but no output schema and 0% schema coverage, description is incomplete. Does not explain return value format, whether dates are future-only, or any constraints beyond asset type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has single parameter 'underlying' with no description; description adds that it applies to HK/US stocks/ETF/index only. This gives partial meaning but does not specify format or allowed values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists option expiration dates, specifies verb 'List' and resource 'option expiration dates', and adds asset type constraints (HK/US stocks/ETF/index only). This effectively distinguishes it from siblings like get_option_chain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like get_option_chain or get_option_underlying. The description only provides asset type restrictions without context of workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and description only implies a read operation via 'Get'. Does not disclose side effects, authentication needs, rate limits, or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Front-loaded with main purpose, then adds constraints. Ideal length for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main fields returned and max codes, but lacks return format (though no output schema), error conditions, and prerequisites. Adequate for a low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds value with 'up to 400 codes' constraint beyond the schema. However, does not explain what the codes represent (e.g., stock tickers) or format expectations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Get stock basic+snapshot info' and lists specific fields (name, lot size, market cap, PE). Suffers slightly from lack of explicit differentiation from siblings like get_company_profile or get_snapshot, but the mention of underlying tool helps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs the many sibling tools. Only mentions a max of 400 codes and an underlying tool, but no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist to cover behavioral traits. The description does not mention authorization, rate limits, or what happens if no data is found. It lacks any behavioral context beyond the data type options.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences plus a bilingual label. It front-loads the purpose in English. The Chinese translation adds no value for an English-oriented AI but does not harm conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and no annotations, the description is insufficient. It omits details on num, holder_id, and return format, and does not clarify how results are structured or paginated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 4 parameters with 0% description coverage. The description explains data_type (holders/trades) and implies code is a US stock symbol, but num and holder_id are not described. This partially compensates but leaves significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves US insider holdings/trades (Form 4) and specifies US stocks only. It distinguishes from siblings like get_institutional_holdings by focusing on insiders and mentioning Form 4.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates US stocks only and defines data_type options, but provides no guidance on when to use this tool versus alternatives (e.g., get_holder_detail) or when it is not appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, permissions, rate limits, or behavior when no securities are found. It only describes the basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three lines, front-loading the purpose. The Chinese phrase adds a bit of redundancy but does not harm conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and 0% schema coverage, the description lacks completeness. It does not explain return values, parameter details, or usage context, which is inadequate for a tool with many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only adds minimal meaning for reference_type ('WARRANT / FUTURE / OPTION per SDK enum') without explaining code parameter usage or providing further semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get securities related to a code (spot↔warrant/future/option)' with a specific verb and resource, and distinguishes itself from siblings by focusing on reference securities linking spot to derivatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding reference securities but does not explicitly state when to use this tool over siblings like get_warrant, get_future_info, or get_option_chain. No exclusion or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description does not disclose behaviors such as data freshness, rate limits, authentication needs, or side effects. It only specifies that it returns revenue composition, which is insufficient for an agent to understand the tool's full behavioral profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences. The first sentence states the main purpose, and the second provides crucial parameter mapping. There is no fluff, and key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description should be richer. It does not mention return format, error handling, data limits, or whether the breakdown is for a single period or multiple. This leaves significant gaps for an agent using the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds meaning for financial_type (7=年报, 9=聚合季报). This maps the integer to financial report types, adding value beyond the schema. However, code and currency_code remain undocumented, so description only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves revenue composition by product, industry, region, or business. It provides the verb 'Get' and a specific resource 'revenue breakdown', and includes multilingual translations. This distinguishes it from sibling tools like get_company_profile or get_financial_statements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There is no mention of prerequisites, suitable contexts, or exclusions. The only contextual hint is the mapping for financial_type, but it does not help decide between this and other similar 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?
The description discloses that the tool returns short-selling data with two data types (volume/interest) and market coverage (HK/US). However, no annotations exist, and the description does not mention aspects like data freshness, read-only nature, or rate limits. The name implies read-only, but that is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and to the point, front-loading the core function ('Short-selling data') followed by specifics. It is efficient, though the inclusion of Chinese characters may add noise for some users.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of output schema and minimal parameter descriptions, the description should provide more context. It does not explain the meaning of the 'num' parameter or the format of 'code', leaving ambiguity for an AI agent. The market coverage is noted, but essential details are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds minimal parameter meaning. It explains the enum options (volume/interest) with examples but does not describe the 'code' or 'num' parameters (e.g., what 'num' represents). The description fails to compensate adequately for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool provides short-selling data (volume or interest) for HK and US markets, which distinguishes it from siblings like get_analyst_consensus, get_capital_flow, etc. The verb 'get' is implied, and the resource is well-specified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of scenarios where another tool might be more appropriate, nor any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool returns only top 10 brokers, is restricted to Hong Kong, and that days_before=0 means realtime data. However, with no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention whether the operation is read-only, if authentication is needed, or what the output format looks like. The disclosed behaviors are helpful but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two short lines that combine purpose and a parameter hint. It is front-loaded with the core functionality. However, it could be considered under-specified; while no words are wasted, the brevity sacrifices completeness. It earns a 4 for efficiency but not a 5 due to missing contextual details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema, no annotations), the description should provide enough context for agents to use it confidently. It fails to specify the output structure (e.g., broker names, IDs, buy/sell breakdown), how to interpret the ranking, or any limitations beyond 'HK only'. The description is incomplete for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must clarify parameters. It explains 'days_before: 0=realtime', adding meaning beyond the schema's default value. However, the required 'code' parameter is left completely unexplained—no hint that it is likely a stock code or broker identifier. The description adds partial value but fails to cover all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the top 10 buy/sell brokers, limited to Hong Kong ('HK only'). The addition of the Chinese translation reinforces the purpose. Although no explicit verb like 'get' or 'list' is used, the phrase 'Top-10 buy/sell brokers' unambiguously indicates a listing operation, distinguishing it from sibling tools that focus on other financial data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use or avoid this tool. The description does not mention alternatives, prerequisites, or scenarios where this tool is preferred over other broker-related tools like get_holding_changes or get_institutional_holdings. Agents must infer usage solely from the tool name and the breif description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does not disclose behavioral traits like read-only nature, required permissions, rate limits, or response structure. It only conveys parameter mappings, not tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, using bullet-like format for parameters. The bilingual content adds minimal redundancy but overall efficient. Could be shortened slightly by removing duplicate Chinese labels.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters and no output schema, the description fails to explain the return format, period count (num default), or code format. Essential context for a data-retrieval tool is missing, leaving the agent underinformed about output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description adds meaning for statement_type (enum mapping), financial_type (period mappings), and currency_code (ISO 4217 with native currency hint). It does not explain num or code, but code is standard and num is inferrable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves financial statements (income, balance sheet, cash flow, key indicators) with bilingual labels, making the verb+resource explicit and distinct from sibling tools like get_analyst_consensus or get_company_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings. It lacks explicit context for when to choose this over alternatives such as get_kline or get_earnings_calendar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It does not mention that this is a read-only operation, nor does it disclose any side effects, authentication needs, or limitations. Only lists parameters without behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with two sentences. However, it includes Chinese translations that may not be needed for English agents, slightly increasing cognitive load. Still efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no output schema, and no annotations, the description leaves gaps. It does not describe the return format (e.g., plate names, codes), pagination, or how many results to expect. Insufficient for fully informed usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It adds explicit values for 'market' (HK/US/SH/SZ/SG/MY/JP) and 'plate_type' (ALL/INDUSTRY/REGION/CONCEPT), but does not explain 'count' or 'keyword'. Partial improvement over schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs 'List plates' and states the resource type (concept/industry/region). It also lists supported markets and plate types, clearly distinguishing this tool from siblings that retrieve other financial data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by listing parameters and defaults, but does not explicitly state when to use this tool versus alternatives like 'get_industrial_plate' or 'get_owner_plate'. No exclusions or conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions the two views and their parameters but does not discuss data source, freshness, pagination, limits, error conditions, or authentication requirements. The behavioral context is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two brief sentences. It front-loads the key concept ('Macro indicators - 宏观指标') and then efficiently describes the two views. No redundant or extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and no annotations, the description is insufficiently complete. It lacks details on return values, error handling, data range constraints, and the meaning of 'available indicators'. The description only covers the views and parameter usage briefly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It clarifies that 'search' is for the list view, and 'begin'/'end' are for history, and that 'indicator_id' is used in history. However, it does not explain the format of dates, the nature of indicator_id, or whether search is a substring match. The description adds moderate value but is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves macro indicators with two distinct views: 'list' for available indicators (with optional search) and 'history' for time series data for a specific indicator (with optional begin/end). The verb is implied, but the resource and actions are unambiguous, distinguishing it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use each view (list vs history) based on the desired output, but does not explicitly state when not to use this tool or provide alternatives among the many sibling tools. No exclusion criteria or comparative guidance is 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?
No annotations exist, so description carries full burden. It reveals it is forward-looking and requires market/date, but omits return format, pagination behavior, and any safety/rate-limit info. Major gaps in behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise—two sentences. First sentence conveys main purpose, second adds key parameter usage and sibling distinction. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has 3 parameters, no output schema, no annotations. Description gives basic purpose and parameter hints but lacks output details, exhaustive market values, and full parameter coverage. Incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It adds meaning for 'market' (US/HK/...) and 'date' (YYYY-MM-DD format), but does not explain 'count' parameter. Partial coverage, some value but incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it is an all-market forward dividend/ex-date calendar, using specific verb 'get' and resource 'dividend calendar'. It distinguishes from sibling tool 'get_corporate_actions' by noting that is per-stock historical while this is market-wide forward.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly differentiates from get_corporate_actions, helping choose between them. Provides context for when to use: for forward dividend dates across markets. Could be improved by contrasting with other calendar tools like get_earnings_calendar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description does not disclose read-only nature, authentication needs, rate limits, or side effects. It only states purpose and precondition, missing crucial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste. The Chinese translation adds redundancy but is still efficient. Slightly front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema or annotations. Description does not describe the return data structure (e.g., list of positions, dates). For a background tool, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not explain what 'code' and 'leader_name' mean beyond implying 'leader_name' is from get_company_executives. No details on format or expected values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides background/career history of a named executive. It uses specific verb ('get') and resource ('executive background'), and distinguishes from sibling get_company_executives by mentioning the two-step process.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to first call get_company_executives to find leader_name, then call this tool. This provides clear when-to-use guidance and an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It fails to mention any side effects, permissions, rate limits, pagination, or output format. The description only explains view options and change_type, omitting critical 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph with mixed language (Chinese characters). It conveys key information but lacks structuring (e.g., bullet points) and could be more readable. Every sentence adds some value, but the format hinders quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters and no output schema, the description leaves significant gaps. It does not explain the return format, pagination behavior, or the interpretation of 'holdings' data. Required parameters like 'market' and 'institution_id' are undocumented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates partially by explaining 'view' (list/change) and 'change_type' (NEW/INCREASE/DECREASE/CLEAR). However, it fails to explain 'num', 'market', or 'institution_id', leaving required parameters undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves holdings by institution, distinguishing between 'list' and 'change' views, and explicitly differentiates from the sibling tool get_institutional_holdings. This provides a specific verb+resource with clear scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly contrasts with get_institutional_holdings, stating 'This is the BY-INSTITUTION direction... distinct from get_institutional_holdings (who holds a given stock).' This gives clear guidance on when to use this tool vs. the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully convey behavioral traits. It only mentions read operation implicitly and date constraints, but lacks details on side effects, authorization needs, rate limits, or response format. This is insufficient for an option chain tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using two sentences to convey purpose and constraints. It front-loads the action and avoids unnecessary words, making it efficient for agent processing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is the sole source of context. It does not explain what the returned option chain contains (e.g., strikes, calls/puts) or any pagination. Missing critical details for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains that start/end are date filters in YYYY-MM-DD format, adding meaning beyond the schema. However, the underlying parameter is not explained (e.g., expected ticker format), leaving a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get option chain for an underlying', specifying the action and resource. It distinguishes itself from sibling tools like get_option_expiration_date and get_option_quote by focusing on the full chain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description limits usage to 'HK/US stocks/ETF/index only', providing a clear context. It mentions optional date filtering via start/end, which guides proper invocation. However, it does not explicitly state when not to use this tool or suggest 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?
No annotations exist, so the description bears full responsibility. It mentions 'history' and 'who holds THIS stock', implying time-series data, but lacks specifics on data range, update frequency, or whether it shows current holdings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with one main sentence and a single line for alternative guidance. It is front-loaded but could benefit from a brief parameter explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of output schema and annotations, the description is minimal. It clarifies the tool’s distinction from a sibling but does not describe return format, time range, or pagination. Adequate for a simple tool but lacking detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%—no parameters are described in the schema properties. The description does not explain 'code' or 'num', leaving the agent to infer that 'code' is a stock identifier and 'num' possibly limits results. This is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns by-stock institutional holdings history, including Chinese terms and a reference to 13F filings. It explicitly distinguishes itself from the sibling tool get_institution_holdings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use this tool vs. the sibling tool: 'For by-institution (which stocks an institution holds) use get_institution_holdings.' However, it does not provide additional context like prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description should disclose more. It hints at a read operation (get) and mentions input constraints, but does not describe return values, side effects, or permissions. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Reasonably concise: two sentences with key info front-loaded. Includes some extraneous Chinese characters, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks explanation of the missing 'hv_time_period' parameter and what the output contains. For a tool with no output schema and no annotations, this leaves significant gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the 'code' parameter (option code) and 'query_time_period' (with mapping), but leaves 'hv_time_period' undefined. Partial coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it's for 'option volatility analysis (IV/HV) for a single option contract,' which is specific and distinct from sibling tools like get_option_chain or get_option_quote. The verb 'analyze' is implied, and the focus on volatility is 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to resolve an option code using resolve_option_code first, and explains the query_time_period mapping. Lacks explicit comparison with alternatives or when-not-to-use, but the prerequisite is valuable context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It describes the read-like operation (browse) and view modes, but does not mention side effects, authentication, rate limits, or pagination. The behavior is implied but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a single sentence with clear bullet-like formatting. It front-loads the main purpose and efficiently conveys all necessary view-specific instructions without any redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters and no output schema, the description provides a reasonable overview of input requirements and view outcomes. However, it lacks details on the return data structure, pagination behavior, or default values (e.g., count=20), which are important for the agent to fully understand the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description effectively explains the purpose of 5 out of 6 parameters (view, market, keyword, chain_id, plate_id) within the context of different views. Only the 'count' parameter is not explained. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool browses industrial/supply chains and explicitly lists three distinct views (list, detail, by_plate) with their specific purposes. It differentiates from sibling tools like get_industrial_plate by focusing on chains rather than plates, aiding correct selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage guidelines, e.g., 'market needed for list' and which ID to pass for each view. However, it does not specify when to avoid this tool or mention alternative tools for similar tasks, leaving the agent without full decision-making 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?
The description provides important behavioral info about raw scaling (e.g., PRICE 10.0, MARKET_CAP 1e10) and references an external schema for config_json. However, it does not disclose output format, side effects, auth needs, or rate limits. Since no annotations are provided, the description carries the full burden but falls short.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two lines plus parenthetical clarifications. Every sentence adds value, front-loading the purpose and then detailing key parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters, no output schema, and no annotations, the description covers market and config_json but omits page_count and does not describe the output format or return behavior. It is minimally complete but could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema for 'market' (listing supported values) and 'config_json' (explaining it is a JSON string with filters/retrieves/sort and raw scaling). However, 'page_count' is not mentioned, and the config_json reference to external schema leaves some vagueness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool screens stocks by multi-factor config (V2), with verb 'Screen' and resource 'stocks'. It distinguishes from sibling tools, which are all 'get_' tools for specific data, making this the only screening tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the tool is unique among siblings (no other screening tools), the description does not explicitly state when to use it or provide alternatives. It implies usage for multi-factor screening but lacks explicit guidance on when to prefer it over other 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?
Discloses rate limit (10/30s) and return fields (market/code/name/sec_type). No annotations are present, but the description covers key behavioral traits. Lacks detail on error handling or pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes redundant Chinese text. It is front-loaded with English purpose, but the inclusion of both languages and the rate-limit note could be more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Provides enough context for a search tool: keyword search, return fields, rate limit, and a usage hint. Missing details about max_count functionality and result format, but adequate for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 'keyword' as the search term but does not explain 'max_count' or its default value (10). The return fields hint at what keyword searches for, but max_count receives no clarification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches securities/ETFs/plates by keyword, returns specific fields (market, code, name, sec_type), and advises calling this first if unsure of a stock code. This distinguishes it from sibling tools that likely require exact codes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends calling this first if unsure of a stock code, providing clear usage context. Also mentions rate limit (10/30s). Does not explicitly list when not to use it, but the sibling context implies alternatives for specific data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. Discloses listing behavior, fuzzy search, and output id. However, it does not mention ordering, pagination, limitations on count, or error handling for invalid market names.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences, front-loaded with main purpose. No wasted words. Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 3 params, description covers listing purpose, optional search, and output usage. Lacks details on output structure (fields beyond institution_id) and behavior with large count. Almost complete but could be more explicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%; description explains 'name' (fuzzy search) and 'market' (implicitly), but 'count' parameter (default 20) is not described. Example helps with name. Partially compensates but misses count semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists institutions in a market, with optional fuzzy name search, and returns institution_id usable in other tools. It distinguishes from sibling tools that cover holdings, distribution, profile, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides usage context: optional name fuzzy search with example, and that returned institution_id is for other institution tools. Lacks explicit when-not-to-use or alternatives, but the intended use 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?
No annotations provided, so description must carry full burden. It discloses data scope (IV/HV, PCR) and constrains begin/end to ≤364 days, but lacks details on rate limits, authentication, or side effects. The return types (time series vs snapshot) are implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise with two sentences, but the first sentence is a list-like phrase that mixes English and Chinese, slightly reducing clarity. It front-loads the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately covers parameter usage and date constraints. However, it does not describe the output format or fields returned, leaving some ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description adds significant meaning: explains the 'view' enum values and their associated parameter usage (list for overview, single + dates for others). However, it does not specify the date format or that 'code' can be a string or array.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides option underlying IV/HV data, with three specific views (volatility, statistic, overview). It distinguishes itself from sibling tools like get_option_chain and get_option_volatility by focusing on underlying metrics and offering batch snapshots.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: for overview pass a list of codes, for volatility/statistic pass a single code with begin/end (≤364 days). However, no exclusions or alternative sibling tools are mentioned.
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?
With no annotations, the description carries the full burden. It discloses return fields (title, source, publish_time, related_securities, url) and a rate limit of 10 requests per 30 seconds. No contradictory claims exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences front-load the purpose, then detail subtype and output/rate limit. Every sentence adds value; no redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description covers purpose, parameters (partially), return fields, and rate limits. Missing details on pagination or ordering but sufficient for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies the 'news_sub_type' parameter with options ALL/NEWS/NOTICE/RATING. However, 'keyword' and 'max_count' lack additional context beyond their names and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches news/announcements/ratings by keyword, with Chinese translation for multilingual support. It distinguishes from siblings like get_analyst_consensus or get_earnings_calendar, which retrieve specific data types rather than performing a keyword search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates usage for news-related searches but does not provide explicit when-to-use or when-not-to-use guidance. Alternatives among siblings are not mentioned, leaving the agent to infer context from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses the tool's read-only nature (historical data), the types of K-lines, rehab options, and a version limitation. Missing details include potential rate limits, response format, and error handling. No contradiction with annotations (none exist).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it starts with the purpose, then lists parameter constraints and usage patterns. Every sentence adds value, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and no annotations, the description provides a good overview but lacks details on return format, error handling, and edge cases. The limitation about US intraday is noted, but additional context like pagination or data source would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description adds significant meaning by explicitly listing valid values for ktype and rehab, and explaining the use of start, end, and num. It covers almost all parameters except 'code', which is self-explanatory. This compensates well for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get K-line / candlestick / historical price'. It lists supported ktype values, rehab options, and the two modes of operation (range vs latest bars). This distinguishes it from sibling tools like get_snapshot or other historical 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use start+end vs num, and notes a limitation ('US intraday session not exposed in v1'). However, it does not explicitly state when not to use this tool or mention alternative tools 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?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions the analysis includes bid/ask, P&L, max profit/loss, and breakeven, but does not disclose data freshness, performance characteristics, or any side effects. For a read-only analysis tool, this is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a parenthetical Chinese translation. The most important guidance (preferred source, not summing) is front-loaded. Every sentence adds value without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter and no output schema, the description covers the key aspects: what it does, how to structure the input, and how it differs from alternative approaches. It lacks details on return format or edge cases, but overall it is complete enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only a generic array type for 'legs' with no description (0% coverage). The description adds the crucial structure: {code, action: BUY|SELL, quantity}. This significantly enhances understanding beyond the schema, though it does not specify format constraints beyond the action enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs combo option bid/ask and P&L analysis, including specific outputs like max profit/loss and breakeven. The Chinese translation reinforces the purpose. It differentiates from summing single-leg snapshots by explicitly advising against that method.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'PREFERRED source for combo bid/ask; do NOT sum single-leg snapshots', giving clear when-to-use guidance and a contraindication. It could be improved by naming a specific alternative tool, but the contrast with 'summing snapshots' 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?
No annotations are provided, so the description must bear the full burden. It states 'no subscription needed' (a behavioral note) and lists the data fields returned. However, it does not mention rate limits, data freshness, or other behavioral traits, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient paragraph with no wasted words. It front-loads the core purpose, then provides usage guidance and parameter details, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (one parameter, no output schema), the description covers purpose, usage triggers, parameter format, and constraints. It is sufficiently complete for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only one parameter 'codes' with no description. The description adds value by giving example formats (US.AAPL, HK.00700, SH.600519) and a usage limit (up to 400 codes), which goes beyond the schema's bare type definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool retrieves a market snapshot with specific data (latest price, OHLC, volume, bid/ask) for one or more stocks. The verb 'Get' and resource 'market snapshot' are clear, and the mention of 'no subscription needed' distinguishes it from siblings that might require subscriptions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage triggers: 'Use when the user asks for 报价/价格/行情/快照/quote/price/snapshot.' It also gives code format examples and a limit of 400 codes per call. It lacks explicit exclusions or alternatives but is sufficient for guidance.
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?
With no annotations, the description carries the full burden. It states the tool returns historical records per stock, implying a read-only operation. It does not mention authentication, rate limits, or response format, but the behavior is sufficiently clear for a simple retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, and includes helpful bilingual terms (Chinese translations). Every word earns its place; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has two simple parameters, no output schema, and no annotations. The description adequately explains the tool's scope and distinguishes from a sibling, but could be more complete by mentioning the output format (e.g., list of events). Still, it meets the needs for a straightforward retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains the 'action_type' enum values (dividends, buybacks, splits) and hints that 'code' is a stock identifier, but does not define 'code' explicitly. This adds some value but leaves one parameter undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'corporate actions', lists the three types (dividends, buybacks, splits), and distinguishes from sibling tool get_dividend_calendar, which covers forward all-market dividends.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly directs the agent to use get_dividend_calendar for a forward all-market dividend calendar versus this tool for per-stock historical records, providing clear when-to-use 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?
No annotations are provided, so the description must convey behavior. It states the tool retrieves snapshot/Greeks, implying read-only, but does not explicitly confirm read-only nature, mention rate limits, authentication needs, or data freshness. It adds the legs format but lacks deeper 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using two sentences to convey purpose, parameter format, and exclusion. It is front-loaded with the main action and efficiently covers key points without extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one complex parameter and no output schema or annotations. The description adequately explains the input format and usage boundaries, but it does not describe the return structure or constraints on legs (e.g., max quantity). Given the complexity, more detail on output would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema for 'legs' is minimal (array of objects with additionalProperties true) and has 0% description coverage. The description compensates by specifying the exact structure: {code, action: BUY|SELL, quantity}, providing crucial meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get option snapshot/Greeks for one or more legs.' It specifies the resource (option snapshot/Greeks) and the action (Get), and distinguishes from the sibling tool 'get_option_strategy_analysis' for combo bid/ask. The Chinese translation reinforces purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when NOT to use this tool ('NOT for combo bid/ask') and provides an alternative ('use get_option_strategy_analysis'), offering clear usage guidance. This helps an AI agent avoid misapplication.
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?
Although annotations are absent, the description discloses that it aggregates multiple data sources (user info, quota, state) and explicitly calls it a diagnostic. It does not mention potential side effects, but for a read-only, no-parameter tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with key information front-loaded (Self-diagnostics). The inclusion of Chinese text may be redundant for English agents but does not harm conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description covers the purpose, usage, and aggregated data. It could mention authentication requirements but it's implied by 'user info'. Overall complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so schema coverage is 100% trivially. The description does not need to add parameter details and the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Self-diagnostics' and lists the aggregated data types: user info, history-K-line quota, global state. It distinguishes from sibling data retrieval tools by being a diagnostic tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs when to use: 'Call when a data tool returns a permission/quota error to diagnose the cause.' This is a clear usage scenario.
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?
Discloses return format (code example) and notes different abbreviation for HK options. No annotations, so description carries burden. No mention of errors or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with purpose. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers inputs, output format, and special case for HK codes. With no output schema, explanation of return value is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description provides examples for each parameter (underlying, expiry, strike, option_type), adding meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'resolve' and resource 'option code'. Differentiates from hand-building codes, especially HK. Specific examples of inputs and output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly warns against hand-building HK codes, indicating when to use this tool. Implicitly for generating correct codes. 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.

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:

[![futu-opend-mcp MCP server](https://glama.ai/mcp/servers/xyonium/futu-opend-mcp/badges/card.svg)](https://glama.ai/mcp/servers/xyonium/futu-opend-mcp)

Score Badge

Copy to your README.md:

[![futu-opend-mcp MCP server](https://glama.ai/mcp/servers/xyonium/futu-opend-mcp/badges/score.svg)](https://glama.ai/mcp/servers/xyonium/futu-opend-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/xyonium/futu-opend-mcp'

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