This MCP server has critical gaps in definition quality. Tool names are problematic: they use Chinese descriptions as primary identifiers and lack clear verb-noun patterns. For example, 'getFolders' lacks a descriptive action verb ('list_folders' would be clearer). All 7 tools have minimal schema documentation, input parameters are present but lack detailed type constraints, ranges, or format specifications. Descriptions are translated from Chinese and are sparse (20-70 chars), falling well below the 194-char baseline for production tools. Most critically, NO output schemas are documented anywhere in the provided source, making it impossible for agents to understand what these tools return. Parameter descriptions exist but are generic ('Folder name', 'File ID') without format guidance, constraints, or examples of expected values. Error handling and recovery guidance are completely absent. Security concerns: uploadFile accepts a 'multipart' parameter type (non-standard in JSON Schema), and there is no evidence of secret injection, permission gates, or audit logging. The tools appear to be a thin wrapper over Spring controller endpoints with minimal LLM-oriented design.

• Document the full output schema for each tool. E.g., 'getFolders returns {folders: [{id: long, name: string, parentId: long, createdAt: string, itemCount: int}], total: int, nextCursor?: string}'.
• Expand tool descriptions to 100-200 chars. Template: 'ACTION: What the tool does. WHEN: Use case or relationship to other tools. RETURN: What fields you get back. EXAMPLE: How an agent would use it.' E.g., for createFolder: 'Create a new folder in the tool share system. Use this after getFolders() to verify the parent folder exists. Returns {folderId, name, parentId}. Useful for organizing shared tools by category.'
• Add constraint details to parameter descriptions. E.g., 'Folder name (string, 1-255 chars, no leading/trailing spaces, alphanumeric + dashes allowed)' instead of 'Folder name'.
• Fix uploadFile schema. Replace 'multipart' type with 'string' + 'binary' format, or document the multipart handling separately. Document expected file size limits and supported MIME types.
• Add pagination to getFolders and getFiles. Include limit (default 20, range 1-100), offset, and total count in responses. E.g., '{folders: [...], total: 150, offset: 0, limit: 20}'.
• Implement and document error handling. E.g., deleteFolder could return: '{success: false, error: "Folder not found (ID=999). Available folders: [123, 456, 789]"}' or '{success: false, error: "Folder not empty. Delete child items first."}'.
• Add dry-run parameters to destructive tools. E.g., deleteFile(id, dryRun=true) returns what WOULD be deleted without actually deleting.