Two tools present with basic naming and minimal descriptions. search_by_text and get_conversation_messages follow action-verb convention (search_, get_), but descriptions are functional but terse (59 and 67 chars respectively). Both tools have input schemas with typed parameters and defaults, but lack detailed descriptions explaining WHEN to use each tool, WHAT distinguishes them, or error guidance. Output schemas are undocumented, the LLM cannot predict what fields will be returned. No error classification or recovery guidance. The TwitterDMSearch class implementation shows proper field resolution (extracting sender/recipient user objects), but the tool interface doesn't expose this richness or explain it to the LLM. Parameters have types but lack format/constraint documentation. Searches are case-insensitive internally, but this affordance is not mentioned in descriptions. No pagination guidance despite the 'limit' parameter suggesting large result sets. Tool composition is reasonable (search vs get_conversation are distinct concerns), but parameter naming lacks clarity, 'query' could be more specific ('text_query' or 'search_text') to avoid ambiguity with other search dimensions like sender_id or conversation_id that the internal class supports but are not exposed as tool parameters.

• Expand search_by_text description to ~100-150 chars: 'Search for messages containing specific text. Use this to find messages by keywords, partial text, or phrase. Case-insensitive. Returns up to 'limit' most recent matches sorted by time (newest first). If no results, returns empty list.'
• Expand get_conversation_messages description similarly: 'Retrieve all messages in a specific conversation, sorted by time (newest first). Use this to view a full conversation thread. Requires a conversation_id (obtain from search_by_text results or list_conversations). Returns up to 'limit' most recent messages.'
• Document input and output schemas explicitly in the tool metadata or in docstring format that a client parser can extract. Output should specify: [{ id, conversation_id, time, message_data: { id, text, sender: { id, screen_name, ... }, recipient: { id, screen_name, ... }, ... } }, ...]. Add 'limit' parameter constraint: 'Integer, 1-100, default 10.'
• Add error handling: If query is empty/whitespace, return { error: 'query cannot be empty. Provide at least one character to search.' }. If conversation_id not found, return { error: 'Conversation not found. Call list_conversations() to see available IDs.' }.
• Consider exposing additional tool parameters for common filters: add optional parameters 'sender_id' and 'recipient_id' to search_by_text so the LLM can narrow results without client-side post-processing. Update description to reflect these new parameters.
• Add a list_conversations or search_conversations tool to help LLMs discover available conversation IDs without blindly guessing. This prevents 'not found' errors.