Zammad MCP by usefulapi

The Zammad user this access token belongs to: id, name, e-mail, roles and groups. Use it to confirm the connection and the token's permissions. GET /api/v1/users/me.

Takes no parameters.

Search tickets with Zammad's query syntax. With Elasticsearch on the instance you can use fields, e.g. `state.name:open AND group.name:Sales`, `customer.email:"[email protected]"`, `title:invoice`, `number:20001`; a plain word searches ticket text. Replies carry ids plus names (group, state, priority, owner, customer). GET /api/v1/tickets/search?expand=true.

List the tickets the token's user can see (an agent sees the tickets of their groups; a customer only their own). For anything targeted use zammad_search_tickets. GET /api/v1/tickets?expand=true.

One ticket by its numeric id (not the ticket number): title, group, state, priority, owner, customer, organization, dates, escalation and article count. GET /api/v1/tickets/{id}?expand=true.

All articles (messages, internal notes, e-mails, phone notes) of one ticket in order, with sender, type, internal flag, from/to/cc, subject, body and attachment names (attachments are not downloaded). Long bodies are cut at 6000 characters; use zammad_get_ticket_article for the full text. GET /api/v1/ticket_articles/by_ticket/{ticket_id}.

One article by its id with its full body, headers and attachment names. GET /api/v1/ticket_articles/{id}.

The tags on one ticket. GET /api/v1/tags?object=Ticket&o_id={ticket_id}. Needs an agent token.

The ticket states of the instance (new, open, pending reminder, pending close, closed, ...) with ids and whether they are active. Use the names in zammad_update_ticket. GET /api/v1/ticket_states.

Takes no parameters.

The ticket priorities of the instance (e.g. '1 low', '2 normal', '3 high') with ids. Use the names in zammad_update_ticket. GET /api/v1/ticket_priorities.

Takes no parameters.

The ticket groups (queues) of the instance, with ids, names and agent ids. Zammad requires the admin.group permission for this list; with an agent-only token it returns an authorization error. GET /api/v1/groups.

Search customers and agents by name, e-mail, login, phone or organization. Returns profile fields (no credentials). Needs an agent token. GET /api/v1/users/search?expand=true.

One user (customer or agent) by id: name, e-mail, phone, organization, roles, VIP flag and notes. No credentials. GET /api/v1/users/{id}?expand=true.

Search customer organizations by name or domain. Needs an agent token. GET /api/v1/organizations/search.

List customer organizations with domain, VIP flag and member ids. Needs an agent token. GET /api/v1/organizations.

One organization by id: name, domain, notes, VIP flag, member ids. GET /api/v1/organizations/{id}.

WRITE: add an INTERNAL note (visible to agents only, never e-mailed to the customer) to ONE ticket. Needs an agent's token (a customer's token is refused, because Zammad would make the note public). The ticket's other data is not changed. POST /api/v1/ticket_articles with type=note, internal=true.

WRITE: send a customer-visible reply on ONE ticket. THIS E-MAILS A REAL PERSON: the reply is delivered by e-mail to exactly ONE recipient and cannot be recalled. By default the recipient is the ticket's customer (looked up from the ticket); `to` may name one other single address. No cc, no bulk, no attachments. Needs an agent's token (a customer's token is refused). For an internal remark use zammad_add_internal_note. GET /api/v1/tickets/{id}, then POST /api/v1/ticket_articles with type=email, internal=false.

WRITE: change fields of ONE ticket: state, priority, owner (agent), group and/or title. Use names from zammad_list_ticket_states / zammad_list_ticket_priorities / zammad_list_groups. Pending states need `pending_time`. Never deletes, removes or merges (those states are refused). The instance's own triggers still run, so closing or reassigning a ticket can send the customer or agent a notification e-mail. PUT /api/v1/tickets/{id}.

WRITE: create ONE new ticket for an EXISTING customer (by e-mail address or user id) in a group, with a first article recorded as written by the customer (type note or phone). It does not send an e-mail by itself, but the instance's triggers may (for example an automatic confirmation to the customer). It never creates new users. POST /api/v1/tickets.