Kaneo MCP server defines 6 tools with complete input schemas and basic descriptions. All tools have verb-noun naming (whoami, list_workspaces, list_projects, get_project, create_project, update_project) following conventions. However, descriptions are minimal (10-60 chars), lacking context on WHEN to use each tool, prerequisites, or return value structure. Parameter descriptions exist but are terse. No output schemas documented. Error handling and recovery guidance absent. Tool composition is reasonable (single responsibility), but descriptions fall short of LLM-optimized baselines (target 50-200 chars per pattern:tool-description). Risk annotations present (READ_ONLY, WRITE) but not formalized as toolAnnotations in protocol.

• Expand each tool description to 80-150 chars. Include: what it does, when to call it (vs. similar tools), and what it returns. Example: 'List all workspaces accessible to the signed-in user. Call this first to discover workspace IDs before listing projects. Returns array of {id, name, icon}.'
• Document output schemas for all tools. Specify field names, types, and whether results are paginated. Example: 'Returns {projects: [{id, name, icon, slug, description, isPublic, createdAt}], total: number}'.
• Add pagination to list_workspaces and list_projects: accept limit (1-100, default 20) and offset/cursor parameters. Return total count and next_cursor for large result sets.
• Add error recovery guidance. For create_project, document: 'If name already exists in workspace, error returns available names. If workspace_id invalid, call list_workspaces() first.'
• Formalize risk annotations as MCP toolAnnotations: set readOnlyHint=true for whoami/list_*/get_*, destructiveHint=true for create_*/update_*. This enables clients to warn users before destructive calls.