future_signals
聚合高质量科技/AI/商业/营销信源的最新文章(未来趋势信号素材),可按分类或关键词过滤。趋势判断由调用方大模型完成。
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| keyword | No | 按关键词过滤标题/摘要 | |
| category | No | 信源分类;industry=品牌/商业/广告/媒体组合,可用 list_categories 查看;all=全部 |
聚合高质量科技/AI/商业/营销信源的最新文章(未来趋势信号素材),可按分类或关键词过滤。趋势判断由调用方大模型完成。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| keyword | No | 按关键词过滤标题/摘要 | |
| category | No | 信源分类;industry=品牌/商业/广告/媒体组合,可用 list_categories 查看;all=全部 |
Changes observed during successful MCP inspections.
Input schema / properties / category / descriptionPrevious value: -"信源分类,可用 list_categories 查看;all=全部"New value: +"信源分类;industry=品牌/商业/广告/媒体组合,可用 list_categories 查看;all=全部"Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds behavioral context beyond annotations by clarifying that the tool returns raw article material and does not perform trend analysis itself, which is valuable for setting caller expectations.
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 short sentences, front-loaded with the core action and source scope, followed by filtering options and caller responsibility. Every sentence adds distinct value with no filler or repetition.
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 read-only, optional-parameter aggregation tool, the description is largely complete: it states the input source, filtering options, and the division of labor between tool and caller. It lacks exact return-field examples and sorting/pagination details, but the absence of an output schema and the simplicity of the tool make this acceptable.
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 67%: keyword and category are described in the schema, while limit is not. The description reinforces the purpose of keyword/category filtering but adds little detail about limit behavior or how filters interact. It partially compensates for the missing limit documentation, so a 3 is 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 action (aggregate latest articles) on a specific resource (high-quality tech/AI/business/marketing sources) and mentions filtering by category/keyword. It is clear and distinct from generic siblings, though it does not explicitly name a sibling or contrast itself with one.
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 implies usage: gather raw future-trend signal material and let the calling LLM do trend judgment. It provides useful context for when to call it, but it does not explicitly state when not to use it or name alternative tools like discover_trending_topics or get_trending.
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.