Loading ToolBench
MCP server for managing flipbook presentations. Allows uploading PowerPoint/PDF files, importing Google Slides, and accessing flipbook viewer URLs and metadata.
The Flipbook MCP provides 6 tools with explicit JSON-RPC definitions in internal/mcp/server.go. All tools have names starting with action verbs (list_, create_, import_, get_, delete_) and descriptions. However, most parameter descriptions are minimal or missing, input schemas lack detailed type definitions for object properties, and output schemas are completely undocumented. The server implements basic error handling but does not provide recovery guidance. Parameter constraints are not enforced via enums or validated ranges. No tool annotations (readOnlyHint, destructiveHint) are present despite clear risk classifications. Overall, the server has a foundation (explicit schemas, descriptions) but falls short of production-grade quality due to incomplete parameter documentation and absent output schema documentation.
Upload a file (PowerPoint or PDF) to create a new flipbook. Accepts base64-encoded file content. Waits for conversion to complete and returns the viewer/embed URLs.
Delete a flipbook and all its associated files.
Get detailed information about a specific flipbook including page URLs, dimensions, and embed code.
Check the conversion status of a flipbook (pending, converting, ready, or error).
Import a Google Slides presentation by URL to create a new flipbook. The presentation must be publicly shared. Waits for conversion to complete.
List all flipbooks with their status, viewer URL, and embed URL.
Output schemas are completely undocumented. Tools return JSON responses but LLMs have no schema definition to understand what fields to expect, preventing downstream tool composition and forcing manual parsing.
Parameter descriptions are minimal or absent. 'file_base64' has a description but many properties in inputSchema are defined as map[string]string without clarifying format constraints, length limits, or valid values. LLMs cannot infer whether 'url' requires 'https://' or if 'title' has length restrictions.
No tool annotations present despite clear risk classifications. delete_flipbook is DESTRUCTIVE but lacks destructiveHint annotation. list_flipbooks is READ_ONLY but lacks readOnlyHint. Agents have no machine-readable signal of side effects.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | 2024-11-05+ | v1 |
Error responses lack recovery guidance. The server can return JSON-RPC errors via errorResp() but provides only error code and message with no actionable next step. Example: 'Invalid params' does not tell the LLM what to fix or what alternatives exist.
Input parameter constraints are not enforced. For example, 'filename' in create_flipbook has no validation that it includes a valid extension (pptx, pdf, etc.), and 'file_base64' has no check for valid base64 or maximum size, inviting invalid calls from LLMs.
Idempotency not addressed. create_flipbook accepts base64-encoded files but does not guarantee idempotency, if an LLM retries a failed creation with the same file, it may create duplicate flipbooks. No deduplication key or idempotent annotation is provided.
No pagination or result limits documented. list_flipbooks returns all flipbooks with no indication of limit, offset, or total count. If an account has thousands of flipbooks, this violates the enforce-result-limits pattern and risks context window exhaustion.