The Signal MCP server has three READ_ONLY tools with basic descriptions and schemas visible in the source code. However, significant issues limit quality: (1) Parameter redundancy: all three tools repeat the same 6 parameters (source_dir, password, key, chats, include_empty, include_disappearing) across every function signature. This violates single responsibility and composition patterns, these are configuration concerns that should be handled once at initialization, not repeated for every call. (2) Descriptions are present but generic; they largely mirror the docstring template without explaining WHEN to use each tool or what distinguishes them from each other. (3) Input schemas are visible and properly typed (Path, str, bool, Optional[int]), but parameters lack actionable constraints, no ranges for offset/limit, no explanation of the 'chats' CSV format. (4) No output schema documentation, return types are declared (List[Dict[str, Any]]) but field names and structure are undocumented, forcing LLMs to infer. (5) No error handling guidance, if a chat_name doesn't exist or source_dir is invalid, the tools fail silently or return empty results with no recovery hints. (6) The tools lack clear composition, it's not obvious to an LLM when to use signal_list_chats vs signal_get_chat_messages, or whether signal_search_chat requires calling signal_list_chats first.

• Refactor configuration parameters (source_dir, password, key, chats, include_empty, include_disappearing) into a single 'signal_config' object or server initialization step. This reduces parameter bloat and makes each tool's core responsibility clear.
• Document the output schema for each tool. Specify field names, types, and ranges. E.g., signal_list_chats returns [{name: str, total_messages: int, serviceId: str, ...}]. signal_get_chat_messages returns [{date: ISO8601, sender: str, body: str, quote: str, reactions: list[str], ...}].
• Enhance descriptions to guide LLM selection. E.g., signal_list_chats: 'List all available Signal chats. Use this first to discover chat names before calling signal_get_chat_messages.' signal_search_chat: 'Search for specific text within a single chat, faster than fetching all messages when looking for a keyword.' signal_get_chat_messages: 'Retrieve all or paginated messages from a specific chat by name.'
• Add input constraints and validation hints. E.g., offset: 'Number of messages to skip (0+, typically 0-based pagination)', limit: 'Max messages to return (1-1000, recommended 20-100 to avoid context overflow)', chats: 'Comma-separated chat IDs to filter; if empty, all chats are included.'
• Implement comprehensive error handling. Return structured errors like {error: 'chat_not_found', message: 'Chat "john doe" not found. Available chats: john, jane, group-project. Try again with a known chat name.', available_chats: [list]}. Or {error: 'invalid_password', message: 'Signal data is encrypted but no valid password provided. Pass password parameter.'}.