This server connects AI assistants to SounnyForms, enabling zero-API-key form handling, lead delivery, and code generation.
Submit structured form data directly to any recipient email or form ID, with lead delivery to inbox and encrypted Cloud Firestore storage.
Generate production-ready form snippets for multiple frameworks (React, Next.js, HTML, Tailwind, Vue, curl, CDN) with optional custom fields and anti-spam protection.
Generate a complete standalone HTML/CSS contact page for a company or brand.
Check the health, latency, CORS, and readiness of the SounnyForms serverless backend.
Generates curl commands to submit form data directly to SounnyForms endpoints.
Generates Next.js Server Actions and form components for submitting leads to SounnyForms.
Generates production-ready React form hooks and components that submit inquiries to SounnyForms.
Generates Tailwind CSS-styled form components for use with SounnyForms.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@sounnyforms-mcp Generate a Tailwind contact form for client@example.com"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
The official Model Context Protocol (MCP) server for SounnyForms.
Connect autonomous AI agents, coding assistants (Claude Desktop, Cursor, Antigravity, Continue.dev, OpenAI Swarms), and LLMs directly to serverless form handling, real-time lead dispatch, and code generation with ZERO API keys required.
Zero API Key Required: Submit data or generate production form backends using only destination email addresses.
Instant In-House Email Delivery: Forwards leads directly to the client's inbox with proper Reply-To headers for 1-click responses.
Encrypted Vault Storage: Submissions are permanently saved to Cloud Firestore under the client's account.
Multi-Framework Code Generator: Generate drop-in React hooks, Next.js Server Actions, vanilla HTML, or Tailwind components.
Built-in Bot & Spam Defense: Automatic honeypot field injection and sub-second velocity timers.
Related MCP server: FormIO MCP Server
Add this to your claude_desktop_config.json:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
{
"mcpServers": {
"sounnyforms": {
"command": "npx",
"args": ["-y", "sounnyforms-mcp"]
}
}
}Add to your .cursor/mcp.json or in Cursor Settings > Features > MCP:
{
"mcpServers": {
"sounnyforms": {
"command": "npx",
"args": ["-y", "sounnyforms-mcp"]
}
}
}Add to your workspace or user mcp.json:
{
"mcpServers": {
"sounnyforms": {
"command": "npx",
"args": ["-y", "sounnyforms-mcp"]
}
}
}git clone https://github.com/sounny/sounnyforms-mcp.git
cd sounnyforms-mcp
npm install
node server.jssubmit_formSubmits structured data directly to any recipient email address or custom form ID. The submission is delivered to the recipient's inbox and logged in their dashboard.
Arguments:
recipient_email_or_form_id (string, required): The destination email address (e.g. client@example.com) or form ID.
name (string, required): Full name of submitter.
email (string, required): Submitter's email address for direct Reply-To.
message (string, required): Inquiry message or bug report.
extra_fields (object, optional): Custom key-value pairs (e.g. { "Budget": "$5,000", "Timeline": "Q3" }).
generate_form_snippetGenerates production-ready, copy-pasteable form code for any web framework.
Arguments:
recipient_email (string, required): The email address where form inquiries will be delivered.
format (string, required): "react" | "nextjs" | "html" | "tailwind" | "cdn" | "curl"
form_id (string, optional): Custom identifier for categorizing responses.
custom_fields (array of strings, optional): List of custom field names to include (e.g. ["phone", "company", "budget"]).
check_endpoint_healthPings the live SounnyForms serverless cluster to verify availability, latency, and SMTP gateway health.
Once configured, you can prompt your AI assistant naturally:
"Build a sleek Tailwind CSS contact form in Next.js that sends leads to client@agency.com using SounnyForms."
"Submit a test inquiry to my contact form to verify email delivery."
"Check if the SounnyForms serverless endpoint is healthy."
Web Application: https://forms.sounny.com
Documentation & Sandbox: https://forms.sounny.com/#sandbox
Author: Dr. Moulay Anwar Sounny-Slitine (https://sounny.com)
MIT License © 2026 Dr. Moulay Anwar Sounny-Slitine.
Generates production-grade, accessible, styled or raw frontend code (HTML5, React, Next.js, Vue, Tailwind, or curl) configured for any recipient email with zero API keys.
| Name | Required | Description | Default |
|---|---|---|---|
| framework | No | Desired framework or library format (default: 'html'). | |
| form_fields | No | List of field names to include (e.g. ['name', 'email', 'phone', 'company', 'message']). | |
| recipient_email | Yes | Destination email address where submissions will be routed. | |
| include_anti_spam | No | Include hidden honeypot anti-spam traps and velocity timers (default: true). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It clearly indicates that the tool produces code and does not require API keys, but it does not explicitly disclose side-effect-free behavior, whether it only returns a snippet rather than sending anything, or any limitations around email validation or delivery.
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, information-dense sentence with no filler. It front-loads the core action and resource, then efficiently lists supported formats and the key differentiator of zero API keys.
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 code-generation tool with four well-documented parameters and no output schema, the description plus schema covers the essentials. It lacks explicit guidance about when to use generate_full_contact_page instead, but the provided formats, email configuration, and 'zero API keys' point give enough context 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 description coverage is 100%, so the schema already documents all four parameters. The description adds useful context about production-grade/accessible output and zero-API-key configuration, but it does not add deeper semantics for individual parameters beyond what 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?
The description uses a specific verb ('Generates') and a clear resource ('frontend code') with explicit formats (HTML5, React, Next.js, Vue, Tailwind, curl) and a distinguishing constraint ('configured for any recipient email with zero API keys'). This clearly separates it from siblings like submit_form or generate_full_contact_page.
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?
The description implies usage for generating frontend form code and contrasts implicitly with sibling tools by focusing on snippet generation rather than submission or full-page generation. However, it does not explicitly state when to choose this tool over generate_full_contact_page or submit_form, leaving the routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates a complete standalone, beautifully styled modern HTML5 + CSS landing contact page ready to save to disk or deploy.
| Name | Required | Description | Default |
|---|---|---|---|
| page_title | No | Headline for the contact page (e.g. 'Get in touch with our engineering team'). | |
| company_name | Yes | Name of the business, portfolio, or brand. | |
| recipient_email | Yes | Destination email address where submissions will be routed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It discloses the output type (HTML5 + CSS), style, and that the result is standalone and deployable. However, it does not clarify whether the tool returns the page content directly or writes a file, and it omits how form submissions are handled—a meaningful gap for a contact page 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?
The description is a single compact sentence with the core action and artifact type front-loaded. The phrase 'beautifully styled modern' is subjective and adds little operational value, but it does not significantly harm clarity.
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 and no annotations, so the description must cover return semantics and integration behavior. It does not explicitly state what the function returns (e.g., HTML string vs file path), nor whether the generated page includes a working form linked to an endpoint. This leaves critical ambiguity, especially alongside siblings like submit_form and generate_form_snippet.
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 100%, so the schema already documents all three parameters adequately. The description adds no parameter-level meaning beyond that, matching the baseline for full schema coverage.
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 uses a specific verb and resource: 'Generates a complete standalone... HTML5 + CSS landing contact page'. It implicitly distinguishes from the sibling generate_form_snippet by emphasizing 'complete standalone... page', but it does not explicitly name or contrast with siblings.
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?
The description implies when to use this tool—when a full standalone contact page is needed—but provides no explicit when-to-use/when-not-to-use guidance or alternative comparison. Sibling tool names add context, but the description itself does not route the agent toward or away from specific alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks the live health, latency, CORS headers, and readiness of the SounnyForms serverless backend.
| Name | Required | Description | Default |
|---|---|---|---|
| endpoint_url | No | Optional custom URL to test (defaults to https://forms.sounny.com). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It does disclose that the tool performs live checks across several specific aspects, which is useful. However, it does not say what kind of request it makes, whether it returns raw data or a summary, or how it behaves if the endpoint is unreachable.
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 sentence with no filler. It front-loads the action and packs all relevant checked aspects into a compact, readable list.
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 simple read-only diagnostic tool with one optional parameter, the description conveys the core purpose and scope well. It is slightly incomplete in not indicating the shape of the result or behavior on failure, but these are minor gaps for a tool of this simplicity.
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% for the single optional endpoint_url parameter, so the schema already documents its meaning and default value. The description does not need to add parameter-level detail, and the baseline of 3 is appropriate.
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 opens with a specific verb ('Checks') and identifies both the target resource ('SounnyForms serverless backend') and the specific dimensions probed (health, latency, CORS headers, readiness). This makes the tool's purpose unmistakable and clearly distinct from the sibling tools, which focus on submitting forms or generating form code.
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?
The description clearly implies when this tool should be used: whenever an agent needs to assess the live status of the backend. It does not explicitly name alternatives or exclusion conditions, but the sibling tools are so different in purpose that the context is clear enough for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submits structured form data directly to any recipient email address or custom form ID on SounnyForms with ZERO API keys required. The submission is delivered to the recipient's inbox and permanently logged in their encrypted Cloud Firestore vault.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Full name of the submitter. | |
| Yes | Submitter's email address for direct 1-click Reply-To. | ||
| message | Yes | Inquiry message body or bug report details. | |
| extra_fields | No | Optional custom key-value pairs (e.g. { 'Company': 'Acme', 'Budget': '$10,000', 'Timeline': 'Q3' }). | |
| recipient_email_or_form_id | Yes | Destination email address (e.g. 'alex@company.com') or form identifier (e.g. 'lead_inquiry'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the submission is delivered to the recipient's inbox, permanently logged in an encrypted Cloud Firestore vault, and requires no API keys. This goes beyond the basic action by describing side effects and persistence, though it does not mention response details or limitations like rate limits.
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 entire description is a single dense, front-loaded sentence. It covers the action, destination, authentication requirement, delivery outcome, and logging behavior without wasted words. Every clause earns its place.
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 form-submission tool with full schema coverage, the description is largely complete: it explains what happens after submission, where data is stored, and that no API keys are needed. It lacks an output/return expectation and explicit caveats, but those are not essential for selecting and invoking this tool correctly.
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 100%, so the input schema already documents all parameters. The description itself adds little parameter-level meaning beyond reinforcing that the destination can be an email or form ID. Baseline 3 is appropriate because the schema handles parameter documentation.
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 uses a specific verb ('Submits') with a clear resource ('structured form data') and destination ('any recipient email address or custom form ID on SounnyForms'). It also adds a key differentiator ('ZERO API keys required'), making the tool's purpose unmistakable and distinct from the sibling generate/inspect tools.
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?
The description implies when to use the tool: whenever structured form data needs to be submitted or delivered. However, it does not explicitly state when not to use it or name alternative tools, so an agent must infer the appropriate usage context from the description and sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The core actions are clearly separated: submitting data, generating embed code, generating a full page, and checking status are distinct. The only mild overlap is between generate_form_snippet and generate_full_contact_page, but their descriptions clarify that one produces an embeddable snippet while the other produces a standalone page.
All tool names follow a consistent verb_noun snake_case pattern: submit_form, generate_form_snippet, generate_full_contact_page, and inspect_endpoint_status. The naming is predictable and easy to scan.
Four tools is well-scoped for a forms-focused server. Each tool serves a clear purpose without redundancy or bloat, and there are enough tools to cover the primary workflows.
The submission and code-generation workflows are covered, and the health check is a useful addition. However, there are no tools to retrieve, list, or manage submitted form data despite the description mentioning a permanent vault, leaving a notable lifecycle gap.
Email for AI agents — send, receive as a webhook, manage domains, templates, routing.
Create and wire up contact forms from your coding agent. Forms, snippets, and submissions.
Email for AI agents: send mail, manage contacts, automations & webhooks. Zero-DNS first send.
Authenticated email gateway for AI agents — per-agent inboxes, HITL approval, SPF/DKIM verified.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/sounny/sounnyforms-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
