Skip to main content
Glama

Opus Growth, Ad Platforms MCP Connector

Set Up Site Contact-Form Email

configure_site_smtp
Destructive

Sets up a CONTACT FORM → EMAIL relay for the user's hosted (static) site using the user's OWN Gmail or Yandex — with NO third-party dashboard: the user configures everything here, in chat. A static page can't speak SMTP itself, so its form POSTs to our thin relay and we forward the message through the user's own Gmail/Yandex (Gmail/Yandex does the actual sending). The site OWNER sets BOTH the sender (from_email) and recipient (to_email); the visitor filling the form cannot change them (so it can't be abused as an open relay). provider: 'yandex' (smtp.yandex.com:465) | 'gmail' (smtp.gmail.com:465 — requires a Google APP PASSWORD, not the normal password) | 'other' (give smtp_host + smtp_port). from_email must be the SMTP account (or a verified alias) or Gmail/Yandex rejects the send. By default sends a TEST email to to_email to verify the credentials and reports the result. Returns the form endpoint URL + a ready-to-paste HTML snippet (with honeypot). Re-running reconfigures the same server's form. The SMTP password is stored encrypted; only the site owner's fixed to_email ever receives mail.

READ-ONLY STATUS: call with only server (no smtp_user / smtp_pass / to_email) to see whether that site's form is already set up, its endpoint URL and the field contract, without entering any password. A new site has no endpoint yet — it is created on the first real setup, so build the form with the action in one place and fill it in after setup.

Field contract of the endpoint: POST as a normal HTML form (form-urlencoded or multipart; JSON is not read). Every field whose name does not start with "_" is forwarded in the e-mail; email becomes Reply-To, subject sets the subject line. _gotcha is the hidden honeypot (filled = silently dropped). _redirect = an absolute https URL to send the visitor to after sending, with ?sent=1 or ?sent=0 appended; without it a small thank-you page is shown (HTTP 200, 502 if the mail account refused). No CORS headers are sent, so use a plain form submit (or fetch with mode:"no-cors", where the reply cannot be read). Limit: 20 submissions per hour per form (HTTP 429); a GET on the endpoint answers 404/405 by design.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
serverNo
subjectNo
providerNoyandex
to_emailNo
send_testNo
smtp_hostNo
smtp_passNo
smtp_portNo
smtp_userNo
from_emailNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added
  2. Removed
  3. Added
  4. Removed
  5. Added
  6. Removed
  7. Added
  8. Removed
  9. Added
  10. Removed
  11. Added
  12. Removed
  13. Added
  14. Removed
  15. Added
  16. Removed
  17. Added
  18. Removed
  19. Added
  20. Removed
  21. Added
  22. Removed
  23. Added
  24. Removed
  25. Added
  26. Removed
  27. Added
  28. Removed
  29. Added
  30. Removed
  31. Added
  32. Removed
  33. Added
  34. Removed
  35. Added
  36. Removed
  37. Added
  38. Removed
  39. Added

TDQS

A4.6/5.0
Behavior5/5

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

Goes far beyond the annotations (destructiveHint=true, idempotentHint=false): password stored encrypted, only the owner's fixed to_email receives mail, honeypot anti-relay protection, default test email, 20/hour rate limit with 429, GET returns 404/405 by design, no JSON body accepted, no CORS headers, and 502 when the mail account refuses. Consistent with the destructive/idempotent hints (re-running reconfigures the same form).

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?

Long and dense, but the length is justified by a genuinely complex tool (10 params, relay semantics, endpoint field contract, rate limits). It is mostly front-loaded, though the endpoint-contract material is jumbled into the same paragraphs as the config guidance rather than separately structured.

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?

An output schema exists, so return values (endpoint URL + HTML snippet) need no further unpacking, and the description still delineates the endpoint field contract, redirect semantics, and failure modes. Nothing an agent needs to invoke this correctly is missing.

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?

With 0% schema coverage on 10 params, the description compensates well: provider values and ports ('yandex' smtp.yandex.com:465, 'gmail' requires an app password, 'other' needs smtp_host+smtp_port), from_email alias constraint, to_email as fixed recipient, send_test default, and the read-only trigger via smtp_user/smtp_pass. Minor gap: `subject` and `smtp_user` are not clearly explained as configuration parameters.

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

Purpose5/5

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

States a specific verb+resource (sets up a contact-form→email relay for the user's hosted static site) and makes the mechanism explicit (form POSTs to a thin relay forwarded through the user's own Gmail/Yandex). It is clearly distinguishable from siblings like wordpress_contact_forms and create_lead_form.

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

Usage Guidelines4/5

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

Gives explicit when-to-use modes: read-only mode ('call with only `server` ... to see whether that site's form is already set up') versus full setup, plus the static-site scoping that separates it from WordPress/CRM form tools. It stops short of naming a sibling alternative for non-static sites, so it falls just under a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.