Related Servers

Multiple tools have overlapping or identical purposes (e.g., send_email vs send_mail_v2, stop_list_export_delete vs api_delete_v2_stop_list_export_token, api_post_v2_tickets vs api_post_v2_tickets_ip). The presence of both SDK-parity and raw API wrapper functions creates redundant paths for the same operation, making it very difficult for an agent to determine which tool to use.

The naming is a mix of descriptive snake_case (get_delivery_status), versioned names (send_mail_v2), and raw API-style names with HTTP verbs and version prefixes (api_get_v2_tickets_id). There is no consistent verb_noun pattern; the api_* group breaks the otherwise somewhat consistent snake_case convention, and versioning is applied haphazardly.

With 58 tools, this server is severely overloaded. The count includes many redundant wrappers, meta-tools for documentation (list_endpoints, get_endpoint, search_docs), and near-duplicates of the same endpoint. This far exceeds a usable tool surface for an email delivery API, overwhelming agents with unnecessary choices.

The tool set covers a wide range of the email API domain: sending (email, packages), delivery status, stop-list management, reports, tickets, domain whitelist, IP info, and email validation. While there are some potential gaps (e.g., missing update for packages, no bulk update operations), the core lifecycle is well represented and an agent can accomplish most tasks without hitting dead ends.