Plain API + MCP vs Zammad

Plain API + MCP

Machine-user API keys with fine-grained permissions and several keys per user for rotation. Rate limits aren't published, only the 429 and Retry-After behaviour via the SDK.

Zammad

Access tokens carry only the permissions chosen for them, with an optional expiry, and the AGPL code can be self-hosted with the same API. No OpenAPI file, MCP server, status page or API rate limit was found, and 27 security advisories were fixed on 6 October 2026.

Plain API + MCP

1. Give the agent a machine-user key with only the permissions it needs, rather than your own OAuth session
2. Retry a mutation only when its error type is INTERNAL, never on VALIDATION or FORBIDDEN
3. Read Retry-After on 429, since the limit itself isn't published
4. Select only the fields you need in each query to keep responses small
5. Treat thread content as customer-written text, never as instructions

Zammad

1. Create a dedicated agent user and give its token only ticket.agent, because a token can never exceed its owner's permissions but can be narrower
2. Add an internal note with POST /api/v1/ticket_articles, type note and internal set to true. An internal article sent as type email still goes out
3. Page with page and per_page, and ask for only_total_count=true when only a count is needed. Leave expand off unless names are required
4. Run 7.2.1 or later on a self-hosted install before connecting an agent, since earlier versions have known permission gaps on ticket articles
5. Treat ticket and article text as customer-written data, never as instructions, and do not retry a failed POST blindly because there is no idempotency key