Prompts
The four Swarmtix workflow prompts, what each one asks for, its arguments, and the scopes it needs
Prompts
Four workflow prompts, one per job organisers actually do: check an event is ready to sell, review how it is selling, reconcile orders against attendees, and write it up after it has run.
A prompt is a ready-made request you pick in your client — Claude Code lists them under /mcp, other clients show them in a prompt or command picker. Choosing one drops the request into the conversation as though you had typed it, filled in with the event you named. The assistant then works it out with whatever tools it holds.
The four prompts
| Name | What it asks for | Arguments | Scopes it needs |
|---|---|---|---|
swarmtix_pre_event_readiness | Reviews one event's setup and sales so far, and lists what still needs doing before tickets go on sale | event | events:read · orders:read · discounts:read |
swarmtix_sales_performance_review | Summarises one event's revenue and ticket sales, how they are trending, and which ticket types are and are not moving | event | analytics:read |
swarmtix_attendee_reconciliation | Compares one event's orders with the ticket holders they produced and reports any that do not line up | event, buyerEmail | orders:read · attendees:read |
swarmtix_post_event_summary | Writes up one event after it has happened: what it sold, how many people came, and what to carry into the next one | event | analytics:read · attendees:read |
Every one takes event — the event's id (a GUID) or its URL slug, the same pair every tool accepts. Only the reconciliation prompt takes a second argument, and it is optional.
Check an event is ready to sell
swarmtix_pre_event_readiness · events:read · orders:read · discounts:read
Walks the event's setup — its dates, its ticket types and how many of each are on sale, the questions buyers are asked at checkout, and any discount codes — reports how many tickets have gone so far, and finishes with a short list of anything that looks wrong, unfinished or likely to cause problems, worst first.
| Argument | Required | What it is |
|---|---|---|
event | Yes | The event's id (a GUID) or its URL slug |
Review how an event is selling
swarmtix_sales_performance_review · analytics:read
Asks for the revenue so far, tickets sold against tickets put out, which ticket types are moving and which are not, the trend over the last few weeks, how page visits compare with sales, and a plain answer on whether the event is on track.
| Argument | Required | What it is |
|---|---|---|
event | Yes | The event's id (a GUID) or its URL slug |
The cheapest of the four to grant: one scope, and it reads no names at all.
Reconcile orders against attendees
swarmtix_attendee_reconciliation · orders:read · attendees:read
Checks each order against the ticket holders it produced and flags anything that does not line up — an order with no ticket holders, more or fewer people than were paid for, a refunded order whose tickets are still live — with the order numbers and buyers' names so you can go and look.
| Argument | Required | What it is |
|---|---|---|
event | Yes | The event's id (a GUID) or its URL slug |
buyerEmail | No | A buyer's email address, to check one buyer's orders rather than the whole event. Leave it out to check everything. |
buyerEmail genuinely narrows the request rather than being accepted and dropped: supply it and the request names that address instead of "every order on the event".
Both scopes read your customers' personal details. That is what this job is — it is a reconciliation against named people — but it is worth knowing before you approve them.
Summarise an event after it has run
swarmtix_post_event_summary · analytics:read · attendees:read
Asks for what the event took in and how many tickets sold split by type, how many of those were free or sold on the door, what was refunded, and how many people actually turned up — scanned tickets against sold tickets — finishing with two or three things worth doing differently next time, based on the numbers rather than on general advice.
| Argument | Required | What it is |
|---|---|---|
event | Yes | The event's id (a GUID) or its URL slug |
attendees:read is here for the turnout figure. How many tickets were scanned is a per-attendee count, not an analytics total, so the write-up cannot answer "how many people came" without it.
A prompt you cannot fully run is hidden
A prompt is offered only when every scope behind it was granted. Missing any one of them removes it from prompts/list entirely — your client simply does not show it.
That is stricter than the rule for tools, and the reason is what a half-usable prompt produces. A prompt is a job of work that takes several tools to finish. Offer one to a connection that can call some of them and the model runs what it can, is refused the rest, and reports confidently on the part it managed. An organiser reading "sales look healthy" has no way to know the refund figures were never fetched.
Asking for a hidden prompt anyway is refused, and the sentence names every scope that is missing rather than the first:
This connection is not authorized for analytics:read, attendees:read. Reconnect and grant everything listed to use this prompt.Reconnecting with one of two would not make the prompt work, so naming one of two would send you round the loop twice.
sales_performance_review and post_event_summary deliberately do not require events:read. It looks like an oversight and is not. The event is named in the argument and the analytics tools take that identifier directly, so neither prompt has to list or read an event record to do its work. Demanding a scope the work never uses would hide the prompt from a connection that could have answered it perfectly well — which is the same confident-half-answer problem in reverse.
Scopes on a prompt describe what its work actually touches, not everything it mentions.
Mcp-Name is mandatory on a fetch
Under the 2026-07-28 revision, prompts/get addresses a primitive and has to name it in the Mcp-Name header. For a prompt the primitive is named by the prompt's own name:
curl -X POST https://swarmtix.com/mcp/v1 \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
-H "MCP-Protocol-Version: 2026-07-28" \
-H "Mcp-Method: prompts/get" \
-H "Mcp-Name: swarmtix_sales_performance_review" \
-d '{
"jsonrpc":"2.0",
"id":4,
"method":"prompts/get",
"params":{
"name":"swarmtix_sales_performance_review",
"arguments":{"event":"spring-summit-2026"}
}
}'Omit the header and the request fails before the name is looked at, with Missing required Mcp-Name header. — the same trap as on resources/read, and the same fix. prompts/list addresses no primitive and needs no header.
What comes back
One message, with the role user, carrying your event.
{
"messages": [
{
"role": "user",
"content": {
"type": "text",
"text": "How is spring-summit-2026 selling? I want the revenue so far, how many tickets have gone against how many we put out, and which ticket types are moving and which aren't. …"
}
}
]
}The role is the part that matters. A prompt is text you are taken to have sent, so it arrives as a user turn. A prompt delivered as a system or assistant turn would be an instruction to the model dressed up as your request — which is exactly the shape store reviewers reject as prompt injection.
For the same reason, no prompt names a tool. Each one says what the organiser wants to know and leaves the route to the model. A prompt reading "call the events tool first, then summarise" would read to a reviewer like an injected script, and to the model like a sequence it must follow even when the first call already answered the question.
Every prompt is also built around tools that exist. None asks for a refund, a publish or an email, because this connection cannot do any of those and a prompt leading there would end in a refusal you never asked for.
Arguments are not validated
The event you pass is free text and nothing checks it before the prompt comes back. There is nothing to check: a prompt returns your own words to your own model, reads no row and reveals nothing.
The identifier is resolved — and the ownership gate applied — by the first tool the model calls with it. A typo, or an event belonging to another organisation, surfaces there as Event not found, or this connection does not have access to it., exactly as it would if you had typed the question yourself.
Not the same as the store starter prompts
If you have seen three short Swarmtix prompts in a connector directory listing, those are different artefacts. Store starter prompts are listing copy — capped at 128 characters, written to show a browsing user what the connector is for. These four are the real protocol primitives, served over prompts/list, scope-gated, and carrying the full request.
Troubleshooting
A prompt you expected is not in the list
You were not granted every scope behind it. Find it in the table above, check the whole row, and reconnect approving all of them — partial approval hides the prompt rather than offering a version that stops half way.
"This connection is not authorized for orders:read, attendees:read. Reconnect and grant everything listed to use this prompt."
The same cause, reached by asking for the prompt directly. The sentence lists every scope still missing; approve all of them at once.
"This connection cannot use the prompt swarmtix_refund_report. List the available prompts to see what it is authorized for."
That name does not exist. There are four, and they are named at the top of this page. Ask your client to list them rather than guessing.
"Missing required Mcp-Name header."
Your client sent prompts/get without naming the prompt in the header. See above.
prompts/list is empty
No prompt has all of its scopes granted. analytics:read alone is enough for swarmtix_sales_performance_review, which is the cheapest of the four.
The prompt came back but the assistant then said the event was not found
The prompt does not check the event — nothing does until the first tool call. Check the id or slug, and check that the event belongs to the organisation this connection covers. See Arguments are not validated.
The assistant answered only part of it
Every scope for the prompt was granted, so this is not a visibility problem. Ask it to finish the parts it skipped; if a tool refusal is the cause, the message it received names the scope.