Loading ToolBench
Managed or self-hosted knowledge workspace for AI agents with hybrid search, reranking, GraphRAG, and scoped document tools.
DocsMint MCP Server has 10 tools with consistent naming patterns and documented schemas. All tools start with action verbs (search_, get_, list_, create_, update_, delete_), and all have input parameter schemas with types. However, parameter descriptions are sparse or minimal, tool descriptions lack depth regarding when to use them vs alternatives, and output schemas are not documented. No error handling guidance is visible. The server lacks tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk stratification (READ_ONLY, WRITE, DESTRUCTIVE). This places the server solidly in the 'Fair to Poor' range, definitions are present but insufficient for LLM reliability.
Create a new document in the knowledge base
Create a new folder to organize documents
Delete a document from the knowledge base
Retrieve a specific document by ID with full content and metadata
Retrieve GraphRAG graph structure for knowledge visualization and traversal
List all documents with pagination and filtering options
List all folders in the knowledge base
List all available tags in the knowledge base
Missing output schema documentation. No tool documents what fields, types, or structure it returns. LLMs cannot plan downstream tool calls or extract relevant data without knowing the response structure.
Tool descriptions lack depth and selection context. Descriptions are 45 - 60 chars, stating WHAT the tool does but not WHEN to use it vs similar tools or what prerequisites exist. For example, 'Retrieve a specific document by ID with full content and metadata' (get_document) doesn't explain: Is this for detailed viewing or editing? Must you call search_documents first? What metadata is included?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
Search documents using hybrid search with semantic and keyword components
Update an existing document content and metadata
Parameter descriptions are either absent or generic. Many parameters lack context about their constraints, ranges, or expected formats. E.g., 'limit' and 'offset' in list_documents appear without specifying min/max bounds or explaining pagination behavior. No parameter descriptions document dependencies (e.g., folder_id is optional, what happens if omitted?).
No tool annotations for risk stratification. Tools are risk-classified (READ_ONLY, WRITE, DESTRUCTIVE) in metadata but MCP tool definitions lack readOnlyHint, destructiveHint, or idempotentHint attributes. LLMs cannot infer safe retry boundaries or whether operations have irreversible consequences.
No error handling or recovery guidance visible. Descriptions do not explain what errors are possible, whether they are retryable, or what the LLM should do next. E.g., delete_document offers no guidance on 'Document not found' or 'Permission denied' scenarios.
Potential for duplicate operations without idempotency guarantees. create_document and create_folder lack idempotency documentation. If an agent retries after a timeout, will it create a duplicate document/folder or recognize the same request? This invites data integrity issues.
No documentation of required vs optional parameters or their interactions. create_document lists tags and folder_id as optional without explaining whether omitting them has side effects or defaults. When parameters are interdependent (e.g., 'tags' only meaningful if creating), undocumented dependencies cause silent misuse.
Pagination design unclear. list_documents and list_folders accept offset/limit but do not document: Is offset the document number or result position? Does a result of 0 items mean no more results? Should LLMs stop after a certain offset, or continue until an empty response? Ambiguous pagination forces agents to guess or waste calls.