Server provides 6 read-only tools with basic schemas and descriptions. All tools have input schemas with type definitions and parameter descriptions, meeting minimum requirements. However, descriptions are generic and lack LLM-optimized guidance on WHEN to use each tool vs. alternatives. Output schemas are not documented. Error handling is minimal, no recovery guidance or actionable error messages. Tool naming follows verb_noun convention (search, fetch*) but lacks distinction between similar fetch tools (fetchWebContent vs. fetchCsdnArticle vs. fetchJuejinArticle). No tool annotations (readOnlyHint, idempotentHint) despite all being read-only. Parameter descriptions are present but terse (avg ~40 chars vs. baseline 72 chars).
Fetch the full content of a CSDN article
Fetch the README content from a GitHub repository
Fetch the full content of a Juejin (掘金) article
Fetch the full content of a Linux.do article
Fetch the full content of a web page
Search the web using multiple engines (e.g., Baidu, Bing, DuckDuckGo, CSDN, Exa, Brave, Juejin(掘金)) with no API key required
Four fetch tools (fetchLinuxDoArticle, fetchCsdnArticle, fetchJuejinArticle, fetchWebContent) are semantically similar but lack clear differentiation. LLMs will struggle to choose the right one. Descriptions do not explain WHEN to use each vs. alternatives.
No output schemas documented. LLMs cannot plan downstream operations or extract specific fields. E.g., does search() return title, url, snippet, date? Does fetchWebContent return markdown or HTML?
Tool descriptions are generic and lack LLM-optimized guidance. E.g., 'Fetch the full content of a Linux.do article' does not explain when to call this vs. search(). Descriptions average ~40 chars; baseline is 72 chars. No dependency hints or prerequisites.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | <=2025-11-25 | v2 |
No tool annotations (readOnlyHint, idempotentHint, destructiveHint) despite all tools being read-only and idempotent. Agents cannot infer safety properties without explicit hints.
Error handling is minimal. No recovery guidance, actionable error messages, or error classification (retryable vs. user-fixable vs. fatal). E.g., if a URL is invalid, the error should suggest 'Try search() first to find a valid article URL.'