Loading ToolBench
A Go-based backend service with Gin framework that provides article generation and management capabilities, integrating with Dify platform for AI-powered article creation
This MCP server exposes 4 article management tools via HTTP with significant quality gaps. Tool names lack verb prefixes (SaveArticleApi vs save_article), descriptions are minimal (12-42 chars vs baseline 194), and parameter schemas are incomplete. No input validation guidance, error handling is absent, and the output schema is undocumented. The server appears to be a wrapper around a Gin REST API rather than a purpose-built MCP implementation.
Calls the Dify platform to automatically generate an article based on a given title
Retrieves the full details of a specific article by its ID
Retrieves a paginated list of articles with optional keyword search
Saves an article with title and content to the database
Tool names do not follow verb_noun convention and include 'Api' suffix. LLMs parse intent from names, 'SaveArticleApi' is unclear whether it's read or write; 'save_article' is explicit. Names like 'GenerateArticleApi' conflate the action with implementation details.
Descriptions are far below baseline (12-42 chars vs 194 chars average). SaveArticleApi: 'Saves an article with title and content to the database' (57 chars) lacks context on constraints, side effects, or when to use it. GenerateArticleApi (52 chars) does not explain Dify integration or expected latency. LLMs cannot reliably select tools without substantive descriptions.
No output schema is documented for any tool. LLMs do not know what fields to expect in responses, preventing downstream tool composition and data extraction. GetArticleListApi should document that it returns {articles: [{id, title, ...}], total, page, page_size}. GetArticleDetailApi should describe the article object structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 30 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 29 | - | v1 |
Parameter descriptions are minimal or absent. GetArticleListApi 'page' parameter has description 'Page number for pagination' but no guidance on 0-indexing vs 1-indexing. 'page_size' lacks detail on why the maximum is 100. 'keyword' has no mention of which fields it searches (title, content, or both) or case sensitivity.
SaveArticleApi and GenerateArticleApi are write operations but lack any mention of side effects, idempotency, or error recovery in descriptions. An LLM will not know if these operations are safe to retry or if they create duplicates on failure. Per pattern:command-tool, write operations must explicitly state consequences.
No error handling guidance. If SaveArticleApi is called with an oversized title (exceeds 1000 chars) or GenerateArticleApi fails to reach Dify, there is no documented error message, recovery path, or retry guidance. Per pattern:recovery-guide, errors must tell the LLM what to do next.
GetArticleDetailApi 'id' parameter description says 'The article ID as a path parameter' (36 chars) but does not specify format (UUID, integer, string), constraints (max length), or how to obtain it. LLMs may guess wrong ID format.
SaveArticleApi returns no documented reference ID. If the agent calls it and then wants to read or delete the article, it has no way to reference the saved record. The response must include the generated article ID for composition with GetArticleDetailApi.
No pagination details in GetArticleListApi response documentation. If it returns 50 articles by default, does it include a total count, next_cursor, or has_more flag? Without this, agents cannot reliably paginate through large result sets.