Skip to main content
Glama
antideploy

antideploy-mcp

Official
by antideploy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Let the application send email now

email_create

Provisions a working transactional email setup (like password resets) for the project, so the sending path is built and tested against a live relay without your own Resend account.

Instructions

Let this application send email now, while the project is still being written, so a welcome or a password reset is built and tested against the real thing instead of being left out or sending the user to open a Resend account and verify a domain. There is nothing to sign up for. Safe to call twice. Only for a project that sends mail: skip it otherwise, and skip it when the project already sets a RESEND_API_KEY of its own (409 own_email). A 503 email_unavailable means email is not set up on this server: carry on without it and tell the user. If the call is refused or blocked, do not look for another route: tell the user. The token is not returned: call email_env_to_file to put the variables in .env. Send with the resend package written as for any Resend account: new Resend(process.env.RESEND_API_KEY), then resend.emails.send({ from: process.env.EMAIL_FROM, to, subject, html }); in Python resend.api_key = os.environ['RESEND_API_KEY']. The package reads RESEND_BASE_URL or RESEND_API_URL, which point at the platform's relay. The message always leaves from the application's own address under the platform's sending domain, whatever from says, with the application's name as the display name, and nothing receives replies at that address, so set reply_to (replyTo in Node) to a real one if people may answer. It is transactional mail: at most five addresses on a message, a limited number a day by the owner's plan (fewer for an account only days old), and a 429 with daily_quota_exceeded or rate_limit_exceeded means try later, so show a person a message and do not retry in a loop. Attachments, scheduled sending, templates and resend.batch.send are refused. Never use it for newsletters or bulk mail. Tell the user what was set up and on which account.

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses many operational details beyond the annotations: the call is safe to call twice, credentials are not returned, errors have specific meanings, and refused/blocked calls should not be retried through another route. It also explains sending behavior, reply-to handling, relay configuration, quotas, rate limits, and refused features such as attachments, scheduling, templates, and batch sends. This gives the agent a rich and accurate behavioral picture.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The most important information is front-loaded: what the tool does, when to use it, and when to skip it. The remainder is long but largely earns its space with concrete setup, error, sending, and quota details. Some sentences could be tightened, but the structure remains purposeful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter setup tool with no output schema, the description covers the practical lifecycle an agent needs: when to call it, what it does, how to retrieve the resulting token, what sending behavior to expect, and how to handle errors or refusals. The annotations cover safety flags, and the description complements them with the operational context an agent would otherwise lack.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no input parameters, so schema-level parameter semantics are not a concern. The baseline for a zero-parameter tool is 4, and the description does not need to explain parameter meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that this tool enables the application to send email through the platform, using a real setup rather than a user-owned Resend account. It distinguishes this setup action from related tools by referencing `email_env_to_file` for retrieving credentials and by describing the `own_email` conflict case. The phrasing is narrative rather than a crisp verb-resource statement, but the purpose is still unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit inclusion and exclusion criteria: use only for projects that send mail, skip if the project already sets its own `RESEND_API_KEY`, and skip if email is not needed. It also explains what to do on `409 own_email`, `503 email_unavailable`, refusal, or blocking, and points to `email_env_to_file` for the token. This is strong when-to-use and when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools