cn-intel-mcp

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

No annotations are provided, so the description carries the disclosure burden. It usefully characterizes the return type (signals + 信息差依据 / judgment layer, not raw data), which is genuinely helpful. But it omits auth needs, rate limits, latency, and whether answers are cached or time-sensitive—significant gaps for a tool calling an external inference layer with zero annotation coverage.

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

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

Two tight clauses, front-loaded with the core purpose and immediately followed by the differentiator. No filler, 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?

The description is adequate for a 2-param Q&A tool: it explains the answer shape and the distinction from data APIs. However, with no output schema and no annotations, an agent gets no information about response structure beyond a phrase, no error modes, and no guidance on question phrasing despite the schema's examples. Minimum-viable rather than 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 100%, so the schema already documents both parameters (question with examples, limit default 5). The description does not add syntax, format constraints, or meaning beyond what the schema provides, so the baseline of 3 applies.

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?

Names a specific verb+resource (natural-language question answering over industry questions) and adds an explicit differentiator: unlike the data APIs, it returns the judgment layer ('what it means') rather than raw data. This directly separates it from siblings like read_signal_board and read_article, which an agent can distinguish without opening any 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 '区别于数据 API' clause tells the agent when this tool is the right choice—interpretive questions rather than raw data retrieval. No explicit when-not or alternative routing to a named sibling is given (e.g., no 'for raw signals use read_signal_board'), so it falls short of a 5 but the usage context is clear.

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. It implies a read-only operation via '读取' and describes the data returned (hit rate, verification stats, per-signal range), but omits permissions, side effects, rate limits, and 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.

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

Two sentences, front-loaded with the core purpose. The second sentence about being the only time-accumulated asset is somewhat editorial but earns its place by underscoring the data's provenance and value.

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 no output schema, the description usefully outlines the return content (hit rate, validation stats, per-signal results). The input schema fully covers parameters, but the absence of usage guidance leaves a small completeness gap.

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 100%, so the schema already documents both parameters (industry filter, include_signals default). The description adds no additional parameter meaning or examples, matching the baseline 3 when schema does the heavy lifting.

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 (信号验证记录) and enumerates what it returns: hit rate, verified/pending stats, per-signal results. It clearly distinguishes itself as a historical performance record, but does not explicitly differentiate from siblings like read_signal_board or read_earnings_tracker.

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, when-not-to-use, or alternative guidance is provided. The sentence '这是唯一用时间积累的资产' is a value proposition rather than usage direction, leaving an agent to infer when this tool is preferable to its siblings.

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?

未提供 annotations，描述需承担行为说明责任。它补充了返回字段（标题/主题/链接）和内容用途，但未说明鉴权、分页、排序或速率限制等行为特征。

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?

单句直述，先说明列出什么、再说明返回内容与用途，信息前置且无冗余。

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?

对于仅 2 个参数、无输出 schema 的只读列表工具，描述已说明返回字段和发现文章的用途。虽未提及分页等行为，但 limit 参数已在 schema 中覆盖，整体足够调用。

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 覆盖率 100%，limit 和 topic 均已有描述，基线为 3。描述本身未对这两个参数补充额外语义或格式说明。

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?

明确给出了动词“列出”和资源“中国硬科技供应链研究文章清单”，并说明返回标题/主题/链接。与同级工具 read_article 形成列表与详读的隐含区分，但未直接点明同级工具。

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?

通过“供 Agent 发现可引用的深度内容”给出了使用场景，但未说明何时应改用 read_article 等替代工具，也没有排除条件。属于隐含用法指引。

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. It usefully discloses that the content is Chinese and is first-hand industry investigation notes from an 'information gap' perspective, which helps interpretation, but it omits behavioral traits such as return size, truncation, or behavior on a missing/ambiguous title.

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?

Two compact sentences with the purpose front-loaded and no padding. The second sentence about content nature earns its place as interpretation context, though slightly ornamental.

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 tool with no output schema and no annotations, the description covers the essentials (what is read, in what language, from what kind of source). It stops short of noting return shape or failure behavior, leaving minor gaps that a reader tool could reasonably fill.

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 100%, so the schema already documents the title parameter fully, including fuzzy matching and the list_articles lookup hint. The description adds no parameter-level syntax or format detail beyond that, making the baseline 3 appropriate.

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 (读取/read) and resource (研究文章全文/full text of a research article), and the '全文' scope distinguishes it from list_articles, which only surfaces titles. It is clear enough that an agent would not confuse it with the sibling listing tool, though it does not name siblings 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?

It gives an implied usage context ('供 Agent 引用分析' – for agent citation/analysis) and the schema hints that list_articles is the way to find titles, but there is no explicit when-to-use/when-not guidance or routing to alternatives among ask_edge, read_signal_board, etc. Usage must be inferred.

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 behavioral burden. '读取' implies a read-only operation and the content of the table is described, but there is nothing about permissions, whether all rows are returned, pagination, or result ordering. For an unannotated tool this leaves significant disclosure gaps.

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?

A single, front-loaded sentence that wastes no words and puts the resource first. It is efficient, though the parenthetical list of status values duplicates the schema's enum-free documentation.

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 two-optional-parameter read tool with full schema coverage and no output schema, the description conveys what data is returned, which is the key missing piece. However, it offers no return-format or filtering behavior guidance, leaving it only minimally 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 100%, and both filters (status, industry) are already fully documented in the schema with example values. The description adds no filter syntax or semantics beyond what the schema provides, so the baseline 3 applies.

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 names a specific resource (中报信号验证追踪表) and enumerates the three dimensions of data it holds: signal-board predictions, actual disclosed results, and verification status. An agent understands the content, but it does not differentiate itself from the sibling read_signal_board, which the description even references ('信号板预测的公司').

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?

There is no statement of when to use this tool versus alternatives such as read_signal_board or get_track_record, and no prerequisites or exclusions. Usage must be inferred entirely from the resource name.

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 burden. It clarifies that the return is structured JSON with verification-record fields (predicted_on/verify_by/verify_event/result), which is useful, but says nothing about permissions, data freshness, volume, or failure behavior for what is presumably a read.

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 and compact, with purpose and return shape in the first clause. The emoji and field enumeration add mild noise but every clause carries information.

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?

There is no output schema, and the description compensates by naming the exact fields returned by each signal, which is the most important missing structured information. Filtering behavior is left to the schema, so little is absent.

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 100%, so limit, result, and industry are already documented with examples and filtering semantics. The description adds no parameter detail beyond the schema, which is the expected baseline here.

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 ('读取信号信息差看板') and describes the returned content, including the high-information-gap signal focus. It is distinguishable from siblings like get_track_record or read_earnings_tracker, though it does not explicitly name the distinction.

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 never says when to choose this tool over alternatives such as ask_edge or get_track_record, nor does it state any preconditions. Usage must be inferred entirely from the name.

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