Loading ToolBench
A document parsing server that extracts content, layout, and tables from documents using OCR and multimodal analysis
This server has critical structural and definition issues. Only one tool (parse_document_layout) is present with a basic schema and minimal description. The tool lacks comprehensive parameter documentation, output schema specification, error handling guidance, and lacks critical context about operation, prerequisites, and what happens when called. The implementation in client.py shows a mock/stub implementation returning hardcoded markdown and table count, with no evidence of actual document parsing capability. No MCP server scaffolding is visible, no tool registration mechanism, no protocol implementation, no error handling framework, and no indication this is a functional MCP server at all. The codebase appears incomplete and unsuitable for production use.
Parses document layout and extracts content from a document URL
No MCP server implementation visible. The repo contains only a Python client class and example usage; no MCP protocol implementation, message handlers, or tool registration mechanism are present. Critical for claiming to be an MCP server.
Tool description is only 79 characters ('Parses document layout and extracts content from a document URL'). This is insufficient context for LLM selection. Missing: when to use this tool vs alternatives, what formats it supports, what it returns, error modes, and prerequisites. Baseline expectation is 194 chars average.
Input schema is incomplete. Parameters lack full JSON Schema formatting, type constraints, and validation rules. The 'dpi' parameter has a default (300) but no documented valid range (e.g., 72-600). The 'document_url' lacks format specification (must be valid http(s) URI). Missing required constraints and validation rules.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 37 | 2026-07-28+ | v2 |
Output schema is not documented anywhere. The tool returns {'parsed_markdown': str, 'extracted_tables_count': int}, but there is no formal schema specification, no description of field semantics, no indication of what markdown format is used, or what happens if extraction fails. LLMs cannot plan downstream tool calls without knowing output structure.
No error handling guidance. The stub implementation returns success-only responses. No documentation of failure modes: what happens if the URL is invalid, the document is unreadable, DPI is out of range, or the service times out? Error responses must tell LLMs what to do next.
Implementation is a mock stub. The parse_document_layout method returns hardcoded markdown and table count, with no actual document processing, URL fetching, or OCR logic. This is not a functional tool, it is a template.
No parameter descriptions for 'document_url'. While 'dpi' has a description, 'document_url' only has 'URL of the document to parse', this does not specify file format support, size limits, authentication requirements, or what happens for non-document URLs. Parameter descriptions must be actionable.
No security or permission documentation. No clarity on whether the tool validates URLs before fetching, whether it accepts authentication headers, whether it has rate limits, or what document formats are supported. Missing scope declarations and permission gates.