Critical failures across all dimensions. Tool definitions exist only in mcp.json with names and brief descriptions, but NO input schemas are visible in source code. The mcp.json file shows tool names and one-line descriptions (avg ~50 chars), but provides zero parameter definitions, type information, or output schemas. Without schemas, LLMs cannot validate inputs or understand return structures. No evidence of error handling, permission gates, or security patterns. STDIO transport limits remote accessibility. This is a skeleton definition file with no implementation detail visible.

• Add complete JSON Schema inputSchema to every tool in mcp.json. For example, collection_manage should define parameters: { collection_id (string, required for update/delete), name (string, required for create), description (string, optional), parent_id (string, optional), action (enum: create|update|delete, required) }.
• Expand descriptions to 100-200 chars. Example: 'Create, update, or delete collections. Use create to add a new collection, update to rename or change parent, delete to remove. Requires collection_id for update/delete, name for create.'
• Document output schemas for all tools. For list_raindrops: 'Returns { raindrops: [{id, title, url, tags, created_at}], total: number, limit: number, offset: number }'.
• Split 'manage' tools into separate create/update/delete tools. E.g., create_collection, update_collection, delete_collection. This makes LLM intent inference unambiguous.
• Add error handling documentation. For destructive tools, define: 'Returns { success: boolean, message: string, confirmation_required?: boolean }. If confirmation_required=true, call with confirmed=true parameter. On failure, returns { error: string, code: string, suggestion?: string }'.