MessageGears API + MCP (2026): XML RPC, stale SDKs, zero MCP

MessageGears exposes a single public programmatic surface for message submission: the v3.1 Web Service at https://api.messagegears.net/3.1/WebService. It is not a REST API. It is an RPC-style endpoint that takes name/value pairs over HTTP, selects an operation through an Action parameter, and answers in XML. Credentials travel as query parameters, not as headers. There are five documented Actions, three official email SDKs whose most recent commit landed in 2017, and zero Model Context Protocol servers, official or community. This tab documents what is actually published, and is explicit about what is not.

At a glance

Read those three cells together and the shape of the integration job becomes clear. A buyer wiring MessageGears into an application in 2026 writes the HTTP client, the XML parser, the retry policy and the error taxonomy by hand, in whatever language the stack uses, because no maintained client library exists for it. That is a different starting position from Postmark or Resend, where a one-line package install and a typed client are the documented path. It is not automatically disqualifying: MessageGears sells a warehouse-native activation platform, not a developer-first sending API, and the SMTP relay covers a large share of real traffic, but it is a line item in the integration estimate that should not be discovered in week three.

MCP integration in 2026

The Model Context Protocol has become the default way agent frameworks reach a SaaS product without bespoke glue. For an email platform, an MCP server is what lets an assistant look up a send, draft a campaign, or check an account’s activity without someone hand-writing a tool wrapper first. Here is where MessageGears stands.

What the absence actually means

An MCP gap is not the same thing as an API gap. The v3.1 Web Service is live and documented; anything an agent needs to do can still be done by writing a tool definition around it. The cost is that every team does that work separately, and each team absorbs the same three problems: the XML response format has to be parsed into something a model can consume, the credentials have to be passed as query parameters rather than through a header that a standard HTTP tool layer would inject, and the surface is narrow enough that the tool set has to be built around five Actions rather than discovered from an OpenAPI description. None of that is exotic. All of it is unbudgeted if a team assumed parity with platforms that ship a server.

There is one genuine nuance worth stating precisely, because it is easy to overclaim in either direction. MessageGears operates a standard authenticated SMTP relay, with the Account ID as username and the API Key as password. Generic SMTP-speaking MCP servers exist, and a relay that speaks ordinary SMTP is, mechanically, something such a server could be pointed at. That is an inference from protocol standards, not a documented integration: MessageGears publishes nothing about MCP, endorses no generic server, and offers no guidance on which relay limitations would bite in that configuration. Given that the relay itself does not support attachments, CC or BCC, an agent routed through it inherits those constraints silently.

MessageGears Web Service v3.1 essentials

The v3.1 Web Service is a single endpoint. There are no resource paths, no HTTP verbs carrying semantics, and no status-code-driven error model in the REST sense. A caller posts a parameter set that includes Action, and the value of Action determines what happens. The response is XML validated against a published XSD, carrying at minimum a RequestId and a Result.

Two consequences follow from that table and both affect code that is written the way a modern API client is usually written. First, no JSON. Every integration needs an XML parser in the request path, and every log line, every replayed payload and every test fixture is XML. Second, the 2 MB POST ceiling is the only officially published size figure anywhere in the API documentation, and it applies to the whole request. For TransactionalJobSubmit that ceiling has to cover the recipient XML, the HTML template and the text template together, so a large inline template plus a long recipient block can approach it faster than intuition suggests.

Pagination is not documented anywhere in the v3.1 material. For AccountActivity in particular, which is the one Action that returns a variable-length result set, there is no published cursor parameter, page-size parameter or continuation token. Treat result-set size as an open question to raise with the vendor before designing a reporting job around it, rather than assuming the absence of documentation means the absence of a limit.

MessageGears also operates a modern documentation portal at messagegears.stoplight.io. It renders client-side and its endpoint inventory is not machine-extractable, so it is not treated as a source here. Anything published there but absent from the v3.1 support articles should be confirmed with the vendor in writing before it is built against.

Authentication

Authentication is a pair of credentials sent with every request. There is one scheme. There is no second one.

AccountId and ApiKey as request parameters

