Skip to main content
Glama
Sign In
Arsel MCP Server

Arsel MCP Server

Official
by Arsel-SA
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Send Event

send-event
Destructive

Record a contact event, such as order.completed, to trigger enabled automations and optionally create the contact if it doesn't exist.

Instructions

Record that a contact did something, e.g. order.completed. The event must be defined (list-events) and data must match its schema. Enabled automations triggered by this event run for the contact and may message them, and a contact that doesn't exist yet is created. Before calling it, check list-automations for enabled automations with this trigger, tell the user what they will do, and wait for their go-ahead.

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": {
      "event": "<event>",
      "data": "<data>"
    },
    "name": "send-event"
  }
}

Input Schema

NameRequiredDescriptionDefault
dataYesEvent payload, matching the event's schema.
emailNo
eventYesName of a defined event, from list-events.
timestampNoISO 8601 time the event happened; defaults to now.
contact_idNoArsel contact id, from list-contacts. Cannot be combined with `external_id`, `email` or `phone_number`.
external_idNoThe organization's own user id for the contact.
phone_numberNoE.164 phone number, e.g. +966501234567.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.2.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true and openWorldHint=true, but the description supplies the causal reason the call is risky: enabled automations will run against the contact and may message them. It also discloses a hidden side effect not visible in the schema or annotations — a non-existent contact is created as a side effect of the write — and adds a mandatory human-approval step.

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?

It is front-loaded with the core action and the example, then prerequisites, then side effects, then the approval workflow — a sensible order. It is dense and the final sentence is long, but each clause conveys a distinct operational fact rather than restating the title or schema.

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 destructive, open-world, non-idempotent write with seven parameters and a nested payload object, the description covers prerequisites, side effects, and the confirmation gate, which is the bulk of what an agent needs. It does not address repeat-send behavior or what the call returns, which matters somewhat given idempotentHint=false and no output schema, but those are secondary next to the safely-critical information that is present.

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?

Schema coverage is 86%, so per-parameter definitions are largely handled structurally and the baseline is 3. The description adds real semantic constraints the schema does not: `data` must conform to the named event's schema (a cross-resource dependency), and the contact-identity parameters implicitly accept a contact that does not yet exist because one will be created.

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 uses a concrete verb and resource ('Record that a contact did something') plus a literal example ('order.completed'), which separates it from sibling event tools like create-event (defines event types) and list-events (enumerates them). An agent can tell what this call does without opening the schema.

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

Usage Guidelines5/5

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

It states prerequisites explicitly ('The event must be defined (list-events)'), names the alternative tool to consult first ('check list-automations for enabled automations with this trigger'), and prescribes a gated workflow: describe the automations to the user and wait for approval before sending. This is an explicit when-to-use and how-to-proceed rule, not implied guidance.

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