Loading ToolBench
Document Manager MCP server with Azure Blob Storage backend, OAuth authentication, and client-side AES-GCM encryption for plaintext documents
This HTTP-based Rust MCP server provides 8 document management tools with generally clear naming and complete JSON Schema definitions. All tools follow verb_noun conventions (list_, get_, create_, update_, delete_, add_, remove_). Input schemas are formally specified with type definitions and required fields. However, descriptions are terse (most under 100 chars), parameter descriptions are minimal or absent, output schemas are not documented, and error handling lacks recovery guidance. The server implements risk annotations (READ_ONLY, WRITE, DESTRUCTIVE) which partially compensates for thin descriptions. No tool annotations (readOnlyHint/destructiveHint) are present in the MCP protocol layer despite the risk classifications existing in the server metadata.
Attach a file to a plaintext document, replacing any existing attachment. Refuses encrypted documents.
Create a new plaintext document with optional title and optional file attachment. Returns the new document's id.
Delete a document and all its attachments. Irreversible.
Fetch a document's file attachment by document id. Returns the file as base64-encoded bytes and original filename. Refuses encrypted attachments.
Fetch a single plaintext document by id. Refuses encrypted documents (their content is unreadable server-side).
List every document in the vault with its id, title, encryption status, attachment status, and content size.
Output schemas not documented. The server returns results (list of documents with id/title/encrypted status; file content as base64, etc.) but MCP tool definitions lack returnType or description of response structure. LLMs cannot plan multi-step operations or extract required fields for downstream tool calls.
Parameter descriptions are absent or minimal. The 'id' parameter across all tools is described as 'The document id (UUID, exactly as returned by list_documents)', adequate but doesn't explain what happens if the ID is invalid, whether it's case-sensitive, or what format UUID must take. The 'bytes' parameter in add_attachment says 'Base64-encoded file content' but doesn't specify maximum size or what happens on overflow.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | 2026-07-28+ | v2 |
Delete a document's file attachment, leaving the document itself intact.
Update a plaintext document's title and/or content. Refuses to overwrite encrypted documents.
Error handling lacks recovery guidance. Descriptions say 'Refuses encrypted documents' and 'Refuses encrypted attachments' but don't explain what error will be returned, how the LLM can detect it, or what alternative action to take (e.g., 'encryption_error, call list_documents to check encryption status first').
No pagination or result limits documented. list_documents has no limit/offset/page parameters visible in the schema, and no statement of how many documents are returned. If the vault grows to thousands of documents, the tool will return unbounded results, exploding context size.
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) not present in MCP schema. The server has internal risk classifications (READ_ONLY, WRITE, DESTRUCTIVE) but these are not exposed as MCP tool annotations. LLM cannot distinguish safe reads from destructive writes without parsing description text.
No confirmation step for destructive operations. delete_document will permanently delete a document and all attachments with no dry-run, confirm, or undo option. An agent planning error could destroy user data irreversibly.
create_document description says 'with optional title and optional file attachment' but the schema shows no attachment parameter. The description is misleading, the tool cannot attach a file at creation; you must call add_attachment after. This will cause LLM to attempt invalid calls.