Skip to main content
Glama
thenavidm

Senja MCP Server

by thenavidm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

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.

Input Schema

NameRequiredDescriptionDefault
accountNoExact configured private account profile label; not a tenant or provider account ID.
confirmNoSet true only when the user asked for exactly this action.
form_idNoExact forms[].id from list_links.
payloadNoComplete 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.
recipientsNo
payload_fileNoAbsolute regular non-symlink JSON body file, at most 1 MiB. Cannot mix with payload/body flags.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed12 schema fields changedv3.0.0
    • 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"
  2. First observedv2.0.0

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

Other Tools