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 does disclose that these are real-time quotes (data freshness) and what happens when codes is omitted, which is meaningful behavioral context. It says nothing about auth, rate limits, delay, or response shape, so it is adequate but incomplete for a no-annotation tool.

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

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

The purpose is front-loaded in one line, followed by a compact Args block. Every sentence carries information, though the repeated index list (once in the purpose, once in the default description) is slightly redundant.

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

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

With only one optional parameter, an output schema present (so return values need no explanation), and no annotations, the description covers what the agent needs to call it correctly. The remaining gap is the lack of any note on data freshness guarantees or error behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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, and it largely does: it marks codes as optional, specifies comma-separated syntax with a concrete example ('sh000001,sz399001'), and defines the default set when blank. It stops short of explaining the code format rules in full, hence not a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb (获取/get) and resource (A 股大盘指数实时行情) and enumerates the concrete indices returned (上证指数、深证成指、创业板指、沪深300). The resource type is clearly distinct from the sibling stock tools (get_stock_quote, search_stock, etc.), so an agent can tell it apart without opening the schema.

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

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

Usage is implied by the resource type: fetch market-index quotes. The description also clarifies the default behavior when codes is empty, which is helpful context. However, it never explicitly states when to prefer this over the sibling stock-quote tools or any conditions/exclusions, leaving the routing to inference.

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

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

With no annotations, the description carries the full burden. The verb 获取 implies a read-only retrieval, and the return list adds output context, but it does not explicitly state read-only behavior, permissions, or rate limits. For a simple data getter this is adequate but not richly transparent.

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

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

The description is front-loaded with purpose, then lists returns, then documents the argument. It is short and well structured. The return list is somewhat redundant because an output schema exists, but it is not verbose or wasteful.

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

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

For a single-parameter read-only tool with an output schema, the description covers the purpose, output metrics, and the sole parameter. The main missing piece is usage guidance relative to siblings, but the output schema and implied read-only nature make it largely complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 documents the single symbol parameter as a stock code with an example ('600519'), which is enough to invoke the tool correctly. It could specify format constraints (e.g., 6-digit A-share code) but the example is sufficient.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (获取) and resource (单只 A 股的估值与基本面指标), and lists the returned metrics. It distinguishes from siblings only implicitly by focusing on fundamentals rather than quotes or history; no explicit sibling differentiation is given.

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

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 provided. It does not name alternatives such as get_stock_quote or get_stock_history, nor does it explain when this tool is preferable. Usage context is only implied by the purpose statement.

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

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

With no annotations, the description carries the full burden, and it does disclose one real behavioral trait: the data is forward-adjusted (前复权), which materially affects returned prices. However, it never states that this is a read-only call, nor any limits, error behavior, or market-coverage caveats.

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

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

Front-loaded one-line purpose followed by a tight Args list; effortless to scan. The Args entries restate schema defaults (30, 'daily'), which is mildly redundant but reinforces the parameter contract at negligible cost.

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

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

Output schema exists, so return fields need not be described, and all three parameters are fully specified. The only gap is the absence of any statement about read-only safety or data-source coverage, which matters somewhat given zero annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the Args block is doing all the work — and it succeeds. Symbol example ('600519'), period enum with defaults and meanings (daily/weekly/monthly), and count default of 30 with a maximum of 320 are all documented, which the bare schema does not convey.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: '获取单只 A 股的历史 K 线数据（前复权）' — retrieve historical K-line data for ONE A-share, forward-adjusted. The '单只' (single stock) scoping implicitly distinguishes it from the plural sibling get_stock_quotes, but no sibling is named explicitly.

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

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

Usage is implied by the wording: use it when you need OHLC history for one ticker rather than a quote or fundamentals. No explicit when-to-use, prerequisites, or routing to alternatives (e.g. get_stock_quote for the current price) is given.

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

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

With no annotations, the description carries the burden, and it does disclose real behavioral detail: default source ordering and automatic fallback on failure. It omits any statement about read-only nature, market-hours behavior, latency, or failure modes, so coverage is partial rather than rich.

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

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

Front-loads the core purpose in one sentence, then source behavior, then a compact Args block. Every line earns its place, though the Args formatting is slightly boilerplate for only two parameters.

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

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

