Email API + newsletters. 17 MCP tools. OAuth 2.1 PKCE or API key. EU-hosted (Hetzner + SES).
Scored across 17 tools
Each tool targets a distinct resource-action, and the descriptions proactively draw the boundaries between easily confused pairs: erase_subscriber vs remove_subscriber, add_suppression vs remove_subscriber, and add_subscriber vs tag_subscriber. An agent can confidently pick the right tool for each intent.
Consistent snake_case verb_noun pattern throughout (add_*, create_*, get_*, list_*, send_*, remove_*, erase_*, update_*, tag_*, preview_*). The verbs map predictably to read/write/lifecycle actions with no stylistic mixing.
17 tools is slightly heavy but each one covers a real operation for a mail-marketing domain (campaigns, subscribers, suppression, tags, transactional email, account). Nothing feels like a filler tool, though the set could be marginally tighter.
Strong coverage of the core lifecycle: campaign create/update/send/stats/list, subscriber add/remove/erase/list/tag, suppression add/list, transactional send and status, account info. Minor gaps remain (no single-campaign get, no delete_campaign, no tag deletion), but agents can work around them.
Adds or updates a subscriber. By default the person enters as PENDING and receives a confirmation email: that is double opt-in, and it protects the workspace's sending reputation. double_opt_in: false subscribes directly and must only be used when consent was already collected elsewhere — never on your own initiative. A suppressed or unsubscribed address is refused. An address gets at most one confirmation every 2 minutes and 3 per 24 hours: do not retry in a loop, read confirmation_not_sent_reason and confirmation_retry_at in the response.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | ||
| Yes | |||
| lastName | No | ||
| firstName | No | ||
| double_opt_in | No | false = direct subscription without confirmation. Only request this on explicit instruction from the person. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: PENDING state on entry, a confirmation email, the sending-reputation rationale, refusal of suppressed/unsubscribed addresses, hard rate limits (1 per 2 minutes, 3 per 24 hours) with an explicit anti-retry-loop warning, and named response fields to inspect. Nothing here is derivable from readOnlyHint/destructiveHint/idempotentHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tightly packed sentences, each carrying unique load — default behavior, the exception and its guardrail, the failure mode, and the rate limit with the remediation pointer. The critical constraint and the alternative are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation with no output schema, the description supplies what an agent actually needs: success state (PENDING), side effects (confirmation email), failure mode (suppressed/unsubscribed refused), throttling behavior, and the exact response fields to read instead of looping. No material gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 20%, so the description carries most of the burden. It does substantively enrich double_opt_in (adding the consent-sourcing rule and the 'never on your own initiative' constraint beyond the schema text), but tags, firstName, and lastName are never mentioned in either place. Partial compensation only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource ('Adds or updates a subscriber') and immediately clarifies the upsert semantics, which is exactly what distinguishes it from remove_subscriber, erase_subscriber, and list_subscribers. An agent can route to this tool without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use for the risky parameter: double_opt_in defaults to the safe double opt-in path, and `false` is only permitted when consent was collected elsewhere, with a direct prohibition ('never on your own initiative'). It also states the refusal case (suppressed/unsubscribed addresses), covering when the call will not succeed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Adds an address to the workspace's suppression list. By default (manual), it will receive nothing further, neither campaigns nor individual emails; with unsubscribe, only campaigns, automations, and sends carrying unsubscribe_url are refused to it. Use when someone requests no further contact outside the unsubscribe link.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | |||
| reason | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is covered structurally. The description earns credit by adding domain semantics the annotations cannot convey: the two suppression modes and exactly what traffic each blocks (campaigns, automations, unsubscribe_url sends). It omits reversibility and repeat-call behavior, which would have pushed it higher.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences with no filler; the default behavior and the contrast mode are front-loaded before the usage cue. Slightly packed with parenthetical asides, but each clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive two-parameter mutation with no output schema, the description covers purpose, modes, and usage trigger adequately. Remaining gaps are the undefined bounce/complaint reasons and whether re-suppressing an existing address behaves idempotently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry parameter meaning. It explains the `manual` default and the `unsubscribe` semantics well, but leaves the `bounce` and `complaint` enum values entirely undefined, so half the reason enum remains opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Adds an address to the workspace's suppression list') and immediately distinguishes two operational modes (manual vs unsubscribe). An agent can tell this apart from siblings like add_subscriber or list_suppression without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names the trigger condition: 'Use when someone requests no further contact outside the unsubscribe link.' That is a clear when-to-use signal, though it does not name a concrete alternative tool for in-scope unsubscribe cases, leaving that inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a DRAFT. Nothing is sent: you then need to call send_campaign, or send it from the Mailcheer workspace. Content is written in plain text in text — a blank line separates paragraphs, "#" at the start of a line makes a heading. Always have the draft reviewed before sending.
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Address of an already-registered sender. Defaults to the workspace sender. | |
| kind | No | newsletter, offer, announcement… newsletter by default. | |
| name | Yes | Internal name, visible only in the workspace. | |
| text | No | Plain-text content. | |
| subject | No | Subject line seen by recipients. | |
| preheader | No | Preview text shown after the subject in the inbox. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the safety profile is partly covered. The description adds real value beyond that: it guarantees nothing is sent, identifies send_campaign as the required follow-up, and documents the plain-text markup convention for `text`.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with the most consequential fact ('Creates a DRAFT. Nothing is sent') front-loaded, followed by the required next step and the content-format rule. No sentence is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description still orients the agent on lifecycle (draft, then send) and content format. It omits anything about the returned result (e.g., a campaign identifier needed for the subsequent send_campaign call), which is the main remaining gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description goes further by explaining the markup semantics of `text` (blank line separates paragraphs, leading '#' makes a heading) — syntax the schema does not capture. The other five parameters are left to their schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence gives a precise verb+resource ('Creates a DRAFT') and immediately scopes it against the sending action, distinguishing it from send_campaign. An agent can tell this is the authoring step, not the delivery step, without inspecting either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states the follow-on action ('you then need to call send_campaign, or send it from the Mailcheer workspace') and adds a review prerequisite. It does not, however, address when to use this versus update_campaign for editing an existing draft, so the routing is strong but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Erases a person from the workspace at THEIR request (right to erasure): record, name, fields, proof of consent, tags. Statistics of campaigns already sent do not move; the suppression list is not touched. To stop someone receiving anything, use remove_subscriber — not this one. IRREVERSIBLE: only use it on the explicit request of the person concerned, relayed by the user.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and non-idempotent, but the description goes further: it enumerates exactly what is destroyed (record, name, fields, proof of consent, tags), what is preserved (campaign statistics, suppression list), and flags IRREVERSIBLE with the consent precondition. This is precisely the extra context annotations cannot carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences, front-loaded with the erasure scope, then the preserved-data boundaries, then the alternative and the irreversibility warning. Every clause carries actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter destructive tool with no output schema, the description covers scope, side effects, preconditions, and the routing alternative. An agent has everything needed to call it correctly and safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and there is one required parameter (email), which the description never describes. The parameter name is self-evident, so no real ambiguity results, but the description adds no semantics such as exact-match requirements or behavior when the email is not found.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (erases) and resource (a person from the workspace) and frames it as a GDPR right-to-erasure operation, which separates it cleanly from generic subscriber deletion. It also explicitly names the sibling it is not (remove_subscriber).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit when-to-use condition ('only use it on the explicit request of the person concerned, relayed by the user'), an explicit when-not ('To stop someone receiving anything, use remove_subscriber — not this one'), and names the alternative. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the workspace this key grants access to, its scopes, plan, remaining emails this month (queued sends included), when the counter resets, billing status, member and domain limits, sending domains (verified or not) and registered senders. Call this FIRST: it tells you which address to send from before attempting anything.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds genuine behavioral context beyond that: the result is scoped by the calling key's grants, includes queued sends in the quota counter, and reveals counter-reset and billing state. It stops short of describing refresh timing or caching, so it is not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with what is returned and closed with the imperative to call it first. The field enumeration is long but each item is decision-relevant (sending domains verified-or-not, remaining quota). Slightly dense, but no filler sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description carries the full burden of explaining return values — and it does: it lists the workspace, scopes, plan, quota, reset time, billing, limits, domains, and senders. For a zero-argument, read-only tool that is sufficient for an agent to decide to call it and interpret the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so per the baseline rule a score of 4 applies — there is nothing for the schema to document and nothing for the description to compensate for. The description correctly implies no input is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (returns the workspace/account this key grants access to) and then enumerates the exact fields returned — scopes, plan, remaining emails, reset timing, billing status, limits, sending domains, senders. This clearly distinguishes it from every sibling tool, which all act on campaigns, subscribers, suppression lists, or emails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Call this FIRST: it tells you which address to send from before attempting anything' gives explicit ordering guidance and the purpose that ordering serves (resolving the sending address). It does not name alternatives or when-not conditions, but for a no-argument discovery tool there is no competing sibling, so the omission is minor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Status and figures for a campaign: recipients, sent, delivered, opened, clicked, bounced, complained. Rates are calculated on delivered messages, not on recipients. Every rate comes twice: open_rate and click_rate include bots (security gateways, preloads), human_open_rate and human_click_rate set them aside — that is the figure to give the person when they ask how many read it.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the safe read-only, idempotent profile, and the description adds substantive non-obvious semantics: rates are computed on delivered messages rather than recipients, and bot traffic inflates open_rate/click_rate versus the human_* variants. That is genuinely useful context an agent would otherwise get wrong, though it says nothing about freshness, caching, or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three front-loaded sentences: the returned metrics first, then the rate denominator, then the bot/human distinction. Each sentence carries distinct information, though the final clause is dense and could be split for scanability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must describe the return payload, and it does so well by listing fields and explaining how rates are derived. The main omissions are the meaning/source of the id argument and any note on data freshness, which matter for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one required parameter with 0% schema description coverage, so the description carries the burden. 'For a campaign' makes it inferable that id is a campaign identifier, but the description never states the expected format or points to list_campaigns as the source of the id, leaving a real gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource ('Status and figures for a campaign') and enumerates the exact metrics returned, so an agent knows precisely what it gets back. It doesn't explicitly name the sibling it differs from (list_campaigns for discovery, send_campaign for sending), so differentiation is implied rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: fetch stats for a known campaign id, and the description gives clear interpretive guidance on which rate to report ('human_open_rate... is the figure to give the person when they ask how many read it'). However, it never says when to call this versus list_campaigns or how to obtain the required id, so tool-selection guidance is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Status of an email sent via send_email: sent, delivered, bounced, or complained. Amazon's delivery callback arrives a few seconds to a few minutes after sending — a "sent" status right after the call is normal.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, non-open-world behavior, so the safety profile is covered. The description adds genuinely useful non-obvious behavior: Amazon's delivery callback lags by seconds to minutes, so a stale "sent" is expected. It does not cover auth requirements or error behavior for unknown ids.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: the first defines the resource and return values, the second supplies the timing caveat. No filler, and the core purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, read-only tool with no output schema, the description usefully enumerates the status values and timing behavior. It is nearly complete; only error/unknown-id behavior is unaddressed, which is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single id parameter, so the description must carry the burden. It implies the id identifies an email previously sent via send_email but never explicitly states that the parameter is the message identifier returned by that call, leaving a small inference gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb+resource (status of an email sent via send_email) and enumerates the possible outcomes (sent, delivered, bounced, complained), immediately disambiguating the generic name get_email from sibling tools like send_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly situates the tool in a workflow — call it after send_email to check delivery outcome — and pre-empts a common misuse (treating an immediate "sent" status as a problem). It stops short of stating explicit exclusions or naming alternative siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The workspace's campaigns, from newest to oldest, with their status: draft, scheduled, sending, or sent.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No | ||
| status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds ordering and the set of possible status values, which is useful context, but says nothing about pagination behavior despite limit/cursor parameters existing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no wasted words; ordering and status values are delivered immediately. It is efficient though quite terse for a cursor-paginated list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a listing tool with no output schema, the description covers ordering and status values but leaves pagination (limit/cursor) and the shape of returned campaigns undocumented. An agent can call it, but not confidently page through results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all three params. It helpfully enumerates the status values (draft, scheduled, sending, sent), which gives meaning to the status filter, but limit and cursor are entirely unexplained – no pagination semantics at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('The workspace's campaigns') plus ordering ('newest to oldest'), which clearly distinguishes it from siblings like create_campaign, get_campaign_stats, or send_campaign. However it doesn't explicitly name a sibling it is the alternative to, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No indication of when to use this list versus preview_campaign_send, get_campaign_stats, or get_account. There are no prerequisites, exclusions, or alternative-routing guidance of any kind.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the workspace's subscribers, page by page. Use cursor with the next_cursor value from the response to get the next page. status filters on subscribed, pending, unsubscribed, bounced, or complained.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Search by address or name. | |
| limit | No | 1 to 100, 50 by default. | |
| cursor | No | Next-page cursor. | |
| status | No | ||
| updated_since | No | ISO 8601 date: only the records created or changed since then (status, name, fields, tags). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds behavior beyond them by disclosing that the response carries a `next_cursor` and that results are returned page by page, which is exactly the kind of runtime context the agent needs for pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the core action, then pagination mechanics, then the filter enumeration. Every sentence carries information not already present in structured fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a five-parameter, read-only list tool with no output schema, the description covers the essentials: scope, pagination loop, and filter values. It omits any mention of return fields or ordering, but that is a minor gap given the annotations already establish the safe read profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80%, so most parameters are documented already, but the description adds real value the schema lacks: the five allowed `status` values (subscribed, pending, unsubscribed, bounced, complained) appear only here, since the schema's `status` has no description and no enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Lists the workspace's subscribers') and adds the paginated nature of the operation. It does not explicitly contrast itself with sibling list tools such as list_suppression or list_tags, but the resource name is unambiguous enough to select it correctly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete operating guidance: use `cursor` with the `next_cursor` value from the response for the next page, and what values `status` filters on. It conveys clear context for how to drive the tool but never states when to prefer it over an alternative (e.g. a search-oriented sibling) or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Suppressed addresses, with their reason: bounced, complained or manually suppressed (nothing goes to them), or unsubscribed (no more campaigns, automations, or sends carrying unsubscribe_url, but an individual email still reaches them). The scope field tells whether the address is suppressed for this workspace only or for the entire platform. No tool removes an address from this list: that action is done manually in the Mailcheer workspace, because it is the one that can suspend a sending capability.
| Name | Required | Description | Default |
|---|---|---|---|
| No | Look up a specific address. | ||
| limit | No | ||
| cursor | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, idempotentHint, etc., but the description adds valuable behavioral context: the different suppression reasons and their effects ('nothing goes to them' vs 'unsubscribed but individual email still reaches them'), the meaning of the 'scope' field, and the crucial note that no tool can remove an address (manual action required). This goes well beyond annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense paragraph that front-loads the core purpose and then adds necessary nuances. It's not overlong but could be slightly tightened. Every sentence adds value: reasons, scope field, and removal caveat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description must explain return content. It does explain the reasons and the scope field, which is likely part of the return. However, it doesn't describe pagination behavior (limit/cursor) or the exact return structure. Still, for a read-only list tool, this is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 33% (only email has a description). The description doesn't detail parameters, but it explains the 'scope' field semantically, which is not a parameter but a return field. For the parameters, there's no added meaning beyond the schema's 'email' description. However, the baseline for 33% coverage would be lower; the description compensates somewhat with domain context. Given the schema does document email and the other two are standard pagination, a 4 is fair.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists suppressed addresses with their reasons. It distinguishes itself from siblings like add_subscriber or erase_subscriber by describing the suppression domain, but doesn't explicitly contrast with add_suppression or mention that no sibling provides the opposite removal action. Still, the verb+resource is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes what the tool returns and notes that removal is a manual action in the Mailcheer workspace, not via any tool. This implies appropriate usage (read-only list) and warns against expecting a removal tool. However, it doesn't state when an agent should use this versus list_subscribers or other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The workspace's tags, with how many subscribers carry each one (subscribers) and, among them, the active ones (subscribed). Read this before tagging: reuse an existing name rather than creating a near-duplicate.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered structurally. The description adds value the annotations cannot: it documents the returned fields (`subscribers` count and the active `subscribed` subset), which matters because there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero filler: the first delivers what the tool returns, the second delivers the decision rule for using it. The most actionable content (reuse before creating) is placed at the end where it lands as a directive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, non-destructive list tool the description covers the resource, the shape of the result, and the reason to call it. With no output schema present, explaining the returned counts is exactly the missing piece an agent would otherwise lack.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4. Nothing in the description misdescribes inputs, and the field names referenced (`subscribers`, `subscribed`) describe output rather than inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource ('the workspace's tags') and specifies exactly what each entry carries (`subscribers` and `subscribed`), so the agent knows what a call returns. It does not explicitly contrast with the sibling `tag_subscriber`, but the listing purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Read this before tagging: reuse an existing name rather than creating a near-duplicate' gives a clear precondition that selects this tool before write-side tagging. It stops short of naming the alternative tool (`tag_subscriber`) or stating when not to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only: nothing is sent. Returns exactly what send_campaign would do right now — would it go out (and if not, why), and how many people would receive it. With to, reports address by address who is kept and who is excluded, with the reason (unsubscribed, bounced, complained, not in the list…). If the monthly quota is not enough, would_send is false, blocked_code is quota_exceeded and blocked_details gives the figures and the reset date. Call it BEFORE send_campaign, and give that number to the person when you ask them to confirm.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Campaign identifier. | |
| to | No | Optional. The addresses to restrict the send to. Omitted = the campaign's whole audience. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), and the description reinforces 'nothing is sent' while adding real behavioral detail: the would_send/blocked_code/blocked_details contract and the quota_exceeded case with reset date. It does not mention rate limits or cost, so it stops short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the most important reassurance ('Read-only: nothing is sent') and structured around would-send, exclusions, and quota. The final sentence is more instructional than definitional, but it still earns its place by shaping correct usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must carry return-value meaning, and it does so for the key fields (would_send, blocked_code, blocked_details). It does not enumerate the per-address exclusion reason vocabulary exhaustively, but gives representative examples.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds meaning beyond the schema: with `to` it reports address-by-address who is kept or excluded and why, whereas omitting it evaluates the whole audience. That is a semantic payoff not present in the schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb+resource (preview a campaign send) and immediately scopes it: 'Returns exactly what send_campaign would do right now.' It is unambiguously distinct from the sibling send_campaign and from read tools like get_campaign_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit routing: 'Call it BEFORE send_campaign, and give that number to the person when you ask them to confirm.' It states both the sequencing relative to the alternative tool and the intended workflow, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unsubscribes an address and adds it to the workspace's suppression list: no more campaigns, automations, or sends carrying unsubscribe_url. The record is not deleted — that is what prevents the address from coming back on the next file import. This action cannot be reversed via the API: only the person can re-subscribe.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations (destructiveHint=true, idempotentHint=false): it discloses the suppression-list side effect, the channels affected, that the record persists rather than being deleted, and that the change cannot be reversed via the API. That irreversibility and the persistence detail are exactly the behavioral facts an agent needs before calling a destructive tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, each carrying distinct information — effect, persistence rationale, irreversibility — with the primary action front-loaded and no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter destructive mutation with no output schema, the description supplies the side effects, irreversibility, and the deletion distinction that the annotations alone do not convey. Nothing material is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the single `email` parameter is undocumented in the schema; the description only obliquely refers to 'an address', adding no format, validation, or source guidance. With one obvious parameter this is not fatal, but the description does not compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (unsubscribes) plus the exact resource behavior (adds the address to the workspace suppression list) and names the downstream effect (no more campaigns, automations, or sends). It is clearly distinguishable from siblings like erase_subscriber and add_suppression because it explains the suppression-record mechanic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context for when this is the right call ('record is not deleted — that is what prevents the address from coming back on the next file import'), which implicitly steers the agent away from erase_subscriber. It stops short of explicitly naming the alternative tool or stating when-not-to-use, so it is not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
⚠️ IRREVERSIBLE. Locks the recipient list and triggers sending to ALL active subscribers in the workspace — or, with to, only to the requested addresses that are active subscribers (never an unsubscribed or suppressed address). A sent email cannot be recalled. First call preview_campaign_send with the same parameters, then ask the person for explicit confirmation, telling them how many people will receive the message. Messages go out progressively; get_campaign_stats tracks progress.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Campaign identifier. | |
| to | No | Optional. Restricts the send to these addresses. An empty list sends to nobody (refused); for the whole list, omit the field. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond annotations: irreversible send, locks the recipient list, progressive delivery, no recall of sent email, and a human-confirmation requirement. It also clarifies filtering against active subscribers and suppression of unsubscribed/suppressed addresses, which annotations alone (destructiveHint=true) would not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Six compact sentences, front-loaded with the irreversible warning and the scope behavior, then the required preview/confirm workflow, then delivery/progress tracking. No redundant or filler clauses.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation with no output schema, the description covers the critical gaps: irreversibility, recipient-list locking, filtering semantics, pre-send preview, human confirmation, and progress tracking via get_campaign_stats. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is already 100%, so the baseline is 3. The description adds behavioral meaning: `to` restricts to active subscribers only, empty list is refused, and omit for the whole list. This goes beyond the schema's terse parameter text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('send a campaign') and immediately distinguishes scope: all active subscribers, or a restricted set via `to`. It also names the sibling preview_campaign_send for the pre-send step, so an agent can tell this apart from send_email and get_campaign_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use and a required pre-call workflow: 'First call preview_campaign_send with the same parameters, then ask the person for explicit confirmation'. Also states filtering behavior with the `to` parameter, leaving no inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sends a single (transactional) email to one or more addresses. The sender must belong to a verified domain of the workspace — call get_account to see which ones. An address suppressed for a bounce, a complaint or by hand fails the entire call, with its reason. An unsubscribed address still gets an individual email (a reply, an invoice, an appointment); a newsletter or a prospecting email must carry unsubscribe_url, and is then refused to an unsubscribed address. At most 50 addresses in all, to, cc and bcc together. Every address (to, cc, bcc) counts against the plan's monthly quota: past it, the call is refused (quota_exceeded) with the figures and the reset date — do not retry before that date. The email is sent immediately: this action cannot be undone.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient, or list of recipients. | |
| from | Yes | Sending address on a verified domain. "Name <address@domain.com>" format accepted. | |
| html | No | HTML body. | |
| text | No | Plain-text body. At least one of html or text is required. | |
| verify | No | Verify recipients before sending: an address that cannot receive mail refuses the call (`undeliverable_recipient`) instead of bouncing. Recommended for prospecting. | |
| replyTo | No | Reply-to address. | |
| subject | Yes | Message subject. | |
| unsubscribe_url | No | One-click unsubscribe https address. Required for a newsletter or a prospecting email: it makes the send refused to an unsubscribed address. Leave it out for an individual email. |
Adds (add) and removes (remove) tags on ONE existing subscriber, and nothing else: no subscription, no confirmation email, no status touched. Prefer it to add_subscriber for changing tags: add_subscriber is a subscription and sends the confirmation again to a pending person. An unknown address is not created (404). The response says what really changed (added, removed).
| Name | Required | Description | Default |
|---|---|---|---|
| add | No | ||
| Yes | |||
| remove | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that: it clarifies the side-effect boundary (no subscription/confirmation/status change), the 404 behavior, and the response content. It does not mention rate limits or auth, but the added context is substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and scope, followed by the sibling comparison and the failure/response notes. Dense and largely waste-free; the parenthetical 404 and response clause are compact. Slightly packed into one long sentence chain but no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description compensates by stating the response reports actual changes ('added', 'removed'). Combined with the scope boundary and 404 note, an agent has enough to invoke it correctly; only tag-identifier format remains unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, and it does: it explains that `add` and `remove` are the tag operations and that `email` targets 'ONE existing subscriber' (with 404 if unknown). It stops short of saying whether add/remove accept tag IDs vs names or how duplicates are handled, but it is far more than the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Adds and removes tags on ONE existing subscriber') and explicitly bounds the scope with 'and nothing else: no subscription, no confirmation email, no status touched.' An agent can distinguish this from add_subscriber or remove_subscriber without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent: 'Prefer it to add_subscriber for changing tags' and explains why (add_subscriber re-sends confirmation to a pending person). Also states the failure condition for unknown addresses (404). Both when-to-use and when-not-to-use are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edits a DRAFT: name, subject, preheader, kind, sender, content (text). Nothing is sent. Prefer it to create_campaign to rework a text: otherwise the old draft stays in the list. A scheduled, sending or sent campaign cannot be edited (409).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| from | No | ||
| kind | No | ||
| name | No | ||
| text | No | The new content, in plain text: it replaces the old one. | |
| subject | No | ||
| preheader | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavior: 'Nothing is sent', the state precondition on the target campaign, and the concrete 409 failure mode plus the list-pollution consequence of not using it. It stops short of noting auth/permission requirements, so not a full 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very dense and front-loaded: the resource scope leads, then the field list, then the alternative and the failure condition. Every clause earns its place, though the stacked constraints in one long sentence make it slightly harder to scan than an ideal definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter mutation tool with no output schema and low schema coverage, the description covers the critical unknowns: what is mutated, that nothing is dispatched, the allowed object state, and the alternative tool. Remaining gaps (unspecified fields are presumably left untouched, per idempotentHint) are minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 14% (just `text`), so the description carries real weight: it enumerates the editable fields and maps API fields to parameter names ('sender' -> `from`, 'content' -> `text`), which the bare schema does not. It does not describe formats or say anything about the required `id`, so it is helpful but not exhaustive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (edits), a specific resource and scope (a DRAFT campaign), and enumerates the editable fields. It is immediately distinguishable from create_campaign and send_campaign, so an agent can select it without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names the alternative ('Prefer it to create_campaign to rework a text') and the reason ('otherwise the old draft stays in the list'), and states a hard exclusion: scheduled/sending/sent campaigns cannot be edited and return 409. Both when-to-use and when-not-to-use are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Updates the first name (first_name), last name (last_name) and custom fields (fields, by technical key) of an existing subscriber. The email address cannot be changed: it is the identifier. Tags are managed with tag_subscriber. Unknown fields are rejected (400). The response contains the updated record and the fields keys that were ignored (ignored_fields).
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The subscriber's email address (identifier). | ||
| fields | No | Custom field values keyed by their technical key. | |
| last_name | No | ||
| first_name | No |
Verifies one or more addresses (up to 100) BEFORE writing to them, without sending anything: syntax, a domain that receives mail, a mailbox that already hard-bounced on Mailcheer, disposable or role mailboxes, and DNS signals of a dead mailbox. Each address gets a verdict: invalid (writing to it will bounce), risky (may bounce, or is not a person), unknown (DNS did not answer) or valid (nothing known against it — not a proof that the mailbox exists). Use it before prospecting, or before importing a list you did not collect yourself.
| Name | Required | Description | Default |
|---|---|---|---|
| emails | Yes | The addresses to verify (1 to 100). |
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
send_email1 field changedInput schema / properties / verifyAdded value: +{
+ "description": "Verify recipients before sending: an address that cannot receive mail refuses the call (`undeliverable_recipient`) instead of bouncing. Recommended for prospecting.",
+ "type": "boolean"
+}verify_emailupdate_subscribererase_subscriberlist_subscribers1 field changedInput schema / properties / updated_sinceAdded value: +{
+ "description": "ISO 8601 date: only the records created or changed since then (status, name, fields, tags).",
+ "type": "string"
+}list_tagstag_subscriberupdate_campaignsend_email1 field changedInput schema / properties / unsubscribe_urlAdded value: +{
+ "description": "One-click unsubscribe https address. Required for a newsletter or a prospecting email: it makes the send refused to an unsubscribed address. Leave it out for an individual email.",
+ "type": "string"
+}add_subscriberadd_suppressioncreate_campaignget_accountget_campaign_statsget_emaillist_campaignslist_subscriberslist_suppressionpreview_campaign_sendremove_subscribersend_campaignsend_emailOfficial remote MCP server of MailSenpai, the EU-hosted email marketing platform. Connect Claude, ChatGPT, Cursor or another MCP client to your account and ask in chat to create lists, find subscribers, prepare templates, create draft campaigns and read campaign stats. OAuth 2.1 with PKCE, no API keys. Sends and deletions need explicit confirmation; every call is logged.
Hosted email for AI agents: create inboxes, send, receive, and reply over MCP with scoped API keys
Hosted email MCP for your own Gmail, Outlook.com, Microsoft 365, iCloud or IMAP inbox: read, search, draft, reply in thread, forward and file mail. It moves or flags up to 500 messages in one call, and a send leaves exactly one copy in Sent. A calendar is a separate connection, and connecting one adds diary and scheduling tools.
Transactional e-mail and permission-based campaigns, multi-tenant, with a full audit trail.
Add one secure layer between your agents and this server.
