Loading ToolBench
A collection of MCP servers for various integrations including Blink CMS, DataFast, Digits, Railway, Stripe, Gmail, PostgreSQL, Fly, Tolt, and Video
17 CMS tools with well-structured definitions. Tool naming follows verb_noun convention consistently (cms_list_dir, cms_read_file, cms_write_file, etc.). Descriptions are generally clear and specific, most exceed the 50-char minimum and provide context on what each tool does. Input schemas are present for all tools with proper JSON Schema structure. However, output schemas are undocumented (critical gap), error handling guidance is minimal, and some descriptions lack sufficient detail on when/why to use the tool versus alternatives. The cms_search_replace and cms_multi_edit tools have unusually lengthy descriptions that include implementation details (exact matching, flexible whitespace) which, while helpful, violate the 10-1024 char guideline by pushing toward the upper bound. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present despite tools spanning read/write/reversible categories. Overall, definitions are above-average for community MCP servers but fall short of production-grade clarity.
Rollback: copies a previous version to live content. Does NOT create new version.
Move a CMS content file to Trash (soft delete). Can be restored later.
Discard unpublished changes. Reverts content to last published version. No version created.
Get version history for a content item (shows version numbers, change summaries, who made changes)
Search CMS content with Meilisearch for fuzzy text matching. Returns excerpts with highlighted matches - perfect for finding text to use with cms_search_replace. Features: - Fuzzy matching (handles typos and variations) - Returns relevant excerpts with <<<highlighted>>> matches - Shows exact match positions in content - Much faster than scanning all files Use this BEFORE cms_search_replace to find the exact text you need to replace.
List CMS content in a directory path. Use "docs" for documentation, "blog" for blog posts.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract the right fields from responses. This forces inference and increases hallucination risk.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear semantic differences: cms_list_dir, cms_read_file, cms_search, cms_grep are read-only; cms_write_file, cms_search_replace, cms_publish, cms_unpublish are destructive; cms_delete_file, cms_restore_file, cms_discard_draft are reversible. Annotations help agents reason about safety and retry logic.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 53 | - | v1 |
List articles with unpublished changes (draft content newer than last publish)
List deleted content in Trash
Make multiple edits to a single CMS file in one atomic operation. All edits must succeed or none are applied. Features: - Edits are applied in sequence, each operating on the result of the previous - Atomic: all succeed or none are applied - Each edit has the same capabilities as cms_search_replace (exact + flexible matching) IMPORTANT: - Plan edits carefully - earlier edits change content that later edits search - Use replace_all for renaming across the file
Publish: creates a VERSION SNAPSHOT of current content and makes article visible. Versions are only created on publish.
Read a CMS content file. Returns current working content (draft if exists, else published).
Read the full content of a specific historical version
Restore a deleted file from Trash
Search CMS content by text query
Find and replace text in a CMS content file. Features: - Exact match first, then flexible whitespace matching (tolerates indentation differences) - Multiple occurrence detection: requires more context or replace_all=true when text appears multiple times - Cross-platform line ending normalization (\r\n → \n) - Returns git-style diff showing exactly what changed CRITICAL: For single replacement, include 3-5 lines of context before/after to uniquely identify the target.
Unpublish: makes article HIDDEN from website. Content and versions preserved.
Create or update content. Edits go to draft (NO version created). Use cms_publish to create version and make live.
cms_search_replace and cms_multi_edit have verbose descriptions (300+ chars) mixing usage guidance with implementation details (exact matching, whitespace tolerance, line endings). Descriptions should focus on WHAT/WHEN/WHY for LLM selection, not implementation internals.
No error handling guidance in descriptions. Tools like cms_delete_file, cms_publish, cms_activate_version perform state changes but offer no recovery hints (e.g., 'If deletion fails, check cms_list_trash'; 'If publish fails due to validation, fix content with cms_search_replace').
cms_publish and cms_unpublish accept 'paths' array but descriptions don't mention batch semantics or whether partial failures are possible. If one path fails, do all fail or only that one? Agents need per-item success/failure clarity.
cms_grep description mentions Meilisearch but tool is exposed as generic cms_grep. If Meilisearch is a backend detail, hide it; if it's a constraint (e.g., indexed fields only), document which fields are searchable.
cms_list_dir, cms_list_trash, cms_list_drafts lack pagination parameters (limit, offset, cursor). No description of max results. If a directory has 1000 files, LLMs cannot fetch beyond the first batch or know total count.
cms_activate_version description says 'Rollback: copies a previous version to live content. Does NOT create new version.' This is helpful but uses 'Rollback' which may confuse users expecting git-style rollback semantics. Clarify: 'Restore a previous version without creating a new version snapshot.'