Loading ToolBench
MCP server (FastMCP): draft and publish Markdown to dev.to and Hashnode from Cursor or Claude Desktop.
Server has 12 tools with complete input schemas and descriptions. Naming follows verb_noun convention (publish_, devto_, hashnode_). Descriptions are present but vary in quality (50-250 chars). All parameters have types and descriptions. Output schemas are documented via return type hints. Error handling uses _ok/_fail pattern with structured responses. Main gaps: no enum constraints for scope parameters, no pagination metadata (total_count, next_cursor) in list responses, no confirmation pattern for destructive operations, and descriptions lack dependency hints or recovery guidance.
Permanently delete a dev.to article you own (DELETE /api/articles/{id}).
Fetch one dev.to article by numeric id (GET /api/articles/{id}).
List your dev.to articles. scope: published | unpublished | all (paginated).
Update a dev.to article you own. Pass only fields to change. Max 4 tags.
Fetch one Hashnode draft by id (GraphQL `draft`).
Fetch one published Hashnode post by id (GraphQL `post`).
List tools lack pagination metadata. devto_list_my_articles and hashnode_list_posts accept page/first/after but do not document or return total_count, has_more, or next_cursor. LLMs cannot determine if more results exist or how to fetch them efficiently.
scope parameter in devto_list_my_articles is free-form string, not enum. Description says 'published | unpublished | all' but no JSON Schema enum constraint. LLMs may pass invalid values; validation happens at runtime only.
Destructive operations (devto_delete_article, hashnode_remove_post) lack confirmation or dry-run pattern. No recovery guidance in error responses. Agents can permanently delete content without safeguards.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
List drafts for your publication.
List posts for your publication (cursor pagination; `after` from previous pageInfo).
Delete a published Hashnode post by id (`removePost`).
Update a published Hashnode post. Pass only fields to change.
Create and publish one article to dev.to and Hashnode from the same Markdown body. Returns a dict with `dev_to` and `hashnode` outcomes (ok, url, error, note). If hashnode_published is false, Hashnode stays a draft (see `note`).
Check dev.to API key and Hashnode publication access (no publishing).
Error responses use generic _fail() pattern with string messages. No error classification (retryable vs user-fixable vs fatal). LLMs cannot determine whether to retry, ask user, or abort.
Tool descriptions lack dependency hints and recovery guidance. E.g., publish_article does not mention that verify_credentials should be called first, or what to do if Hashnode token is missing.