Loading ToolBench
The Doctor MCP server has 7 tools with clear, action-verb names and mostly well-defined input schemas. However, there are significant gaps: tool descriptions are brief (many under 100 chars), parameter descriptions are sparse or missing entirely, output schemas are not documented, error handling is not visible, and there are no security annotations (tool tags like destructiveHint for delete_docs). The server is HTTP-based (good for protocol readiness), but the definition quality falls short of production-grade due to incomplete parameter coverage, missing output documentation, and lack of error guidance patterns.
Delete documents from the database based on filters
Fetch and index a URL, crawling pages starting from that URL
Retrieve the full text of a document page
Check the progress of a crawl job
List all available document pages
List all unique tags in the database
Search for documents using semantic search
Output schemas not documented. No tool specifies what fields are returned, what types they are, or how downstream tools should chain results. This forces LLMs to infer output structure, risking field mapping errors.
delete_docs is destructive but has no confirmation or dry-run step, no permission gate, and no audit trail pattern. Agents can irreversibly delete documents without safeguards.
Sparse parameter descriptions. Parameters like 'tags' appear in 4 tools but descriptions are minimal (e.g., 'Tags to assign this website', 'Tags to limit the search with'). Missing guidance on: format expectations, how tags are structured, whether they are case-sensitive, whether partial matches are allowed.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Tool descriptions are brief (30-60 chars for some), under the 50-200 char LLM-optimized range. E.g., 'List all available document pages' (31 chars) does not explain WHEN to call this instead of search_docs, what order results are in, or what the pagination scheme is.
No error handling patterns visible. No recovery guidance ('if search fails, try list_tags first'), no error classification (retryable vs. fatal), no actionable error messages. Code shows logging but no error response structure.
No tool annotations (destructiveHint, readOnlyHint, idempotentHint) visible in schema. This prevents clients from applying differential safety policies or rate limiting. delete_docs should declare destructiveHint=true; search_docs should declare readOnlyHint=true.
Pagination support is incomplete. list_doc_pages and search_docs accept max_results/limit but do not document total count or next_cursor in responses. Without clear pagination, large result sets risk context window overflow.
delete_docs has no scope declaration or permission gate visible. There is no documentation of who can call this tool, what permissions are required, or how it checks authorization before executing.