Cactal

Add a notification recipient to a form

websiteForms_recipients_add

Idempotent

Adds an email address to one form, identified by its name from the action path. New forms notify the organization owners until changed. Organization members and website editors receive submissions immediately; other addresses get a confirmation email (link valid 7 days). member and confirmed addresses receive email; pending addresses must confirm by link; failing addresses bounced or complained; stopped addresses opted out. Works before the first submission; at most 20 addresses per website.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "websiteId": "<websiteId>",
      "formName": "<formName>",
      "email": "<email>"
    },
    "name": "websiteForms_recipients_add"
  }
}

Input Schema

Name	Required	Description
`email`	Yes	Address to notify.
`formName`	Yes	The form name from the action path.
`websiteId`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 2, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the annotations, which already declare a non-read-only, idempotent, open-world mutation, the description adds substantial behavioral detail: default organization-owner notifications, immediate delivery for members/editors, confirmation links valid 7 days, and the meaning of member, confirmed, pending, failing, and stopped statuses.

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 description is front-loaded with the core action and then supplies constraints and status semantics. It is somewhat dense, especially the status-definition list, but every sentence carries useful information for invoking the tool correctly.

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

Completeness4/5

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

For a mutation tool with no output schema, the description covers behavior, defaults, delivery semantics, lifecycle states, and a hard limit. It is nearly complete, though it does not explain the required websiteId parameter or any permission requirements.

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

Parameters3/5

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

Schema description coverage is 67%, and the description clarifies two parameters: email as the address to notify and formName as the form name from the action path. websiteId is left undocumented in both schema and description, so the description only partially compensates for the coverage gap.

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?

The description states a specific verb and resource: adding an email address as a notification recipient to one form. It also identifies the form by name from the action path, which distinguishes it from sibling tools like websiteForms_recipients_remove or websiteForms_recipients_resend.

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?

The description gives clear context for when this tool applies: adding recipients, including before the first submission, with a 20-address limit per website. It does not explicitly name alternatives such as remove or resend, so it falls short of full when-to-use/when-not guidance.

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

All Cactal tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?