Your agent sends invoices, password resets, or incident digests, and SMTP2GO is the delivery path. You go looking for an integration and find two first-party options: a remote MCP server documented under the AI section of SMTP2GO's developer docs, and the v3 REST API you have probably already called from a backend service.
They are not two views of the same thing. One hands your agent a live map of the API plus a generic request runner. The other hands it named actions with fixed schemas. That difference decides how much damage a confused model can do at 2am.
Both are maintained by SMTP2GO and both authenticate with the same credential. What differs is the shape of the surface your agent sees.
The official SMTP2GO MCP server is a remote Streamable HTTP endpoint that initializes as SMTP2GO-API-Docs. Clients such as Claude Code, Codex, Cursor, and Gemini CLI connect to it directly, with no local bridge process.
Four of its five tools are read-only and describe the API surface. The fifth, execute-request, performs real calls, including sending mail, from a HAR object carrying method, url, headers, query string, and body. SMTP2GO notes that the discovery tools may be reachable without authentication, while execute-request requires the key in the X-Smtp2go-Api-Key header. A standard Authorization: Bearer header also works, added so Claude Desktop connectors, which cannot send custom headers, can authenticate.
SMTP2GO's v3 REST API is JSON in, JSON out, with a global base URL that routes to the nearest of the US, EU, and AU endpoints. It covers sending (single, batch up to 1,000 messages, and raw MIME), activity search, delivery statistics, templates, suppressions, sender verification, webhooks, SMTP users, API keys, and subaccounts.
Authentication is an API key, passed either as an api_key body field or as the X-Smtp2go-Api-Key header. There is no OAuth flow and no user-level identity. Each key carries its own permitted endpoint list, its own optional rate limit, and a status of allowed, blocked, or sandbox. Parent accounts act on children by passing subaccount_id.
Four dimensions decide this for a production agent: what it can call, how it authenticates, what you maintain, and which workload each path fits.
Because execute-request is generic, there is no capability gap in the usual sense. The gap is granularity.
The same pattern holds for everything that mutates account state, with one row that behaves differently.
Read that last row against the first table. On the MCP path, sending an invoice and clearing a suppression entry are the same tool as far as your agent framework is concerned, so a tool allowlist cannot separate them.
Your only lever there is the key itself: SMTP2GO lets you restrict a key to specific endpoint paths, including wildcards such as /email/*, and set it to sandbox so nothing is delivered. That is real, and it is coarse. It lives in SMTP2GO's dashboard, not in your agent definition or your code review.
Most tools in this series diverge here, with MCP forcing OAuth and the API allowing keys. SMTP2GO does not diverge. Both paths carry the same 32-character key with an api- prefix, in a header or in the body.
One consequence is pleasant: headless and scheduled agents work on both paths with no browser consent step, which is what a delivery platform needs. One is not: an API key is an account credential, so nothing in either path records which end user triggered a send.
In a multi-tenant B2B agent, every customer brings their own SMTP2GO account and their own key. That is N credentials to store, rotate, and revoke.
MCP does not give you a vault. The REST API does not give you a vault. The credential layer is yours to build or to buy, and it is the same layer either way. Our write-up on access control for multi-tenant AI agents covers why this surfaces late rather than early.
The MCP server maintains the endpoint catalog for you. When SMTP2GO adds a parameter, get-endpoint reflects it with no release on your side. You own everything downstream: request construction, retries, pagination, and reading a 200 OK that still reports per-recipient failures.
The typed-tool path inverts that. Schemas are fixed and validated, so a malformed send fails before it reaches the wire, and tool names are stable enough to allowlist. In exchange, a new SMTP2GO capability is callable only once the tool exists.
The /activity/search endpoint is capped at 60 requests per minute. Sustained error responses can get your originating IP timed out for at least a minute, returning 429 Too Many Requests.
An agent that polls activity in a loop finds this quickly. Webhooks are the documented alternative for realtime data, and a per-key rate limit lets you cap one agent's send rate without changing the account default.
Reach for it when a human is in the loop and the endpoint list is still a question:
Reach for typed tools when the send is real and the action list needs to be reviewable:
The comparison above is about tool shape. The operating cost is about keys, and it is identical whichever path you pick.
SMTP2GO shows an API key exactly once, at creation. Navigate away and it is gone; you delete that key and make another. That single fact sets the contract for any system storing one: capture at creation, encrypt at rest, never log, and keep the value out of anything an LLM can read.
Then multiply by tenants. Fifty customers means fifty keys, fifty rotation schedules, and fifty revocation paths for the day a customer offboards. Once a credential string enters a context window, it can surface through a reasoning trace, a debug log, or a downstream tool's output. The challenge of credential ownership across agent tool-calling patterns becomes acute at this scale.
Scalekit ships SMTP2GO as two connectors: the SMTP2GO connector with 74 typed tools, and the SMTP2GO MCP connector wrapping the vendor server's five. Both are API Key connectors, so the vault, the tenant isolation, and the revocation path are the same whichever you choose.
Credentials never touch the agent runtime. Your code passes an identifier, and Scalekit resolves the connected account and injects the key server-side at request time.
Create the connection once per environment in the dashboard under AgentKit, Connections, then paste the SMTP2GO key. The connection name you choose is what your code references from here on.
Both SDKs read the same three values, found in the dashboard under Developers, API Credentials.
The agent does not load a connector catalog. It loads the tools the current identifier's connected account is authorized to call, which for a billing agent is a handful rather than 74.
Scope is a function of identity, not connector configuration. Two tenants calling the same agent resolve to two connected accounts, and therefore two SMTP2GO accounts, with no branch in your code.
The LangChain adapter returns that same scoped set as StructuredTool objects, so the model never sees a tool this tenant has no credential for. For a deeper look at how LangChain tool calling works and where it stops, see our dedicated guide.
When the sequence is fixed, skip the reasoning loop. execute_tool runs the named tool against the connected account and returns the result plus an execution ID you can store next to your own audit record.
Two schema details are worth knowing before the first call. SMTP2GO rejects a send unless at least one of html_body, text_body, or template_id is present, and the sender address must already be verified as a sender domain or a single sender email.
The MCP connector follows the vendor server's own two-step shape: search the spec, then execute. Note where the credential is not.
Compare the two blocks. The typed call declares an intent a reviewer can read. The HAR call declares a URL string the model composed.
Most email agents are not email-only. They read a ticket, look up a record, then send. That is where a single generic executor compounds.
A Virtual MCP server declares exactly which connections and which tools an agent role can see, then serves every tenant from one static endpoint. Identity arrives at runtime as a short-lived session token, minted per run, with a default expiry of about one hour.
Setup happens once per agent role. Runtime is a token mint. The endpoint is static; the identity is not.
A Gmail connection might surface 30 tools where a summarizer needs one. SMTP2GO's typed connector surfaces 74, and the destructive ones sit beside the routine ones: removing a suppression re-enables delivery to an address that already bounced, and removing an API key cuts off every integration still using it.
Context cost follows the same curve. At roughly 200 tokens per tool definition, a 40-tool surface burns about 8,000 tokens before the agent does any work, and scoping to five or ten cuts that by around 80 percent. The fix is not better prompting. It is surface reduction. More on the tradeoff is in our note on when to use a Virtual MCP server.
A shared key answers none of the questions an auditor asks after a bad send. Every message looks like it came from the account, because it did.
Scalekit records each tool call against the connected account that authorized it, so a send is attributable to a tenant and an identifier rather than to one shared credential, and execute_tool returns an execution ID you can carry into your own traces.
When a customer asks why their domain sent 4,000 messages on Tuesday, that record is the answer, and smtp2go_search_activity fills in what SMTP2GO saw at delivery time. The reasoning behind this model is in our post on agent tool observability.
If a developer is exploring SMTP2GO interactively, or you want new endpoints reachable the moment they ship, the official MCP server is the faster path, and its discovery tools are genuinely useful.
If the agent sends mail your customers receive, build against typed tools. A reviewable action list is worth more than a generic executor on the day a model improvises. Either way the key is the same key, and neither path stores, rotates, or revokes it for you; that is infrastructure, and it decides whether the agent survives its second tenant.
Understanding the broader agent tool calling auth patterns, problems, and anti-patterns will help you make the right call for your production system. AgentKit pricing is on the Scalekit pricing page, and the full catalog is at agent connectors.
Building an SMTP2GO agent and weighing these two paths against your own tenancy model? Join the Scalekit Slack community and ask, or book time through the Talk to us page if you need an answer today.
