ocr2md-mcp demonstrates solid tool design with complete schemas, clear descriptions, and proper parameter typing. All 4 tools have explicit input schemas with type definitions and descriptions. Tool names follow verb_noun convention (ocr_file, ocr_url, ocr_batch, ocr_to_markdown). Descriptions are substantive (80-150 chars) and explain purpose and use cases. Parameters include enums (displayPath), constraints (concurrency 1-10), and optional flags. However, output schemas are not formally documented, responses return structuredContent but the shape is inferred from code. Error handling is minimal; no recovery guidance or actionable error messages visible. No tool annotations (readOnlyHint, idempotentHint) despite all tools being read-only. Batch tools lack per-item failure reporting.

• Add formal output schema documentation to each tool. Define the structuredContent shape (e.g. { markdown: string, pages: [...], metadata: {...} }) so LLMs know what fields to extract.
• Annotate all tools with readOnlyHint: true and idempotentHint: true in the tool definition. This signals to clients that results can be cached and calls are safe to retry.
• For ocr_batch and ocr_to_markdown, return per-file results with individual success/failure status: { filePath, status: 'success'|'error', markdown?: string, error?: { code, message, recoveryHint } }.
• Add error recovery guidance to tool descriptions. E.g. 'If TextIn API fails, retry after 30s. If file is unreadable, check file format is JPEG/PNG/PDF.'
• Validate and document the 'relativeTo' parameter: 'Base directory for relative paths. Must be an absolute path that exists. If omitted, defaults to current working directory.'