This is a moderately equipped DEVONthink MCP server with 28 tools. The server shows uneven quality across tools: some (add_tags, classify, compare, ask_ai_about_documents, create_summary_document) have detailed schemas and descriptions; many others (is_running, create_record, delete_record, move_record, etc.) lack visible schema definitions in the provided source. The naming is consistently verb-based and clear (create_, get_, delete_, search_), which is good. However, critical infrastructure tools lack documented input schemas, only 4-6 tools show complete schema visibility in the source code provided. Many tool files are referenced but their actual schema/parameter definitions are not shown, forcing schema scores to 0 per the rubric. Descriptions vary: some tools have rich, context-aware descriptions (100+ chars); others are minimal or inferred from names alone. Error handling is not visible in the source snippets provided. The server does support prompts and resources (optional features), which is good for MCP richness, but does not show logging, sampling, elicitation, or tool annotations.

• Add full input/output schemas to all 21 tools that lack them. Prioritize CRUD tools (create_record, delete_record, update_record_content) since these are core operations.
• Write descriptions (50-200 chars) for all tools, following the pattern: WHAT does it do, WHEN to use it (vs similar tools), any prerequisites. Example: 'Search for DEVONthink records by name, metadata, or content. Use this for broad discovery; use get_record_by_identifier for direct UUID lookups.'
• Standardize parameter names across all tools. Use 'record_uuid' (not 'uuid' or 'recordUuid') consistently. Use 'database_name' consistently. This reduces LLM confusion.
• Document output schemas for all tools. At minimum: what fields does each response contain? What are their types? Example: 'Returns {record_uuid: string, name: string, created_at: ISO8601, tags: string[]}'
• Add error handling patterns to destructive tools (delete_record, remove_tags). Consider: dry-run mode, confirmation step, or detailed error messages like 'Record not found. Check UUID with search() first.'
• Clarify tool distinctions: make descriptions explicit about when to use search vs lookup_record vs get_record_by_identifier. State the difference in each tool's description.
• Add enum constraints to 'databaseName' parameters in classify and compare. List valid database names or explain how to discover them.
• Add pagination support to list_group_content if not present. Include limit (1-100, default 20) and offset parameters. Document max result count.