Zammad MCP by usefulapi
REMOTE · ZAMMAD.USEFULAPI.IO
Search and read Zammad tickets, customers and organizations; add notes, replies and ticket updates.
Available components
Last scanned (23 hours ago)
Scores higher than 47% of remote servers
Reachable. Last reached 16 Oct 2026.
Category CRM and Sales
How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →
Endpoint Security78
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- Authorisation is enforced on tool calls, advertised via RFC 9728 protected-resource metadata. Discovery is public, which costs nothing: no tool can be invoked without a token. View diagnostics → Pass
- HTTPS enforcement could not be verified: the plaintext port redirected somewhere other than https, so enforcement is unproven. View diagnostics → Unverified
- HSTS check failed: the Strict-Transport-Security header is absent. See how to fix → View diagnostics → Fail
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
- The authorisation server offers only Dynamic Client Registration (RFC 7591), which MCP 2026-07-28 deprecated in favour of Client ID Metadata Documents. View diagnostics → Partial
Transport & Reachability0
- Transport check failed: declared streamable-http, but the endpoint redirected instead of responding directly. See how to fix → View diagnostics → Fail
Schema Quality & AI Usability84
- 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).Pass
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 2280 tokens (~120/item across 19 items; 19 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management13
- Stability observed for 4 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 19 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 20 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities60
- Spec-recency check failed: implements MCP spec 2025-06-18; the latest is 2026-07-28. See how to fix → Fail
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 16 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 10 to 13. That category is still filling its 30-day observation window: 3 days of observed history at the previous scan, 4 at this one. The score rises as the window fills, whether or not the server changes.
- 14 Oct 26 +2
- The server rewrote its instructions, which are the text every model session reads security
- The server now declares the “prompts” capability functional
- First check of Schema quality: 100 functional
- New prompt “getting_started” functional
- Server version: 1.0.0 → 1.1.0 functional
- 13 Oct 26 +1
- Stability: unverified → 0.03 ▲ functional
- 12 Oct 26 61
First indexed and scored.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 16 Oct 2026 · Probed https://zammad.usefulapi.io/mcp
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=usefulapi.io | CN=WE1,O=Google Trust Services,C=US | 13 Sept 2026 | 12 Dec 2026 | ECDSA 256 | ECDSA-SHA256 | d9be3287b0fde9630e825ba1f79bff3f |
| SANs: usefulapi.io, *.usefulapi.io | ||||||
| CN=WE1,O=Google Trust Services,C=US (CA) | CN=GTS Root R4,O=Google Trust Services LLC,C=US | 13 Dec 2023 | 20 Feb 2029 | ECDSA 256 | ECDSA-SHA384 | 7ff31977972c224a76155d13b6d685e3 |
| CN=GTS Root R4,O=Google Trust Services LLC,C=US (CA) | CN=GlobalSign Root CA,OU=Root CA,O=GlobalSign nv-sa,C=BE | 15 Nov 2023 | 28 Jan 2028 | ECDSA 384 | SHA256-RSA | 7fe530bf331343bedd821610493d8a1b |
Background: What to check on a remote MCP endpoint →
DNSSEC insecure
Validation of zammad.usefulapi.io. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| io. | present | 57355 | 8 | Verified |
| usefulapi.io. | absent | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication Enforced and verified
The endpoint asked for a token and published valid RFC 9728 metadata describing how to get one.
| Result | Enforced and verified |
|---|---|
| Enforced | On tool calls |
| HTTP status | 302 |
WWW-Authenticate challenge Bearer realm="OAuth", resource_metadata="https://zammad.usefulapi.io/.well-known/oauth-protected-resource/mcp"
Bearer realm="OAuth", resource_metadata="https://zammad.usefulapi.io/.well-known/oauth-protected-resource/mcp"Protected resource metadata
| Document | https://zammad.usefulapi.io/.well-known/oauth-protected-resource/mcp |
|---|---|
| Retrieved | Yes |
| Resource | https://zammad.usefulapi.io/mcp |
| Authorisation server | https://zammad.usefulapi.io |
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://zammad.usefulapi.io/mcp | Redirected | 302 | https://usefulapi.io/zammad/ |
| http (plaintext) | http://zammad.usefulapi.io/mcp | Inconclusive | 302 | http://zammad.usefulapi.io/mcp |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
zammad_add_internal_note Add internal note ~118
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.
| Name | Type | Req | Description |
|---|---|---|---|
| body | string | yes | Note text (plain text). |
| subject | string | – | Optional note subject (one line). |
| ticket_id | integer | yes | Zammad ticket id. |
No output schema declared.
No examples provided.
zammad_create_ticket Create ticket ~258
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.
| Name | Type | Req | Description |
|---|---|---|---|
| article_type | string | – | Type of the first article: note (default) or phone. |
| body | string | yes | First message of the ticket (plain text). |
| customer | string | – | E-mail address of an existing customer. Give this or customer_id. |
| customer_id | integer | – | User id of an existing customer. Give this or customer. |
| group | string | yes | Group name the ticket goes to, e.g. Users or Sales. |
| owner_id | integer | – | User id of the agent who should own the ticket. |
| priority | string | – | Initial priority name (default: 2 normal). |
| state | string | – | Initial state name (default: new). |
| subject | string | – | Subject of the first article (default: the title). |
| title | string | yes | Ticket title. |
No output schema declared.
No examples provided.
zammad_get_me Get current user ~51
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.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
zammad_get_organization Get organization ~50
One organization by id: name, domain, notes, VIP flag, member ids. GET /api/v1/organizations/{id}.
| Name | Type | Req | Description |
|---|---|---|---|
| organization_id | integer | yes | Zammad organization id. |
No output schema declared.
No examples provided.
zammad_get_ticket Get ticket ~83
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.
| Name | Type | Req | Description |
|---|---|---|---|
| ticket_id | integer | yes | Zammad ticket id (the number in the ticket URL, not the 5-digit ticket number). |
No output schema declared.
No examples provided.
zammad_get_ticket_article Get ticket article ~56
One article by its id with its full body, headers and attachment names. GET /api/v1/ticket_articles/{id}.
| Name | Type | Req | Description |
|---|---|---|---|
| article_id | integer | yes | Zammad article id (from zammad_list_ticket_articles). |
No output schema declared.
No examples provided.
zammad_get_user Get user ~63
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.
| Name | Type | Req | Description |
|---|---|---|---|
| user_id | integer | yes | Zammad user id. |
No output schema declared.
No examples provided.
zammad_list_groups List groups ~102
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.
| Name | Type | Req | Description |
|---|---|---|---|
| page | integer | – | Page number, from 1 (default 1). Pass the previous reply's next_page. |
| per_page | integer | – | Results per page, 1-100 (default 25). |
No output schema declared.
No examples provided.
zammad_list_organizations List organizations ~81
List customer organizations with domain, VIP flag and member ids. Needs an agent token. GET /api/v1/organizations.
| Name | Type | Req | Description |
|---|---|---|---|
| page | integer | – | Page number, from 1 (default 1). Pass the previous reply's next_page. |
| per_page | integer | – | Results per page, 1-100 (default 25). |
No output schema declared.
No examples provided.
zammad_list_ticket_articles List ticket articles ~103
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}.
| Name | Type | Req | Description |
|---|---|---|---|
| ticket_id | integer | yes | Zammad ticket id. |
No output schema declared.
No examples provided.
zammad_list_ticket_priorities List ticket priorities ~56
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.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
zammad_list_ticket_states List ticket states ~57
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.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
zammad_list_ticket_tags List ticket tags ~51
The tags on one ticket. GET /api/v1/tags?object=Ticket&o_id={ticket_id}. Needs an agent token.
| Name | Type | Req | Description |
|---|---|---|---|
| ticket_id | integer | yes | Zammad ticket id. |
No output schema declared.
No examples provided.
zammad_list_tickets List tickets ~102
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.
| Name | Type | Req | Description |
|---|---|---|---|
| page | integer | – | Page number, from 1 (default 1). Pass the previous reply's next_page. |
| per_page | integer | – | Results per page, 1-100 (default 25). |
No output schema declared.
No examples provided.
zammad_reply_to_ticket Reply to ticket (e-mails the customer) ~198
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.
| Name | Type | Req | Description |
|---|---|---|---|
| body | string | yes | Reply text (plain text). |
| subject | string | – | Optional subject (one line). Default: 'Re: <ticket title>'. |
| ticket_id | integer | yes | Zammad ticket id. |
| to | string | – | Optional: ONE recipient e-mail address. Default: the ticket customer's address. |
No output schema declared.
No examples provided.
zammad_search_organizations Search organizations ~94
Search customer organizations by name or domain. Needs an agent token. GET /api/v1/organizations/search.
| Name | Type | Req | Description |
|---|---|---|---|
| page | integer | – | Page number, from 1 (default 1). Pass the previous reply's next_page. |
| per_page | integer | – | Results per page, 1-100 (default 25). |
| query | string | yes | Search text, e.g. an organization name. |
No output schema declared.
No examples provided.
zammad_search_tickets Search tickets ~189
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:"a@b.com"`, `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.
| Name | Type | Req | Description |
|---|---|---|---|
| order_by | string | – | Sort direction (default: relevance). |
| page | integer | – | Page number, from 1 (default 1). Pass the previous reply's next_page. |
| per_page | integer | – | Results per page, 1-100 (default 25). |
| query | string | yes | Search query. |
| sort_by | string | – | Field to sort by, e.g. updated_at or created_at. |
No output schema declared.
No examples provided.
zammad_search_users Search users ~114
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.
| Name | Type | Req | Description |
|---|---|---|---|
| page | integer | – | Page number, from 1 (default 1). Pass the previous reply's next_page. |
| per_page | integer | – | Results per page, 1-100 (default 25). |
| query | string | yes | Search text, e.g. an e-mail address or a name. |
No output schema declared.
No examples provided.
zammad_update_ticket Update ticket ~246
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}.
| Name | Type | Req | Description |
|---|---|---|---|
| group | string | – | Group name, e.g. Sales (subgroups as Sales::Europe). |
| owner_id | integer | – | User id of the agent who should own the ticket. Id 1 is Zammad's 'no owner' placeholder. |
| pending_time | string | – | Required for the pending states: when the ticket reminds or closes, ISO 8601 with a timezone. |
| priority | string | – | Priority name, e.g. '3 high'. |
| state | string | – | State name, e.g. open, closed, 'pending reminder'. |
| ticket_id | integer | yes | Zammad ticket id. |
| title | string | – | New ticket title. |
No output schema declared.
No examples provided.
How do I install the Zammad MCP by usefulapi server?
Zammad MCP by usefulapi is a hosted endpoint at https://zammad.usefulapi.io/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
remote · zammad.usefulapi.io
claude mcp add --transport http io-usefulapi-zammad 'https://zammad.usefulapi.io/mcp'
What is the Zammad MCP by usefulapi server?
Zammad MCP by usefulapi is listed in the public MCP registry as io.usefulapi/zammad. Search and read Zammad tickets, customers and organizations; add notes, replies and ticket updates. This page covers its hosted endpoint (https://zammad.usefulapi.io/mcp).
Is the Zammad MCP by usefulapi server safe to use?
Zammad MCP by usefulapi scores 65 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the Zammad MCP by usefulapi server expose?
Zammad MCP by usefulapi exposes 19 tools: zammad_get_me, zammad_search_tickets, zammad_list_tickets, zammad_get_ticket, zammad_list_ticket_articles, and 14 more. Their descriptions and schemas cost roughly 2,072 tokens of context every time the server is loaded.
Does the Zammad MCP by usefulapi server require authentication?
Yes. Zammad MCP by usefulapi asked us for credentials when we connected, so you will need to authorise it in your MCP client before it can do anything.
Is the Zammad MCP by usefulapi server still maintained?
Zammad MCP by usefulapi is still listed as active in the MCP registry. We last reached this channel on 16 October 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.