Loading ToolBench
Visual document to AI-ready Markdown conversion server with MCP support
doc7 provides 10 tools with generally good naming (verb_noun pattern) and adequate descriptions. However, there are critical gaps in schema completeness, parameter documentation, and error handling. Most tools have descriptions in the 50-200 char range which is appropriate, but several parameters lack descriptions or type constraints. Output schemas are not documented. The server shows mid-tier quality typical of community MCP servers, functional but with significant room for improvement in definition rigor.
Ask the user to choose from a small set of explicit options before a consequential action. Use this for model selection and configuration confirmation.
Ask the user to enter a local directory and authorize it for read-only tools during this chat session.
Convert a user-provided document, directory, HTTP(S) URL, or ZIP archive to AI-ready Markdown with optional instruction.
Convert a document, directory, HTTP(S) URL, or ZIP archive into Markdown and persisted page-level artifacts.
Discover models currently exposed by local LM Studio or Ollama-compatible runtimes. This does not change configuration.
Show the effective doc7 configuration, its file path, editable keys, and credential source without revealing secrets.
No output schemas documented for any tool. Tools return structured data (as seen in executeGetConfiguration returning map[string]interface{} and encodeChatJSON), but LLMs cannot plan downstream operations without knowing what fields to expect.
authorize_directory has empty input schema ({}). While intentional, the description provides no guidance on what the tool does, why it's needed, or what happens after calling it. Description is vague: 'Ask the user to enter a local directory and authorize it for read-only tools during this chat session.' Does not explain how subsequent tools use the authorization or what 'authorized' means.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | 2026-07-28+ | v2 |
Confirm locally, prompt the user for an API key with terminal echo disabled, then store it without exposing the value to the model. Never accepts the secret as a tool argument.
Run one portable read-only filesystem command inside authorized directories. This is not a shell and does not support pipes, redirects, scripts, networking, or writes.
Dry-run or apply a small validated configuration change. Without confirmation_id it only creates a proposal and never writes the file.
Send a real vision probe to an OpenAI-compatible endpoint and model. Use this before proposing a model switch.
Several parameters lack descriptions or have incomplete descriptions. Example: run_readonly_command has parameters 'pattern' and 'max_depth' with descriptions, but 'document_id' description is minimal ('Document ID returned by an earlier read-only command'), does not explain how to obtain it or when it's required vs optional.
convert_to_markdown and convert_document have overlapping names and descriptions. Both convert documents to markdown, but the distinction is unclear. 'convert_to_markdown' includes 'document_id' and 'merge' logic; 'convert_document' includes 'instruction' and also takes 'document_id'. Tool naming does not disambiguate when each should be used.
Error handling is minimal. No error responses are documented or shown in tool definitions. From the code sample, error results appear to be simple JSON objects (encodeChatToolResult(false, '...')), but LLMs need categorization: is the error retryable? Should the user fix input? Is it fatal? No recovery guidance is provided.
No documented idempotency or confirmation pattern for destructive operations. set_configuration applies changes to files; convert_to_markdown writes to 'output_dir'; input_secret modifies stored credentials. None have dry-run, preview, or confirmation steps documented to prevent accidental side effects.
ask_user's 'options' parameter is complex nested JSON with object properties (id, label, description, document_id) but lacks clear guidance on which fields are required, when document_id is populated, and what an LLM should do if the options array is empty or malformed.
No documented pagination or result limits for tools that return lists. discover_local_models and run_readonly_command (find command with max_results=100) may return large lists, but no guidance on pagination, chunking, or what happens if result count exceeds limits.