Zammad

Getting a token

1. Sign in to Zammad, open your avatar → Profile → Token Access, and switch token access on if an admin has not already.
2. Create a token with the permissions the agent needs — ticket.agent to read and answer tickets, admin only if you really want the agent to change configuration.
3. Put it in ZAMMAD_API_TOKEN and your instance's base URL (no trailing slash, no /api) in ZAMMAD_URL.

The Authorization header is Token token=…, Zammad's own scheme — not Bearer. This adapter sends it correctly; it is the first thing to check when hand-building a Zammad connector that 401s with a token you know is good.

Permissions are per-token and per-group. A token whose user is not a member of a group cannot see that group's tickets, and Zammad reports this as an empty list rather than an error. An agent that says 'there are no tickets' may simply be looking through the wrong account.

Search syntax is Elasticsearch-flavoured when Zammad has Elasticsearch attached, and falls back to a much simpler SQL LIKE otherwise. state.name:open AND group.name:Support works on the former and not the latter, so keep queries simple if you are unsure.

expand=true turns id references (state_id, owner_id) into readable names. The list tools below pass it through; it costs a little latency and saves several follow-up calls. Self-hosted, which is the thing to plan for.

• On AnythingMCP Cloud the instance must be reachable from the public internet on a real hostname with a valid TLS certificate. A self-signed certificate will fail: the connector offers no trust-anything switch.
• On an internal host (zammad.intern, 10.0.0.x), self-host AnythingMCP on the same network and add that host to SSRF_ALLOWED_HOSTS, or the outbound guard refuses the call before it is made.

Writes: zammad_create_ticket opens a real ticket that notifies the customer, and zammad_add_article sends a real reply if type is email. Use type: note with internal: true for anything the customer should not see.