This MCP server has significant definition quality gaps. While tools have names and basic descriptions, the schemas are incomplete or missing, descriptions are often generic, and there is no evidence of input validation, error handling guidance, or output schema documentation. The tools appear to be inferred from wrapper code rather than formally registered with complete MCP metadata. The codebase shows active development but lacks production-grade tool definition rigor.
Tools (9)
esa_create_postwriteauth50/100
Creates a new article in esa with specified title, content, and category
esa_get_membersread onlyauth50/100
Retrieves the list of members in the esa team
esa_get_postread onlyauth50/100
Retrieves a specific article from esa by post number
esa_list_postsread onlyauth50/100
Searches for articles in esa excluding AI-generated ghostwrite articles using query parameters
Missing output schemas for all tools. LLMs cannot infer response structure, forcing them to parse unstructured output or make assumptions about field names and types.
Parameter descriptions are generic or prescriptive ('Format: user:username...') rather than flexible. This constrains agent reasoning and forces agents to follow rigid templates instead of adapting to actual intent.
No input validation guidance. Parameters lack constraints on length, format, valid values, or ranges. E.g., 'limit' for slack_get_channel_history has no max, 'text' for slack_post_message has no length limit, 'category' for esa_create_post has no enum of valid values.
Add explicit output schemas for all tools. For list/search tools, document the structure of each item (fields, types, example values). E.g., slack_get_channel_history should return [{id, name, created, creator, topic, ...}, ...]. slack_post_message should return {channel_id, timestamp, message_id} to enable chaining.
Include WHEN to use the tool, prerequisites, and what the response contains. Example: 'Retrieve message history from a Slack channel within a time range. Returns up to [limit] messages; use this to search for historical context before posting. Requires channels:read scope.'
Add input validation constraints to parameters. Specify enums for known values (e.g., category in esa_create_post should be enum of valid paths), min/max for numbers (limit: 1-100), length limits for strings (title: 1-255 chars), and format patterns (post_number: positive integer > 0).
Document pagination explicitly. For list tools, add output fields: total_count (or has_more/next_cursor). Provide guidance: 'Call this multiple times with incremented page param until response.total_count <= page * per_page'.
Add error handling guidance. Each tool should document common failure modes and recovery hints. E.g., slack_post_message: 'If channel_id is invalid, returns error 'channel_not_found'. Try slack_list_channels() to find the correct channel_id.' esa_get_post: 'If post_number does not exist, returns 404. Check esa_list_posts() to confirm the post exists.'
Implement and document idempotency for write operations. slack_post_message and esa_create_post should accept an optional idempotency_key parameter to prevent duplicate sends on retry. Document: 'Omit idempotency_key for one-off sends; include it for retryable requests.'
No error handling or recovery guidance. Tools do not explain what happens on failure (e.g., invalid channel_id, missing post, unauthorized user), what the LLM should do next, or whether the error is retryable.
Pagination is incomplete or undocumented. slack_get_channel_history accepts 'limit' but no 'offset' or 'cursor'. esa_list_posts and esa_get_members accept 'page' and 'per_page' but no documentation of total count, next_page indicator, or when iteration is complete.
Parameter type confusion. slack_get_user_profile accepts 'user_id or username' but parameter is named 'user_id' (implies ID only). slack_get_channel_history accepts 'channel_id or channel name' but similarly named 'channel_id'. This violates the naming rubric guideline to use separate parameters (user_id, user_name) or clarify the parameter accepts multiple types.
Several tools located in 'archive/deprecated' directory (slack_get_channel_history, slack_get_user_profile, slack_get_users), code rot risk. Unclear which version is canonical, and deprecated code may not be maintained.
Tools do not document required permissions or scopes (e.g., Slack bot needs 'channels:read', 'users:read'; esa API needs API token with appropriate team access). No guidance on how to authenticate or what credentials are required.
Tool descriptions are often below the 10-1024 character baseline. slack_get_user_profile (16 chars), slack_list_channels description, and esa_get_post (17 chars) are too brief to provide LLM context for proper tool selection.
slack_get_user_profileesa_get_post
Clarify parameter naming when a single parameter accepts multiple types. Either split into separate parameters (user_id vs user_name, channel_id vs channel_name) or rename to reflect this (e.g., user_or_id, channel_identifier). Add explicit guidance: 'Pass either a Slack user ID (starts with U) or a username; the tool resolves it internally.'
Consolidate tools from deprecated and src directories. Remove or archive deprecated versions; maintain a single canonical implementation per tool. Document the version used by the MCP server.
Add scope/permission declarations. Each tool should state required OAuth scopes or API permissions. E.g., slack_post_message requires 'chat:write'; esa_create_post requires 'write:posts' on the team. This enables least-privilege configuration and audit trails.
Add per-item result status for batch-like operations. If slack_list_channels returns multiple channels, include success/error status per channel in the response to enable partial failure recovery.
Provide result limits and explain them. E.g., slack_list_channels: 'Returns up to 100 channels per page. Use pagination to retrieve more. For very large workspaces, consider filtering by category or archived status to reduce result size.' This prevents context window exhaustion.
Document the relationship between request parameters and response fields to enable tool chaining. E.g., if slack_get_channel_history returns a list of messages with user_id fields, slack_get_user_profile should accept those user_ids directly for follow-up lookup.