Senja MCP Server

Send form invites

send_invites

Destructive

Send email invites to up to 100 recipients using a selected form and its existing follow-up sequence to request testimonials.

Instructions

Send email invites using a selected form and its existing follow-up sequence. Local cap100 recipients, not a documented provider quota.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "send_invites"
  }
}

Input Schema

Name	Required	Description
`account`	No	Exact configured private account profile label; not a tenant or provider account ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`form_id`	No	Exact forms[].id from list_links.
`payload`	No	Complete native JSON body; do not mix with body flags or payload_file. Arrays use repeated JSON object flags or a whole native array in a private file.
`recipients`	No
`payload_file`	No	Absolute regular non-symlink JSON body file, at most 1 MiB. Cannot mix with payload/body flags.

Schema Changelog

Changes observed during successful MCP inspections.

Changed12 schema fields changedv3.0.0Oct 6, 2026

addedInput schema / $defs

Added value: +{
+  "recipients": {
+    "items": {
+      "additionalProperties": false,
+      "properties": {
+        "email": {
+          "description": "",
+          "format": "email",
+          "minLength": 1,
+          "type": "string"
+        },
+        "name": {
+          "description": "",
+          "minLength": 1,
+          "type": "string"
+        }
+      },
+      "required": [
+        "email"
+      ],
+      "type": "object"
+    },
+    "maxItems": 100,
+    "minItems": 1,
+    "type": "array"
+  }
+}

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the requested mutation or exclusive private output file."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / payload / properties / recipients / $ref
```
Added value: +"#/$defs/recipients"
```

removedInput schema / properties / payload / properties / recipients / items

Removed value: -{
-  "additionalProperties": false,
-  "properties": {
-    "email": {
-      "description": "",
-      "format": "email",
-      "minLength": 1,
-      "type": "string"
-    },
-    "name": {
-      "description": "",
-      "minLength": 1,
-      "type": "string"
-    }
-  },
-  "required": [
-    "email"
-  ],
-  "type": "object"
-}

removedInput schema / properties / payload / properties / recipients / maxItems
```
Removed value: -100
```
removedInput schema / properties / payload / properties / recipients / minItems
```
Removed value: -1
```
removedInput schema / properties / payload / properties / recipients / type
```
Removed value: -"array"
```
addedInput schema / properties / recipients / $ref
```
Added value: +"#/$defs/recipients"
```

removedInput schema / properties / recipients / items

Removed value: -{
-  "additionalProperties": false,
-  "properties": {
-    "email": {
-      "description": "",
-      "format": "email",
-      "minLength": 1,
-      "type": "string"
-    },
-    "name": {
-      "description": "",
-      "minLength": 1,
-      "type": "string"
-    }
-  },
-  "required": [
-    "email"
-  ],
-  "type": "object"
-}

removedInput schema / properties / recipients / maxItems
```
Removed value: -100
```
removedInput schema / properties / recipients / minItems
```
Removed value: -1
```
removedInput schema / properties / recipients / type
```
Removed value: -"array"
```

First observedv2.0.0Oct 3, 2026

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, openWorldHint=true, idempotentHint=false and readOnlyHint=false, so the safety profile is covered. The description adds the local 100-recipient cap and clarifies it is not a provider quota, which is useful context, but it says nothing about the confirm gate, permission requirements, or what happens to already-sent invites.

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?

Two short, front-loaded sentences with no filler. The second sentence ('Local cap100 recipients, not a documented provider quota') is slightly cryptic in its phrasing, which keeps it from a 5.

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

Completeness3/5

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

For a destructive, non-idempotent, open-world send tool with nested payload objects and no output schema, the description covers the recipient limit but omits the confirm/safety gating, account selection semantics, and any result/error behavior. Adequate but with clear gaps.

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 83%, so the schema already documents account, confirm, form_id, payload and payload_file. The description only vaguely ties form_id to the follow-up sequence and restates the 100-recipient cap that maxItems already encodes, adding little beyond structured data.

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?

States a specific verb and resource ('Send email invites') plus the mechanism (selected form and its existing follow-up sequence), which is enough to distinguish it from the testimonial CRUD siblings. It lacks any explicit contrast with the closest sibling (create_testimonial / submit_testimonial_batch), so it stops 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.

Usage Guidelines2/5

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

No when-to-use or when-not-to-use guidance is given. Nothing tells the agent that a 'confirm' flag and an exact 'account' profile are prerequisites, or when to prefer this over a batch/submit sibling. The only usage-like statement is the recipient cap.

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

Deploy Server