The server defines 3 tools with explicit names, descriptions, and JSON Schema input parameters. However, descriptions are generic and do not address the selection criteria, error recovery, or LLM-friendly guidance required by production patterns. Parameter descriptions are present but minimal. Output schemas are not documented anywhere in the codebase. Tool names follow verb_noun convention (mattermost_channels, mattermost_fetch, mattermost_search) but descriptions are shallow and do not differentiate the tools well. No error handling guidance, no field chaining IDs documented, and no pagination limits documented despite tools accepting 'limit' parameters.

• Expand tool descriptions to 100-200 characters, explaining when to call each tool: e.g., 'mattermost_fetch retrieves recent messages from channels (use for latest activity). mattermost_search finds messages matching a query, with date filtering (use for topic-specific searches).'
• Document the output schema for each tool in source code or README, specifying fields returned (e.g., mattermost_channels returns [{id, name, display_name, creator_id, topic, purpose}, ...]; mattermost_fetch returns {channel_name: [{user_id, username, message, timestamp}, ...]})
• Add constraint details to parameter descriptions: e.g., 'limit (default 20, max 100): Maximum number of messages per channel' instead of relying on JSON Schema to define minimums
• Add error recovery guidance to descriptions: 'If channel_name is invalid, call mattermost_channels() first to list available channels.'
• Rename tools for clarity: consider 'mattermost_list_channels', 'mattermost_get_recent_messages', 'mattermost_search_messages' to make the distinction unambiguous
• Document default values explicitly in descriptions: e.g., 'If channels parameter is omitted, defaults to ["general", "announcements"]' (or whatever the actual defaults are)
• Add pagination support: if tools can filter by offset/cursor, add those parameters and document return fields (total_count, next_cursor) so agents can iterate large result sets
• Clarify timezone and date handling: 'Dates in yyyy-mm-dd format (UTC). before/after are inclusive boundaries.'

Inferred effective spec: <=2025-11-25.

• Relies on Stateful initialize / Mcp-Session-Id (removed; protocol is stateless) - make each request self-contained