Loading ToolBench
面向研究生论文级别文献综述的学术论文管理与分析工具，支持多源学术搜索、智能质量评估、智能压缩、多 LLM Provider、Notion 知识库集成
This server has 16 tools with schemas present but significant quality gaps. All tools have descriptions (in Chinese), but they are brief (10-40 chars), leaving LLM context-selection decisions ambiguous. Input schemas exist and are well-formed JSON Schema with type declarations and descriptions, which is good. However, output schemas are entirely absent from the tool definitions, LLMs cannot see what fields to expect from any tool's return value. Tools use vague, generic names like 'convert_to_*' and 'process_arxiv_paper' that combine multiple concerns (search+download+parse+convert). Error handling is minimal, no recovery guidance, no actionable error messages, no categorization (retryable vs fatal). Parameter naming is inconsistent: some tools use `arxiv_id` while others reference paper metadata directly. The descriptions are translations to English from Chinese originals and lack the specificity needed for LLM tool selection (e.g., 'Parse PDF and return raw text content' does not explain WHEN to use parse_pdf_to_text vs parse_pdf_to_markdown). No tool declares permissions, audit trail requirements, or whether it modifies state (though risk tags are supplied externally). Tool composition is poor: batch_analyze_papers, process_arxiv_paper, and generate_unified_literature_review overlap significantly, it's unclear to an LLM which to call for a given intent.
批量并发分析多篇论文，生成单篇深度分析并保存到数据库
批量并发下载多篇论文的 PDF 文件
批量导出所有有单篇综述的论文为 Markdown 文件
清空工作区所有文件（危险操作）
转换为增强版学术文献综述（包含博士思维分析和Mermaid可视化）
转换为微信文章格式
下载 arXiv PDF 文件
No output schemas documented. LLMs cannot see what fields, types, or structure to expect from any tool's return value. This violates the tool-chain pattern, downstream tools cannot be selected if the LLM doesn't know what the current tool produces.
Tool descriptions are uniformly brief (20 - 45 chars) and lack context for LLM selection. Examples: 'Parse PDF and return raw text content', 'Download arXiv PDF file'. These do not explain WHEN to use the tool, what it returns, or how it differs from similar tools (parse_pdf_to_text vs parse_pdf_to_markdown are both present but descriptions do not clarify the distinction).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 28 | - | v1 |
将数据库中的单篇文献综述导出为 Markdown 文件
导出完整的 Notion 元数据（论文库 + 单篇综述 + 综合综述）
只导出增量内容的 Notion 元数据（需要提供已存在的论文列表）
基于多篇论文的单篇分析，生成跨论文的综合文献综述
解析 PDF 并返回 LLM 翻译后的中文 Markdown 文件
解析 PDF 并返回原始文本内容
完整流程处理 arXiv 论文（搜索、下载、解析、转换）
跨多个学术数据源搜索论文（DBLP、OpenReview、Papers With Code），返回 Notion 友好格式
搜索 arXiv 论文
Tool names violate single-responsibility principle. 'process_arxiv_paper' does search + download + parse + convert in one call, an LLM cannot decompose this into steps or handle partial failure. Similarly, 'batch_analyze_papers' combines download, analysis, and optional wechat generation. Split composite tools so agents can compose them.
No error handling guidance. Tools do not document what errors can occur (network timeout, invalid arxiv_id, PDF parse failure, API rate limit), whether they are retryable, or what the LLM should do next. A bare exception provides no recovery path.
Destructive tool (clear_workdir) lacks confirmation or dry-run support. The tool deletes all files in the work directory with no recovery options. An agent should not be able to invoke this without explicit user confirmation.
Tool names use 'convert_to_*' and 'export_to_*' patterns that conflate input with output format. Examples: 'convert_to_wechat_article', 'convert_to_academic_review_enhanced'. These names do not clearly state the action (transform? generate? summarize?) or preconditions (must PDF already be parsed?).
Parameters lack detail on format, range, and validation. Examples: 'maxConcurrent' has no min/max; 'temperature' (0-1 range) is documented in description but not enforced; 'sources' enum is present but Notion export tools lack description of what 'database_id' and 'page_id' look like or how to find them.
Tool output includes opaque IDs (arxiv_id stored in database) but tool descriptions do not clarify how to retrieve or reference them. The 'export_to_notion_update' tool requires a 'page_id', there is no documented way for an LLM to discover what page_id values are valid or where they come from.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). While external metadata labels tools as READ_ONLY, WRITE, or DESTRUCTIVE, the MCP tool definition itself does not carry this information. Agents cannot reason about safety without parsing external labels.