Server Quality Checklist

Tool Scores

• main_fund_rankB
  3.1/5.0
  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 data freshness, return format, pagination, or access restrictions, leaving the agent with limited operational context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is brief and front-loaded with the core purpose, though the bilingual repetition adds minor redundancy. 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?

  With no output schema and minimal annotations, the description lacks details on output structure, sorting, or pagination, leaving the tool's behavior incompletely specified.

  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 to the 'market' parameter by listing allowed values. However, it does not mention the 'limit' parameter, so partial compensation.

  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 returns a ranking of stocks by main capital net inflow and lists market filter options, distinguishing it from sibling tools like get_kline and sector_fund_flow.

  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 mentions the ranking purpose but provides no explicit guidance on when to use this tool versus alternatives like sector_fund_flow, nor does it state prerequisites or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_klineB
  3.3/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description must bear the burden of disclosing behavioral traits. It mentions historical data but fails to describe rate limits, data freshness, error handling, or any limitations. The description adds little beyond the basic purpose.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise with only two sentences covering both languages. It is front-loaded with the core purpose. However, it could be more structured (e.g., listing use cases or parameter hints) to improve scanability.

  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 and no annotations, the description covers the tool's purpose and periods but lacks important details like return format (e.g., OHLCV fields) and whether data is adjusted. This is a moderate gap for a historical data tool that an AI agent needs to effectively 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 coverage is low (33%: only code has a description). The description repeats the period enum values already in the schema but does not explain the meaning of limit (e.g., number of trading days or bars) or provide examples. It adds no new semantic information beyond what the schema already conveys.

  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 historical K-line data for individual stocks, specifying supported periods (daily, weekly, monthly, intraday) and listing use cases like trend analysis and backtesting. It is distinct from sibling tools such as get_stock_quote or main_fund_rank, which serve different purposes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for technical analysis and backtesting but does not explicitly state when to use this tool versus alternatives (e.g., get_stock_quote for real-time quotes). No exclusions or complementary tools are mentioned, leaving guidance minimal.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• search_stockA
  3.5/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, and the description only states the search functionality without disclosing behavioral traits such as result format, pagination, or behavior on no match. It does not contradict annotations (none present).

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is very concise—two short sentences including a bilingual explanation and an example. Every word is relevant and contributes to clarity without redundancy.

  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 an output schema, the description could be more complete by indicating what the tool returns (e.g., a list of matching stocks). It adequately covers input semantics but leaves the output unspecified.

  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 50% (only 'keyword' has a description). The description adds value by explaining what types of keywords are accepted (name/code/pinyin) and giving examples, but it does not clarify the 'limit' parameter's purpose or its default behavior.

  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 searches A-share stocks by name, code, or pinyin, with an example. It is distinct from sibling tools like get_kline or get_stock_quote, which focus on retrieving specific data rather than searching.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool should be used to find stocks when given a keyword, but does not provide explicit guidance on when to use it versus alternatives, nor does it mention any prerequisites or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_stock_quoteA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations provided. Description mentions data source (东方财富) and 15-minute delay, which adds some behavioral context. No further details on auth, rate limits, or side effects.

  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 concise sentences, bilingual, front-loaded with key information. No wasted 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 one parameter, no output schema, and no annotations, the description adequately covers purpose, data fields, data source, and delay. Could be slightly more detailed on return format, but sufficient for a simple 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 100% for the single parameter. The description does not add new information beyond what the schema already provides (code and example). Baseline score 3 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 it gets real-time quote for A-share stocks, listing specific fields (price, change%, volume, turnover rate, P/E). It distinguishes from siblings like get_kline (k-line data) and search_stock (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?

  No explicit guidance on when to use this tool vs alternatives. Usage is implied (fetch current quote), but no exclusions 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.

• sector_fund_flowA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the full burden. It discloses what the tool returns (涨跌幅、主力净流入、领涨股), but does not mention side effects, rate limits, or other behavioral traits. It is adequate but not rich.

  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 very concise: two sentences conveying purpose, kind options, and return fields. No unnecessary words; front-loaded with both languages.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with 2 parameters and no output schema, the description covers the main purpose and key return fields. It could mention the order of ranking or data format, but it is reasonably complete for its complexity.

  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%, so the description must compensate. It explains the 'kind' parameter with Chinese/English context and the two enum values, adding value beyond the schema. However, it does not discuss the 'limit' parameter, so it is not fully compensatory.

  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 for sector fund flow ranking, specifies the two kinds (industry/concept), and lists the returned fields (change percentage, main net inflow, leading stock). This distinguishes it from siblings like get_kline or main_fund_rank which are for individual stocks or different rankings.

  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 it is for sector-level flow ranking, but does not explicitly state when to use this tool versus similar tools like main_fund_rank. No when-not-to-use 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.