Loading ToolBench
MCP server for Dropbox (Business/Team): file management, search, shared links, and document reference.
Strong foundation with 16 well-named tools, clear descriptions (avg ~120 chars), and complete input schemas. All tools follow verb_noun naming (dropbox_get_*, dropbox_create_*, etc.). Descriptions explain WHAT, WHEN, and consequences. Input parameters are typed with descriptions. However, output schemas are not documented in the source, LLMs cannot see what fields to expect from responses. Error handling is minimal (no recovery guidance, no actionable error messages visible). Risk annotations (READ_ONLY, WRITE, DESTRUCTIVE) are present but not integrated into tool definitions as toolAnnotations. Parameter descriptions could be more prescriptive about formats and constraints.
Copy a file or folder to a new path.
Create a folder at the given path.
Create a shareable link for a file or folder. If a link already exists for the path, the existing link is returned instead of erroring.
Delete a file or folder (and its contents). Destructive — the item moves to deleted state and can be restored from Dropbox for the retention window.
Return the authenticated account (name, email, account id, team). Good for confirming the server is connected to the right Dropbox.
Get metadata (size, modified time, id, etc.) for a single file or folder.
Output schemas not documented. LLMs cannot see what fields responses contain (e.g., what does dropbox_list_folder return? file list structure? metadata?). This forces agents to guess and wastes tokens on trial-and-error parsing.
Risk annotations (READ_ONLY, WRITE, DESTRUCTIVE) are metadata but not integrated into tool definitions as toolAnnotations (readOnlyHint, destructiveHint). MCP spec supports these, they should be declared in the tool schema for client-side safety warnings.
No error recovery guidance. When a tool fails (e.g., 'file not found', 'permission denied'), the response does not suggest next steps. Errors should categorize as retryable/user-fixable/fatal and guide the LLM.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2025-06-18+ | v2 |
Look up metadata for an existing shared link URL.
Return storage usage and allocation for the account.
Get a direct, time-limited (~4h) download/streaming URL for a file. Use this to reference or fetch file contents without creating a permanent shared link.
List the contents of a folder. Pass "" for the root. Set recursive=true to walk subfolders. If the result is truncated, call again with the returned cursor.
List existing shared links, optionally for a specific path. Paginates via cursor.
Move or rename a file or folder from one path to another.
Download a file and return its contents as UTF-8 text — for referencing docs, notes, code, csv, etc. Guarded by DROPBOX_MAX_READ_BYTES (default 5 MB). For large or binary files use dropbox_get_temporary_link instead.
Disable a shared link so the URL no longer grants access.
Search the account for files and folders matching a query (filename and, where indexed, content). Optionally scope to a folder. If the result has_more, call again with the returned cursor.
Upload content to a path. Provide either `text` (inline UTF-8) or `localPath` (a file on this machine to read). Files at/under ~140 MB go in a single request; larger local files are streamed in chunks via an upload session automatically.
Parameter descriptions lack format constraints. E.g., 'path' is described as 'Dropbox path' but does not specify: must start with '/'? Can contain spaces? Max length? LLMs need explicit constraints to avoid invalid input.
No pagination guidance in descriptions. Tools like dropbox_list_folder and dropbox_search accept 'cursor' but descriptions do not explain when/how to use it or what 'has_more' means. Agents may miss truncated results.