Loading ToolBench
Multi-source content intelligent processor that automatically detects input type, uploads to NotebookLM, and generates specified formats. Supports deep analysis mode with three-round progressive questioning (overview → deep excavation → synthesis). Also includes a Feishu document reader MCP server.
This server has significant quality gaps across naming, descriptions, schema completeness, and error handling. While two tools are present with basic descriptions, the implementation lacks proper input schema definitions visible in the code, parameter-level documentation, output schema specification, and error recovery guidance. The descriptions are minimal (19-23 chars for read_feishu_doc, similar for get_doc_info), falling below the 50-200 char baseline for LLM-optimized tools. Critical parameters like 'url' and 'cookies_str' are documented but the overall schema structure is not explicitly defined or validated. Error handling is generic ('success': False with error string) and does not guide the LLM toward recovery. The tools operate on a specialized domain (Feishu document reading) with no attempt to normalize or chain with downstream systems.
获取飞书文档的基本信息（不下载内容）
读取飞书文档内容并转换为 Markdown（支持图片）
Tool descriptions are too short (19-23 chars), well below the 50-200 char baseline for LLM-optimized descriptions. 'read_feishu_doc' as '读取飞书文档内容并转换为 Markdown（支持图片）' and 'get_doc_info' as '获取飞书文档的基本信息（不下载内容）' lack actionable context for when/why the LLM should call each tool.
Input schema definitions are not explicitly visible in the provided code. Parameter types and constraints (e.g., URL format validation, enum values, min/max for numeric fields) are documented only in natural language descriptions, not as formal JSON Schema. LLMs cannot reliably extract constraints from text alone.
Output schemas are not documented. The code shows return dicts with fields like 'success', 'title', 'author', 'content', 'images', 'word_count', 'error', but no explicit schema is provided. LLMs cannot plan downstream steps or extract fields reliably without a documented output contract.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 44 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Error handling lacks recovery guidance. Errors return {'success': False, 'error': <string>} with no indication of whether the failure is retryable, user-fixable, or fatal. The LLM receives no guidance on what to do next, e.g., 'Invalid URL format' should suggest 'Try using a valid Feishu document URL starting with https://bytedance.feishu.cn/docs/docc/...'
Parameter 'cookies_str' is optional but its role is unclear. Description says 'optional cookie string, format: key1=value1; key2=value2. If provided, can download authenticated images.' This implies it unlocks additional functionality but does not specify: Is authentication required for all docs or only some? What happens if an image requires auth but cookies are missing? Should the tool fail silently or error?
No pagination support documented. If a Feishu doc has thousands of words, the 'content' field returned by read_feishu_doc could be enormous, risking context window exhaustion. No limit parameter or streaming strategy is visible.
No tool-to-tool chaining support. get_doc_info returns title, author, word_count, image_count, but does not return a document_id or resource URI that could be passed to read_feishu_doc or other downstream tools. Chaining requires manual re-entry of the URL.