Loading ToolBench
MCP server for news search and retrieval from Elasticsearch. Provides tools for searching news by keywords, filtering with secondary queries, reading individual news items, and batch searching by multiple topics with complex filtering logic.
Server provides 4 news search tools with mostly adequate schemas and descriptions. All tools have explicit descriptions in Chinese, and parameter schemas are visible with type definitions. Output schemas are inferred from .model_dump() calls but not formally documented. No tool annotations (readOnlyHint, destructiveHint) present despite all tools being READ_ONLY. Parameter constraints are mentioned in text but not enforced via JSON Schema enums/patterns. The server shows competent baseline tool definition but misses patterns for LLM optimization and agent clarity.
获取新闻详情。该工具会根据给定的新闻ID（news_id），从新闻库中获取完整的新闻内容。通常，news_id 是从 search_news 或 search_news_with_secondary_filter 工具返回结果中的 id 字段获取的。
根据关键词搜索新闻。可选参数支持按发布时间范围筛选结果。适用于需要多条件复合筛选新闻的场景。
根据主关键词和次关键词联合检索新闻。该工具会先用主关键词在新闻库中查找相关内容，再用次关键词对结果进行进一步过滤，最终返回同时包含主关键词和次关键词的新闻列表。可选参数还支持按发布时间范围筛选结果。适用于需要多条件复合筛选新闻的场景。
根据多个主关键词列表、筛选词列表(组)、数据源列表以 OR 关系批量查询新闻，支持时间范围筛选. 基本查询逻辑：<label1>&<filtered_words>|<label2>&<filtered_words>|<source1>&<filtered_words>|...|允许在基本查询逻辑之上再搜索
Parameter descriptions embed example values (e.g., '例如：\'人工智能\'、\'华为 5G\''), which LLMs tend to reuse literally instead of adapting to context. Rubric baseline: examples should be in schema constraints (enums, patterns), not descriptions.
No tool annotations (readOnlyHint=true, destructiveHint=false, idempotentHint=true) despite all tools being READ_ONLY and idempotent. MCP spec (2026-07-28) includes tool annotations to communicate tool semantics. Agents could use this to optimize execution order and safety.
Output schema not formally documented. Tools return List[dict] or dict (from .model_dump()), but the Pydantic model structure is not visible in the tool definition. Rubric requires: 'Document the output schema. LLMs need to know what fields to expect.' Agent cannot predict what fields will be in the response.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 54 | - | v1 |
Numeric parameter 'max_results' lacks min/max constraints in JSON Schema. Description states '1-100' in text, but no minValue/maxValue in schema definition. Rubric: 'Specify minimum and maximum for numeric parameters... Unbounded numbers let LLMs pass absurd values.'
Date parameters (date_from, date_to) lack format validation. Descriptions state 'YYYY-MM-DD' but no JSON Schema 'format': 'date' constraint. LLMs may pass '2024-6-1' or '06/01/2024', causing silent parse errors.
No documented error handling or recovery guidance. Code does not show try/catch, error classification, or actionable error messages. Rubric: 'Error responses must tell the LLM what to do next.' If Elasticsearch returns 0 results or a connection error, what does the agent see?
Descriptions are in Chinese and read as user-facing API docs, not agent guidance. Rubric: 'Write descriptions as if prompt-engineering. State WHAT the tool does, WHEN to use it, and any prerequisites.' E.g., search_news_with_secondary_filter should clarify when to prefer it over search_news (when filtering on a secondary dimension is essential).
search_topic_news description is incomplete and truncated in source. The description ends mid-sentence: 'Allow…ing in basic query logic…'. This is both grammatically broken and uninformative to an agent.
primary_queries parameter in search_topic_news is marked required but uses 'default=[]' array syntax. Inconsistent. If required, remove default. If optional, state clearly in description.