Server exposes 12 tools with basic descriptions but critical gaps in schema completeness and parameter documentation. Tool names follow verb_noun convention (pharos_search, pharos_install, pharos_remove, pharos_list, pharos_publish) but lack clarity on A/B variants. Input schemas visible for most tools but parameter descriptions are minimal (1-2 sentences). No output schemas documented. Error handling is absent from tool definitions. The 'filters' parameter in search tools is typed as generic 'object' with no structure guidance. Destructive tools (pharos_remove, pharos_remove_apps) lack confirmation/dry-run patterns. No tool annotations (readOnlyHint, destructiveHint) despite clear risk classifications in metadata.

• Document output schemas for all tools. Example: pharos_search should return {servers: [{id, name, description, version, author}], total_count, next_cursor}. This enables chaining to pharos_install.
• Add confirmation/dry-run pattern to pharos_remove and pharos_remove_apps. Implement a 'dry_run' boolean parameter (default false) or a separate 'confirm_remove' tool that requires explicit approval.
• Replace generic 'filters' object with explicit, typed parameters. Example: pharos_search(query, category: enum[discovery, data, ai, ...], min_version, author_name, limit: 1-50).
• Add tool annotations to all tool definitions. Use readOnlyHint=true for search/list/info tools; destructiveHint=true for remove tools; idempotentHint=true for install (if idempotent).
• Consolidate A/B tool variants. Instead of 12 tools (6 pairs), register 6 tools with an optional 'ui_mode' parameter or environment-driven conditional registration. This reduces cognitive load and prevents LLM confusion.

Inferred effective spec: 2026-07-28+.

• Official extensions adopted: Apps