Loading ToolBench
MCP server for collecting and processing technology news for Koala tech weekly newsletter
koala-news server exhibits major quality gaps across naming, descriptions, and schema documentation. Both tools have minimal descriptions (under 20 chars in English context after translation), vague names that don't follow verb_noun pattern, and incomplete parameter documentation. Input schemas exist but lack parameter descriptions. No output schema documentation visible. Error handling is absent from the provided code. The server is a proof-of-concept demo rather than production-grade tooling.
从链接中收集信息，生成 Koala 科技周报文案
从往期 PDF 归档文件中提取周报文案
Tool names do not follow verb_noun convention. 'collect-from-link' uses hyphens and is not action-clear; 'parse-pdf' is similarly vague. Names like 'extract_content_from_url' or 'extract_pdf_text' would be clearer and help LLMs understand intent from the name alone.
Tool descriptions are under 20 characters in English and lack context. 'collect-from-link' description is in Chinese only ('从链接中收集信息，生成 Koala 科技周报文案'), approximately 20 chars in Chinese. 'parse-pdf' is similarly brief. Descriptions must be 10 - 1024 chars and explain WHAT the tool does, WHEN to use it, and any prerequisites, in English for LLM consumption.
Parameter descriptions are completely missing. The 'link' parameter in collect-from-link and 'content' parameter in parse-pdf have no descriptions. LLMs cannot infer parameter meaning from names alone, 'content' is ambiguous (raw bytes? text? PDF path?). Every parameter must have a non-empty, actionable description.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 34 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 34 | - | v1 |
No output schema documentation visible in the source. The tools accept input but their return types are not documented. LLMs need to know what fields to expect in responses so they can chain tools and extract the right data. Baseline: 100% of A+ tools have documented return types.
No error handling or recovery guidance visible. The code calls external APIs (Jina reader, Supabase, PDF extraction) but provides no error messages, categorization, or actionable guidance for LLMs. If a URL is unreachable or PDF parsing fails, the LLM receives no instruction on what to do next.
Security concern: Supabase credentials are partially hardcoded in the server code ('https://xasgqzteakyjyjnumosb.supabase.co'), with only the API key expected from env vars. The URL should also be a secret, or at minimum, documented as such. Credentials must never be embedded in source; use full server-side secret injection.
Parameter naming lacks type suffixes and natural-language support. The 'link' parameter is clear, but 'content' is ambiguous, does it accept a PDF file path, raw binary, or text? There are no enums, regex patterns, or format constraints documented in parameter descriptions. LLMs may pass invalid values without knowing the expected format.