Loading ToolBench
The server registers 9 tools with basic descriptions and input schemas, but falls significantly short of production quality. Descriptions are extremely terse (10-20 chars each), lacking context for when/why to use each tool. All tools are READ_ONLY and fairly well-structured, but parameter documentation is sparse. Tool naming follows verb_noun convention (get_status, get_contents, etc.), which is positive, but descriptions fail to explain what data each tool returns or when an agent should choose one over another. No output schemas are documented. Error handling is not visible in the provided code. The server uses @modelcontextprotocol/sdk v1.9.0 with proper tool registration via server.tool(), but the definitions themselves are minimal.
To get how many comments were made (per day) in tabnews
To get how many posts were made (per day) in tabnews
To get how many users were created (per day) in tabnews
get comments from a content on tabnews api
get content from tabnews api
get contents from tabnews api
get contents by user from tabnews api
Tool descriptions are critically short (10-21 characters), violating the 10-1024 character guideline (baseline: 194 chars avg). Examples: 'get status from tabnews api' (27 chars), 'get contents from tabnews api' (29 chars), 'To get the rss feed from tabnews' (32 chars). These descriptions provide no context for WHEN to call the tool, WHAT data it returns, or HOW to use it in multi-step workflows.
No output schemas are documented anywhere in the codebase. The types/index.ts file defines TypeScript interfaces (TabNewsContent, TabNewsContentChildren, etc.) but these are not exposed as schema documentation in tool definitions. LLMs cannot infer what fields a tool returns, forcing guesswork about downstream field names and risking broken tool chains.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 33 | - | v1 |
To get the rss feed from tabnews
get status from tabnews api
Parameter descriptions are missing for most optional parameters. For example, get_contents accepts 'page', 'per_page', and 'strategy' with descriptions in the schema, but the descriptions are generic ('The page number to get', 'The number of contents per page'). No guidance on valid ranges, defaults, or how pagination affects results. Strategy enum includes ['relevant', 'new', 'old'] but lacks context on what each means.
No error handling guidance visible. The code does not show error responses, recovery paths, or actionable error messages. If a call fails (e.g., invalid username, network timeout, rate limit), the LLM has no guidance on what to do next.
Tool naming lacks clear distinctions in related tools. 'get_contents', 'get_contents_by_user', 'get_content' (singular), and 'get_comments' could be confused. The singular vs. plural distinction is subtle and requires careful reading. A clearer naming convention (e.g., list_contents, get_user_contents, get_content_by_slug, list_comments) would reduce ambiguity.
Pagination support is unclear. 'get_contents' and 'get_contents_by_user' accept 'page' and 'per_page' parameters, but there is no documentation of whether results include a total_count, next_cursor, or has_more field. Without pagination metadata, agents cannot reliably iterate through large result sets.