Loading ToolBench
MCP server for Raindrop.io bookmark management API with tools for collections, raindrops, tags, filters, backups, exports, and file uploads
20 tools with consistent naming (verb_noun pattern) and reasonable descriptions (avg ~150 chars). All tools have input schemas with typed parameters and descriptions. However, output schemas are not documented, LLMs cannot predict response structure. Parameter descriptions are functional but lack format constraints (enums, ranges, patterns). Error handling is absent; no recovery guidance. Destructive tools (delete_collection, merge_collections) lack confirmation patterns despite confirm flags. No tool annotations (readOnlyHint, destructiveHint). Composition is sound, tools chain well via IDs, but descriptions could better explain when to use each tool vs. similar ones.
Creates a collection. POST /collection.
Downloads a backup to disk. GET /backup/{id}.{format}.
Expands or collapses ALL nested collections. PUT /collections {expanded}. confirm=True.
Exports the raindrops of a collection to a file. GET /raindrops/{id}/export.{format}.
Asks Raindrop to generate a new backup. GET /backup. Raindrop prepares the file asynchronously and emails it (how long depends on the number of bookmarks and the queue). It then shows up in raindrop_list_backups.
Lists nested collections (children, any depth). GET /collections/childrens.
Output schemas not documented. LLMs cannot predict response structure, forcing them to guess what fields are returned and how to chain tools. Every tool lacks a documented return type.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Destructive tools like raindrop_remove_collection, raindrop_merge_collections, and raindrop_remove_empty_collections lack explicit destructiveHint markers, forcing LLMs to infer risk from descriptions alone.
Parameter descriptions lack format constraints. 'format' param in raindrop_download_backup and raindrop_export_collection should declare enum values (csv|html|zip) in schema, not just description. 'view' in raindrop_create_collection should be an enum.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | 2026-07-28+ | v2 |
One collection in full. GET /collection/{id}.
Lists top level (root) collections. GET /collections.
Returns the featured collection covers. GET /collections/covers.
Returns the filter counters for a collection. GET /filters/{collectionId}.
Lists the available backups, newest first. GET /backups.
Merges collections: moves raindrops from ``ids`` into ``to``. PUT /collections/merge. GLOBAL and irreversible - needs confirm=True.
DELETES one collection (its raindrops move to Unsorted). DELETE /collection/{id}. Needs confirm=True.
DELETES several collections at once. DELETE /collections {ids}. Needs confirm=True.
Removes EVERY empty collection (count=0). PUT /collections/clean. GLOBAL - confirm=True.
Sorts ALL collections by a key. PUT /collections {sort}. GLOBAL - needs confirm=True.
Searches collection icons and covers by keyword. GET /collections/covers/{text}.
Updates a collection (only the fields you pass). PUT /collection/{id}.
Sets a raindrop's cover from a local file. PUT /raindrop/{id}/cover.
Creates a raindrop from a local file (image or PDF). PUT /raindrop/file.
No error handling or recovery guidance. Tools lack descriptions of failure modes, retryability, or what the LLM should do if a call fails. E.g., raindrop_download_backup does not explain what happens if the backup ID is invalid.
Destructive operations (raindrop_remove_collection, raindrop_merge_collections) require a confirm=True flag but lack a dry-run or explicit confirmation-request pattern. LLMs may pass confirm=True without user consent.