Every call carries AccountId and ApiKey as request parameters alongside Action and the operation’s own arguments. They are not headers. There is no Authorization header documented for the v3.1 Web Service, no bearer token, and no signed-request scheme. The same credential pair doubles as the SMTP relay login: Account ID as username, API Key as password.

No OAuth, no scopes, no per-key permissions

OAuth 2.0 is not offered. Neither is any documented notion of scoped keys, per-environment keys, read-only keys or key rotation tooling. That means one credential grants the full documented surface: submitting transactional mail, submitting bulk jobs, pulling account activity and rendering previews are all reachable with the same secret. Compare that with SendGrid or Mailgun, where scoped API keys are the normal way to keep a reporting service from holding send rights.

Rate limits

MessageGears publishes no rate limits for the v3.1 Web Service. Not a requests-per-second figure, not a requests-per-minute figure, not a daily quota, not a concurrency ceiling, not a documented 429-equivalent response or retry-after signal. This section deliberately carries no table, because a table here would have to be filled with invented numbers and there are none to report.

The same silence covers the SMTP relay: no published messages-per-hour figure, no recipients-per-message cap, no concurrent-connection limit, no maximum message size on the relay side. The only quantified limit in the entire public API documentation is the 2 MB POST payload ceiling, with the roughly 2 KB GET limit noted as a demonstration constraint rather than a production one.

Designing against an undocumented ceiling

An undocumented limit is not an absent limit. Every sending platform enforces something, whether it is published or not, and the practical difference is that an unpublished ceiling is discovered in production rather than designed around. Three habits keep that discovery cheap. Build the client with a configurable concurrency cap from day one, so throttling is a settings change rather than a refactor. Implement exponential backoff with jitter on every non-success result, including transport-level failures, rather than only on a status code the API may never return in the expected form. And instrument the submit path with latency and failure-rate metrics before the first production send, so a ceiling announces itself as a visible inflection rather than as a support ticket.

Then ask for the numbers in writing. MessageGears is sold through a quoted, account-managed motion with no self-service tier, which means there is an assigned contact who can put the applicable throughput figures in the contract or in an email. Getting them there is worth more than a public documentation page would be, because a contractual figure is enforceable and a documentation page is not. Buyers evaluating against Amazon SES, where the send rate and daily quota are visible in the console and adjustable by request, should recognise this as a structural difference in how the two products are operated rather than an oversight.

Official SDKs

MessageGears maintains a public GitHub organization with 4 repositories. Three are email SDKs. The fourth, ngx-material-timepicker, is an archived TypeScript UI component unrelated to email and is listed here only so nobody mistakes the repository count for SDK breadth.

What the SDK debt costs in practice

The Java SDK is the only one with a real distribution path, and even it predates most of the JVM ecosystem a team would be running today. A 2017 library brings a transitive dependency tree frozen at 2017, which is where the cost usually lands: not in the SDK’s own code, which is thin, but in the HTTP client, XML and logging libraries it pulls in, each of which has accumulated advisories since. Security scanning in any modern CI pipeline will flag that tree, and the remediation path is to exclude and override the transitives one at a time until the build is clean, at which point the team is maintaining a fork in all but name.

The C# packages are worse positioned, because there is nothing to install. Adoption means copying source into a solution and owning it outright, from a codebase last touched when the target framework and the language itself looked materially different. The C# AWS SDK, at 2012, is old enough that it is best read as a historical artifact of how the product integrated with AWS at the time.

For everything else, Python, Node, PHP, Ruby, Go, and by extension most of what new services are written in, there is no library at all and never was. The realistic plan for any of those stacks is a thin internal client of a few hundred lines: build the parameter map, POST it, parse the XML, map Result to a typed outcome, and wrap the whole thing in the retry policy described in the rate-limits section. That is genuinely a small amount of code. The point is that it is code a buyer owns, tests and maintains, and it should appear in the integration estimate rather than being assumed away.

Community SDKs

No maintained third-party client library for the MessageGears Web Service has surfaced in public package registries or on GitHub. Where platforms like Mailjet or Brevo have a long tail of volunteer wrappers that fill the gaps between official releases, MessageGears has none: a predictable consequence of an enterprise-only, quoted sales motion with no free tier for hobbyists to build against.