An output schema exists, so return values need not be described. Between the purpose sentence and the two documented parameters, an agent has what it needs to call the tool correctly; only edge-case behavior (invalid codes, market closed) is unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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, and it does: symbol is documented with concrete code examples (600519, 000001) and source is documented with its allowed values (auto/sina/tencent) and default, information absent from the schema's bare string properties. It stops short of specifying code format constraints (exchange prefixes, length).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("获取单只 A 股股票的实时行情") and the scope word "单只" (single) implicitly separates it from the plural sibling get_stock_quotes. An agent can distinguish this from get_stock_quotes/get_stock_history without opening either schema.

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

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

The description explains source-selection behavior (auto default, sina-first with tencent fallback, or force via source), which is useful operational guidance. However, it never says when to prefer this tool over siblings like get_stock_quotes or get_stock_history, so usage is only implied.

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

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

No annotations are provided, so the description carries the full burden, and it does disclose one real behavioral trait: the 10-symbol cap and the real-time (vs historical) nature of the data. It says nothing about auth requirements, rate limits, behavior on invalid/delisted codes, or partial-failure handling, which are the questions an agent would ask before batching.

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

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

One front-loaded sentence carries the purpose and the cap, and the Args block adds only the format detail that isn't in the schema. No filler or repetition; the structure is standard and easy to parse.

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

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

With an output schema present, return values need not be explained, and the single parameter is fully described. The only real gap is operational behavior (auth, invalid-symbol handling) for a tool with no annotations — minor for a straightforward read call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the single 'symbols' parameter has no schema description, so the description must compensate — and it does, specifying comma-separated codes, a concrete example ('600519,000001,000858'), and that both Chinese and English commas are accepted. That is meaningfully more than the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (批量获取) and resource (A 股股票的实时行情) with a hard scope limit (最多 10 只). The plural/批量 framing implicitly separates it from the singular sibling get_stock_quote and from get_stock_history, but it never names those siblings explicitly, so the differentiation is left to inference.

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

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

Usage is only implied: the batch wording and the 10-symbol cap suggest this is the tool for multiple symbols at once, and the sibling get_stock_quote covers the single-symbol case. There is no explicit when-to-use, when-not-to-use, or alternative-routing statement.

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

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

With no annotations, the description carries the full burden and does reasonably well: it discloses that data is local, that coverage is limited to log-writing instances, and how the log path is configured. It does not state what happens when no log exists (empty result vs. error), which is the main remaining gap.

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

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

Front-loaded purpose statement, then return contents, then the coverage caveat, then the argument block. No sentence is redundant and nothing important is buried.

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

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

An output schema exists, so return shape need not be described, yet the description still outlines the aggregates returned (totals, errors, per-tool, per-day). Combined with the log-coverage caveat and parameter bounds, it is nearly complete; only the no-log-file edge case is unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 documents 'days' with its default (7) and a new bound not present in the schema (max 365). This adds real meaning beyond the bare integer property.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: retrieving tool-call usage statistics for this MCP server from local records. It is clearly distinguishable from the sibling stock-data tools (get_stock_quote, search_stock, etc.), which retrieve market data rather than server telemetry.

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

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

Explains the operative condition for the tool being useful: statistics only cover instances that have written a log file, and the log path is configurable via STOCK_MCP_USAGE_LOG. It doesn't name alternatives, but none are needed given the unique purpose.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses fuzzy matching across name, code, and pinyin initials, plus accepted keyword formats, but does not state safety traits such as read-only behavior, rate limits, or result-size constraints.

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

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

The description is short and front-loaded, leading with the core search action before listing keyword semantics. The Args note adds needed parameter detail rather than repeating schema fields, so every sentence earns its place.

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

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

With one required parameter, an output schema, and no annotations, the description supplies enough to invoke the tool correctly and interpret the keyword argument. It could be stronger by connecting this discovery tool to sibling retrieval calls, but the invocation context is otherwise complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description fully compensates: it defines keyword as the search term and gives concrete examples ('茅台', '600519', 'PAYH'), including an explanation of pinyin-initial matching. This adds substantial meaning beyond the bare string schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: '按关键字搜索 A 股股票' (search A-share stocks by keyword). It also clarifies the search scope with fuzzy matching by name, code, and pinyin initials, which clearly separates it from retrieval siblings like get_stock_quote and get_stock_history.

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

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

The description explains what the tool does but gives no explicit guidance on when to use it versus siblings such as get_stock_quote or get_stock_fundamentals. No when-not conditions or alternatives are mentioned, leaving usage context to inference.

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