Ticket Tools | Yaplet

Overview

The Ticket tool category gives you a single tool, manage_ticket, that covers everything you'd normally do to a ticket in the dashboard. You can create tickets, change their status by moving them between columns, hand them to a colleague, tag them, write internal notes your team can see, and reply by email to the customer who reported the problem.

Permission required:Tickets

New login permission. Ticket tools sit behind their own copilot:tickets scope — a separate checkbox on the login screen when you connect an MCP client. If you connected before ticket tools existed, reconnect once to grant it.

Board access applies here. Boards are granted per person, and every ticket tool respects that — you only see and act on the boards you've been given access to, exactly as in your dashboard. Only the organisation owner is exempt; admins hold board grants like everyone else. A board you don't have access to answers exactly the same as a board that doesn't exist.

Key Concepts

Two things about boards are worth understanding before you use this tool, because they explain most of its behaviour.

The column is the status

A board's columns are its statuses — "New", "In progress", "Done", or whatever your board defines. There is no separate status field: you change a ticket's status by moving it to a different column.

Archiving means "in no column"

A ticket that sits in no column at all is archived. That's the entire mechanism. Archiving takes a ticket off the board while keeping it, and putting an archived ticket back into any column brings it out of the archive.

Don't guess IDs. Columns, labels and boards all have IDs you need to pass. Fetch the board first — a single get_record on a board returns its columns, its label palette, the people a ticket can be assigned to, the addresses you can email from, and the available priorities. That's every value this tool accepts.

manage_ticket

Creates a ticket, or changes, archives or deletes an existing one — and optionally comments on it and emails the reporter in the same call.

Parameters

Parameter	Type	Required	Description
`id`	string	No	The ticket to act on. Omit it to create a new ticket.
`action`	string	No	`"update"` (default), `"archive"`, or `"delete"`.
`boardId`	string	Conditional	Required when creating. On an update, moves the ticket to this board.
`boardColId`	string	No	The column (status) to place the ticket in. Must belong to the target board.
`title`	string	Conditional	Required when creating. Up to 500 characters.
`description`	string or null	No	Up to 20,000 characters.
`priority`	string	No	`LOW`, `MEDIUM` or `HIGH`.
`assignedUserId`	string or null	No	The team member to assign it to. Pass `null` to unassign.
`labelIds`	string array	No	Replaces the ticket's labels. Must be labels from the target board. Max 50.
`read`	boolean	No	Mark the ticket read or unread.
`comment`	string	No	An internal note added to the ticket. Up to 5,000 characters.
`email`	object	No	Emails the reporter. See Emailing the reporter below.

How It Works

Creating a ticket — omit id. boardId and title are required. The ticket lands at the bottom of the board's first column unless you name a boardColId. It starts at MEDIUM priority, unread, and with no reporter attached, because nobody submitted it through a form — you asked for it.

Updating a ticket — provide id. Only the fields you actually pass are changed; everything else is left alone.

Archiving — action: "archive" takes the ticket off the board but keeps it and its history. It can't be combined with boardColId: archiving means "in no column", so naming a column contradicts it and is rejected rather than silently ignored. To bring an archived ticket back, just set boardColId to the column you want it in.

Deleting — action: "delete" is permanent and removes the ticket's comments along with it. It has to be sent on its own; any other field in the same call is rejected, because a note or an email recorded against a ticket that's about to disappear would simply be thrown away. Archive instead unless you're certain.

Doing several things at once — field changes, a comment and an email can all ride in one call, applied in that order. Closing a ticket out is a single request: move it to Done, note internally why, and tell the customer.

Moving a Ticket to Another Board

Columns and labels belong to one specific board, so a move has to bring both along:

The ticket is placed in the target board's first column, or in boardColId if you name one — which is checked against the target board, not the one it came from.
Its labels are cleared, unless you pass labelIds from the new board's palette.

Without this, a moved ticket would either disappear from both boards or carry labels that render as nothing.

What Gets Checked

Everything you pass is validated before anything is written, so a wrong ID fails with a clear explanation rather than half-applying:

The assignee must be an active member of your organisation.
Labels must exist on the board the ticket will end up on.
The column must belong to that same board.

Comments

comment adds an internal note. Only your team sees it — the person who reported the ticket never does. Notes are attributed to whoever is signed in, and they appear immediately in a colleague's open ticket panel without them needing to refresh.

Emailing the Reporter

The email object writes to the person who reported the ticket, quoting their original submission back to them. Unlike a comment, this one is visible to the customer.

Field	Type	Required	Description
`content`	string	Yes	Your message to the reporter. Up to 20,000 characters.
`to`	string	No	Defaults to the reporter's own email address.
`senderEmail`	string	No	One of your organisation's verified addresses.
`senderName`	string	No	The name the email appears to come from.

If you don't set senderEmail, or the address isn't verified for your organisation, the email is sent from the default Yaplet sender instead.
A ticket created through this tool has no reporter, so you'll need to supply to explicitly.
Sending is capped at 30 ticket emails per hour per organisation.
If delivery fails you get an error, and nothing is recorded on the ticket — a failed send never looks like a successful one.

Example Prompts

"Create a high priority ticket on the Bugs board: checkout fails on Safari."
"Move this ticket to Done."
"Assign this ticket to Sarah."
"Unassign this ticket so someone else can pick it up."
"Tag this ticket as a regression."
"Archive the tickets we finished this week."
"Bring that archived ticket back into In Progress."
"Add a note to this ticket: waiting on the payment provider to confirm."
"Close this ticket and email the reporter that it's fixed in 2.4.1."
"Delete this duplicate ticket."

Copilot asks first. In the dashboard Copilot, manage_ticket always shows a Confirm button before it runs — it can delete a ticket and it can email a customer, so it never acts unprompted.

Common Workflow Patterns

Triage a Board

Find the board → list_records with table: "boards"
Learn its columns, labels and people → get_record with table: "boards"
List the live tickets → list_records with table: "tickets", archived: false
Move, assign and prioritise → manage_ticket

Example prompt: "Show me everything on the Bugs board that isn't archived, and move anything about checkout into In Progress assigned to me."

Close a Ticket Out

One call does all three parts of closing a ticket — the status change, the internal record, and the customer reply:

Example prompt: "Move this ticket to Done, note internally that it shipped in 2.4.1, and email the reporter to let them know it's fixed."

Move Work Between Boards

Fetch the target board → get_record with table: "boards" (for its columns and labels)
Move the ticket → manage_ticket with boardId, boardColId and labelIds

Example prompt: "Move this feature request off the Bugs board onto the Roadmap board, into Planned, and tag it as an enhancement."

Follow Up on What Customers Reported

Find the tickets → list_records with table: "tickets"
Read one in full, including who reported it → get_record with table: "tickets"
Reply to them → manage_ticket with email

Example prompt: "Find the open bug reports on this board, show me who reported each one, and email anyone still waiting on an update."

Finding tickets in the first place is covered by Data Access Tools — listing boards and tickets, filtering by column, assignee, priority or archived state, and fetching a single ticket with its comments and reporter.