Documented Actions

There is no endpoint list in the REST sense, because there is one endpoint. What varies is the Action parameter. These five Actions are what the v3.1 documentation covers; no others are published, and none should be assumed to exist.

Compare that surface with what a modern transactional API exposes and the difference is not stylistic. There are no documented Actions for suppression-list management, webhook subscription management, template CRUD, domain authentication, or inbound message handling. Some of those capabilities exist inside the MessageGears product and are administered through the console or through the Support Team rather than through the API: domain authentication is the clearest case, since MessageGears publishes no self-service DNS values at all and routes that work through support. The practical read is that the API is a submission and reporting interface, not a platform-administration interface, and any automation plan that assumes account configuration can be driven programmatically needs to be checked Action by Action first.

Code examples

Submitting a transactional message

A production submission is a POST to the single Web Service endpoint carrying the parameter set below. Credentials are parameters, not headers, and the recipient block is XML nested inside a parameter value.

POST /3.1/WebService HTTP/1.1
Host: api.messagegears.net
Content-Type: application/x-www-form-urlencoded

Action=TransactionalJobSubmit
&AccountId=YOUR_ACCOUNT_ID
&ApiKey=YOUR_API_KEY
&FromAddress=no-reply@example.com
&SubjectLine=Your%20receipt
&RecipientXml=<Recipient><EmailAddress>customer@example.com</EmailAddress></Recipient>
&HtmlTemplate=<html><body><p>Thanks for your order.</p></body></html>

The XML response

A successful submission returns the following document. Result is the field to branch on; RequestId is what to log and what to quote in a support ticket.

<TransactionalJobSubmitResponse>
  <RequestId>t23110-a9e77b7c-c980-4ff5-8ede-546fbe0bad66</RequestId>
  <Result>REQUEST_SUCCESSFUL</Result>
</TransactionalJobSubmitResponse>

The failure case substitutes REQUEST_FAILED for REQUEST_SUCCESSFUL. Note what that implies for error handling: the transport can return a perfectly ordinary success at the HTTP layer while the body reports a failed request. Any client that branches on the HTTP status alone will silently record failures as sends. Parse the body, every time, on every call.

Java SDK usage as documented

The Java SDK README configures a client from a properties object and sets the same two credentials the raw API uses. It is shown here because it is the only official code sample with a package behind it, and because the 2017 caveat from the SDK section applies to every line of it.

// Java SDK, last updated October 3, 2017.
// Reference only: verify the dependency tree before shipping.
MessageGearsProperties properties = new MessageGearsProperties();
properties.setMyMessageGearsAccountId("YOUR_ACCOUNT_ID");
properties.setMyMessageGearsApiKey("YOUR_API_KEY");

MessageGearsClient client = new MessageGearsClient(properties);

Common gotchas

Deprecations and changelog

MessageGears does not publish a versioned API changelog. The dated events below come from vendor release notes, news posts and public repository history, and they are the ones with a bearing on the programmatic surface.

• 2026, release 26.3.2: External campaign APIs, described as programmatic composition and launch of campaigns through workflows, plus Push to Inbox improvements with preview. The exact release day is not published, and no endpoint specification accompanies the note. Source: MessageGears release notes.
• June 2, 2026: Integration ecosystem expansion: Microsoft Azure, SingleStore and Bynder added as data sources; TikTok and Google Drive added as destinations.
• January 12, 2023: MessageGears acquires Swrve, adding mobile push, in-app and embedded content channels, following a $62 million growth round.
• October 3, 2017: Final update to the official Java SDK, the newest of the three email SDKs.
• February 24, 2016: Final update to the official C# SDK. The C# AWS SDK had already stopped at August 31, 2012.

The shape of that list is itself the finding. The two most recent entries are ecosystem and campaign-tooling announcements aimed at the marketing buyer; the three before them are the dates on which developer tooling stopped being maintained. Nothing published since 2017 has improved the position of a developer integrating against the Web Service directly.

Frequently asked questions