Sliq

Send Luma Invites

send_luma_invites

Destructive

Luma emails each recipient an invite to the event and adds them to the roster as invited. This is a real send with no approval step and no undo — treat calling it as sending, and confirm the recipient list with the user first unless they have already approved this exact wave.

Distinct from the LinkedIn/email outreach queues: those are Sliq-sent cold sequences with pacing and approval gating, whereas this is Luma's branded event invite from the calendar the user owns. Use the queues to pitch the event to people who don't know it exists; use this to invite people who should land directly on the event's guest list.

Anyone already on the roster — invited, going, pending approval, waitlisted, or declined — is skipped, so re-running with the same list invites only the genuinely new people. That makes retries safe.

Every invite is recorded against the matching person Sliq tracks (under data['luma_invites'], one entry per event), so who-we-invited is answerable from our own records and not only from Luma's roster.

Recipients Sliq isn't tracking are still invited — they just get no such record, which means an RSVP from them won't appear in the funnel. That is normal (hand-typed addresses, people who were never prospects), and most waves have some, but the user can't see it from Luma's side. When not_tracked is non-empty, say so in the reply — how many, and which addresses — instead of reporting a clean send. A summary dict {event_id, invited: [...], invited_count, skipped: [{email, reason}], skipped_count, tracked_count, not_tracked: [...], not_tracked_count} — plus note, user-facing wording for the untracked recipients, present only when there are any. invited lists the addresses actually sent to; a fully-deduplicated call returns invited_count 0 and is a success, not an error. tracked_count counts recipients Sliq already knows; it is lower than invited_count whenever the wave includes people who aren't tracked.

Input Schema

TableJSON Schema

Name	Required	Description
`emails`	Yes	Recipient email addresses. Deduplicated case-insensitively, then filtered against the live roster.
`message`	No	Optional personal note included in the invite email, max 200 characters. Written for the whole wave — Luma has no per-recipient placeholder substitution here, so don't try to personalize it with names.
`event_id`	Yes	The Luma event id from get_luma_events (starts with "evt-").
`on_behalf_of`	No	An agency client's email, from list_agency_clients, to run this call in that client's account: their agents, settings, connected accounts, and credits. Omit it to act on your own account.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 19, 2026

addedInput schema / properties / on_behalf_of

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "An agency client's email, from list_agency_clients, to run this call in that client's account: their agents, settings, connected accounts, and credits. Omit it to act on your own account."
+}

First observedSep 15, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=false and destructiveHint=true, but the description adds substantial behavioral context beyond them: no approval step, no undo, dedupe against every roster status (invited/going/pending/waitlisted/declined), retry safety, per-event recording under data['luma_invites'], and the requirement to surface not_tracked recipients instead of reporting a clean send.

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?

Well front-loaded with <summary> and <returns> sections, and nearly every sentence carries actionable content. It is on the long side and repeats the not_tracked/skip semantics in both summary and returns, but the density is justified for a destructive send tool.

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

Completeness5/5

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

There is no output schema, but the <returns> block fully documents the response dict, including the invited_count 0 success case and the tracked_count vs invited_count relationship — so the agent need not guess at return values. Combined with the destructive-send disclosure, nothing needed to call this correctly is missing.

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 coverage is 100%, so the schema already documents all four parameters thoroughly (including the on_behalf_of account-switching behavior and the 200-char message limit). The description reinforces the whole-wave nature of `message` and the roster filtering of `emails`, but adds little parameter meaning beyond what the schema provides, so the baseline 3 applies.

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?

States a specific verb and resource — 'Send Luma's own event invitations to a list of email addresses' — and immediately distinguishes the operation from the LinkedIn/email outreach queues by naming the sibling category and the scenario each serves. An agent can tell this apart from send_email, manage_linkedin_invite_queue, or register_manual_linkedin_invites without opening any 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?

Gives explicit when/when-not routing: use the queues to pitch people who don't know the event; use this for people who should land on the guest list. It also adds an approval precondition ('confirm the recipient list with the user first unless they have already approved this exact wave') and explains that re-running is safe due to roster dedupe.

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

All Sliq tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?