This server has significant structural issues. Tool definitions exist with schemas and descriptions, but quality is inconsistent. Critical problems: (1) Duplicate tool names (echo, read_file, open_app appear twice) create ambiguity and will confuse LLMs about which variant to call. (2) Descriptions are minimal (10-50 chars) and lack actionable context, e.g., 'list files in a directory' doesn't explain when to use it vs get_project_tree. (3) Parameter descriptions are sparse; many lack detail about format, constraints, or valid values. (4) No output schemas documented, LLMs cannot predict what fields to expect. (5) Error handling is absent from tool definitions. (6) Mock/test tools (echo, get_status) are mixed with production tools, polluting the namespace. (7) No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels. Average tool description length ~35 chars (baseline 194 chars); baseline requires 10-1024 chars with 50-200 optimal for LLM selection.

• Remove or isolate test tools (echo, get_status from test fixtures). Keep only production tools in the main tool registry. Separate test harness from agent-facing tools.
• Expand all tool descriptions to 50-200 characters. Include WHAT the tool does, WHEN to use it (vs similar tools), and any prerequisites. Example: 'list_files: List files and directories in a folder. Use this to explore directory structure; use get_project_tree for hierarchical view with depth control.'
• Document output schemas for every tool. Specify field names, types, and whether results are paginated. Example for list_files: 'Returns {files: [{name: string, path: string, size: int, modified: ISO8601}], total: int, next_cursor?: string}'.
• Resolve duplicate tool names. If echo and read_file appear in multiple files, consolidate into one canonical definition per tool. Use namespacing (e.g., test_echo vs echo) if both are needed.
• Add tool annotations: mark read-only tools with readOnlyHint=true; mark destructive tools (create_note, save_memory_fact, open_app) with destructiveHint=true; mark idempotent tools with idempotentHint=true. This enables agents to reason about safety and retry logic.