Loading ToolBench
Local MCP server for Agent Drop file and secret handoffs between users and CLI AI agents.
Agent-drop defines 6 tools with explicit schemas and descriptions. Naming is clear and verb-based (get_, list_, deliver_, generate_, delete_, clear_). Descriptions are detailed and contextual (avg ~180 chars), exceeding the 10 - 1024 char baseline. However, several tools lack output schema documentation, parameter descriptions are sometimes vague (e.g., 'target' enum in clear_drops lacks explanation of what each value does), and error handling is minimal. No tool annotations (readOnlyHint, destructiveHint) despite clear risk profiles. Input schemas are present but some parameters lack type constraints (e.g., 'filename' in delete_specific_drop accepts any string without validation guidance). The server is locally scoped (STDIO), limiting production applicability.
Wipes the drop folders clean. Use this when you are starting a fresh project and want to clear out all old contextual screenshots and logs.
Delete a specific file from the dropzone. Use this to clean up temporary files you requested from the user but no longer need, keeping their web UI tidy.
PRIMARY DELIVERY TOOL: Use this for ALL documents, reports, and generated files. 1) Write your content to a temporary file in the workspace. 2) Call this tool with the absolute path. This is the most token-efficient way to deliver large artifacts. You MUST specify your agent_name (e.g., 'Gemini', 'Codex') so the user knows who delivered the file.
TINY SNIPPET DELIVERY: Use ONLY for very short text snippets (< 500 characters). For anything longer, you MUST write to a file first and use `deliver_to_user_device` to avoid bloating the conversation history with raw text. You MUST specify your agent_name (e.g., 'Gemini', 'Codex') so the user knows who delivered the file.
Call this immediately when the user says they 'uploaded', 'sent', or 'dropped' a file/screenshot to you. It checks the drop folder and returns the absolute file paths of any files the user recently uploaded that you haven't processed yet. NOTE: Calling this tool AUTOMATICALLY marks the returned files as 'read', so they won't clutter your future queries. You can optionally filter by how recently the file was uploaded.
Output schemas not documented. Tools return results but LLMs cannot infer response structure (e.g., get_unread_uploads returns file paths and metadata, but no schema is provided). This forces LLMs to guess field names and types.
Tool 'generate_and_deliver_file' violates single-responsibility principle. Name contains 'and' (generate_and_deliver), combining file creation and delivery. Should split into separate tools or rename to reflect the primary action.
Destructive tools (delete_specific_drop, clear_drops) lack confirmation/dry-run support and have no tool annotations (destructiveHint). No guidance on recovery or undo. Agents may accidentally delete files without safeguards.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
Returns a list of ALL files the user has ever uploaded to the dropzone (both read and unread), along with their upload timestamps. Use this if you need to find an older reference file or if get_unread_uploads didn't return what you were looking for.
Parameter 'target' in clear_drops uses enum ['user', 'agent', 'all'] but lacks description explaining what each value does. LLMs cannot infer the semantic difference between 'user' and 'agent' drops.
No error handling guidance. Tools do not document failure modes, recovery steps, or actionable error messages. E.g., if a file path is invalid or permissions denied, LLMs receive no guidance on what to do next.