Output schemas are not documented. While input schemas are explicit and complete, there is no visible documentation of what each tool returns, making it difficult for LLMs to plan chaining or extract expected fields. This violates the response documentation pattern.

luma_create_event and luma_update_event use a generic 'object' type for geo_address_json without documenting the expected structure (keys like address, city, full_address, etc.). This forces LLMs to guess the structure and risk invalid requests.

Tool descriptions lack actionable guidance on when to use a tool vs. similar alternatives. For example, meetup_search_events and meetup_search_groups have similar signatures but no clarification of which is appropriate for different use cases. LLMs may struggle to select the right tool.

Error recovery guidance is not surfaced in tool descriptions. While the code includes ProviderError handling and ToolError raising, the tool descriptions do not document what errors are possible or how LLMs should respond. This violates the recovery-guide pattern.

meetup_login tool description does not explain the OAuth2 flow or what happens after redirect. A user reading the description alone would not understand that the tool returns a URL to be opened in a browser, or that tokens are cached server-side. This creates confusion about the tool's actual behavior.

Tools accepting array parameters (hosts, topics, roles) do not document constraints on array length, item type, or format. For example, meetup_create_event accepts 'hosts' as a list but does not specify if they should be member IDs, emails, or names, or if there's a maximum number of hosts.