Loading ToolBench
A Cloudflare Workers-based MCP server for managing a blog platform with AI integration, supporting post search, drafting, comment analysis, analytics, and media uploads.
The server defines 6 tools with basic naming conventions and descriptions, but exhibits significant quality gaps. All tools have descriptions (positive), but descriptions are generic and lack actionable context. Schemas are present but minimal, parameters lack proper descriptions in the schema itself, forcing reliance on tool-level descriptions. Critical issues: (1) parameters in schemas have descriptions but lack full validation constraints (enums, min/max); (2) no output schemas documented for any tool; (3) error handling guidance completely absent; (4) `draft_post` and `upload_image`/`upload_video` lack confirmation/dry-run patterns despite being destructive operations; (5) no permission gates or scope declarations visible. Naming is functional but generic (e.g., `upload_image`, `upload_video` don't clarify which service or idempotency). The `upload_image` and `upload_video` tools accept URLs but lack validation guidance for what constitutes a valid URL. The `draft_post` tool accepts optional `slug` but doesn't describe auto-generation logic or format constraints. Schema format is valid JSON Schema but underspecified for LLM safety.
Retrieve recent comments for analysis.
Get recent view counts and analytics summary.
Create a new draft blog post in the database.
Search for blog posts by title or content.
Upload an image to Cloudflare Images via URL.
Upload a video to Cloudflare Stream via URL.
No output schemas documented for any tool. LLMs cannot plan downstream tool calls or extract relevant response fields. search_posts returns results but structure is undocumented; draft_post creates a post but return value unclear; check_analytics returns summary data but field names unknown.
Destructive/stateful operations (draft_post, upload_image, upload_video) lack confirmation or dry-run patterns. Agents cannot preview side effects before committing. Creates risk of accidental post drafts or media uploads.
Parameter descriptions in schemas are generic or missing validation constraints. 'query' in search_posts should specify max length, character restrictions, supported syntax. 'url' in upload_image/upload_video should specify format (http/https), content-type expectations, max file size. 'limit' parameters lack min/max bounds (e.g., 1 - 100, not unbounded).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 40 | - | v1 |
No error handling guidance. Tools will fail silently or with HTTP errors. LLM has no recovery path (e.g., 'URL invalid, must be public HTTP/HTTPS' vs bare 400 error). No categorization of errors as retryable, user-fixable, or fatal.
No permission gates or scope declarations visible. Tools like draft_post and upload_image modify state but show no authorization checks. Cannot verify agent has write permissions before executing.
Tool names are generic and don't clarify target service. 'upload_image' could mean S3, Cloudflare, or local filesystem, should be 'upload_image_to_cloudflare' for clarity. Similarly, 'upload_video' doesn't specify Cloudflare Stream.
Parameter 'slug' in draft_post is optional with auto-generation fallback, but auto-generation logic is undocumented. Format constraints (lowercase, hyphens, length) unknown. LLM cannot verify provided slug is valid.
No chaining IDs documented. If search_posts returns results, response structure must include IDs/slugs needed by downstream tools (e.g., edit_post, delete_post). Current schema is silent on this.