[v1.6.0] L-179 原子：一个技术方向。传 dir_id 或方向名。返回阶段、所属品类、线索。新闻线索 90 天，论文 24 个月。非壁垒最多 2 条且不给来源 URL；壁垒月卡给全量线索和 URL。只返回 JSON。Atomic tech direction by dir_id or name. News 90 days, papers 24 months. Non-pro: max 2 clues, no source URL. Pro: full clues with URLs. JSON only.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | 方向中文名，如 机器人世界模型 | |
| dir_id | No | Direction id, e.g. robot_world_model |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description has to cover the safety profile, and it provides unusually strong behavioral detail: data freshness windows (news 90 days, papers 24 months), Pro vs non-Pro result caps, omission of source URLs for non-Pro, and a JSON-only return. It does not specify how authentication or subscription tier is determined, so one gap remains.
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 content is dense and front-loaded, but it is stated twice: the Chinese block and the English block repeat identical facts. The version tag "[v1.6.0]", internal code "L-179", and "原子" are noise that does not help an agent decide or invoke.
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 tool has no output schema and no annotations, so the description carries the full burden, and it delivers: it names the returned fields (stage, category, clues), the vintage of the data, the tier-dependent truncation, and the return format. Only edge-case behavior for invalid or conflicting identifiers is missing.
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% (both name and dir_id documented with examples), so the baseline is 3. The phrase "传 dir_id 或方向名" does add modest value by implying either identifier alone is sufficient, but the schema marks no parameter as required, and the description does not resolve what happens if both are supplied or neither is supplied.
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 tool is described as "原子：一个技术方向" (an atomic tech direction) looked up by dir_id or name, and it states what it returns: stage, category, and clues. The scope is clear, but the description never distinguishes this tool from similar ones like intel_category or intel_tech_daily.
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 only says "传 dir_id 或方向名" (pass dir_id or name), which is a parameter hint rather than guidance on when to use the tool. It gives no context, no "not for" exclusions, and no alternatives; tier rules (max 2 clues for non-Pro) only imply differentiated use and are not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.