Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Beschreibung vom Entwickler (englisches Original)
Connect AI assistants to the Tickiti helpdesk API: tickets, queries, reports and admin.
Diese drei werden nie zu einer Punktzahl zusammengefasst: Meinungen, Messungen und Beliebtheit sind verschiedene Dinge.
Für diesen Server haben wir noch keine Zusammenfassung in einfacher Sprache geschrieben. Unten stehen die Fakten, die wir aus der Registry gelesen haben.
Wähle die KI-App, die du nutzt, und kopiere die Einstellungen.
Der Entwickler hat in der Registry keine Installationsangaben gemacht. Sieh dir unten die README des Entwicklers an.
Läuft auf deinem Computer; die Tool-Liste erscheint nach der Installation in deiner KI-App.
Wir prüfen Informationen, die jeder sehen kann; den Code haben wir nicht gelesen. Checks, die nicht zutreffen, werden nicht mitgezählt. · Geprüft am 6. Nov. 2026
Der Registry-Name wurde mit dem GitHub-Konto tickiti bestätigt, dem das Repo gehört
Dieses Repo haben wir noch nicht von GitHub gelesen
Dieses Repo haben wir noch nicht von GitHub gelesen
Dieser Server läuft auf deinem Computer; es gibt keinen Endpunkt im Internet
Läuft auf deinem Computer und nutzt stattdessen lokale Einstellungen
Läuft auf deinem Computer; Tool-Listen können wir nur von Endpunkten im Internet lesen
Verglichen mit allen aktiven Servern dieser Kategorie in der Registry. Sterne zählen nur, wenn dem Herausgeber das Repo gehört.
Er hat 1 von 1 zutreffenden Basischecks bestanden. Den Code haben wir nicht gelesen. Bevor du einen Schlüssel oder Token hinzufügst, sieh nach, welche Zugriffe der Server verlangt, und nutze einen Schlüssel, der nur die Berechtigungen hat, die du brauchst.
Die Registry nennt keinen erforderlichen Schlüssel, manche Server bitten dich aber bei der ersten Nutzung, dich anzumelden.
Er läuft auf deinem Computer. Deine KI-App startet ihn bei Bedarf, und die Daten laufen nicht über die Server des Entwicklers (außer der Server ruft selbst einen Onlinedienst auf).
Das GitHub-Repo wurde zuletzt – geändert, und die neueste Version (0.2.0) kam vor 33 Tagen in die Registry.
Apps, die MCP unterstützen, etwa Claude Desktop, Claude Code, Cursor und VS Code.
In derselben Kategorie: Spec Driven Development, Remote Desktop Commander, Reelsaw
Server derselben Kategorie von anderen Entwicklern, sortiert nach Sternen.
So liest du eine Karte:★ GitHub-SterneiDrei Säulen: Bewertungen · Checks · NutzungiAktualisiert = neueste Version in der Registry veröffentlichti
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.
Drive a self-hosted Reelsaw: turn long videos into vertical clips, edit, re-render and export them.
Unverändert aus dem Repo des Entwicklers übernommen. PopNx MCP hat den Inhalt weder geprüft noch empfiehlt es ihn. HTML, Bilder und Skripte wurden entfernt. Links führen von dieser Website weg.
An MCP (Model Context Protocol) server that exposes the Tickiti helpdesk API to AI assistants such as Claude. It is a thin shim over the Tickiti Public API v1 (/api/v1/...): each MCP tool forwards to a v1 endpoint, adding your bearer token and — for writes — an idempotency key. The token's abilities are the security boundary: the server only relays calls, it never widens them, so a read-only token gives a read-only assistant.
📖 Full documentation: https://www.tickiti.com/docs/topic/mcp_server/
The ticket tools have full, validated inputs; the rest of the API is reachable through two general tools, so the whole surface is available without a separate tool per endpoint.
Tickets
| Tool | Ability | Purpose |
|---|---|---|
create_ticket | tickets:write | Open a ticket (subject+content, template, or intervention), with assignee, priority, status and participants; is_public is required |
respond_to_ticket | tickets:write | Post a response; change status, hold, assignee, priority, queue, subject, participants; send_full_email for the whole reply by email |
close_ticket | tickets:write | Close, optionally with a final reply and a resolution |
edit_response | tickets:write | Change a response in place (whole body, find/replace, visibility) with no notification — or publish an internal note and notify |
delete_response | tickets:write | Soft-delete a response |
add_participants / remove_participants | tickets:write | Change participants |
delete_tickets / restore_ticket | tickets:write | Delete tickets (by number, or everything from one sender) and undo it |
merge_tickets | tickets:write | Merge two tickets (the older survives) |
link_tickets / unlink_tickets / list_linked_tickets | tickets:write / read | The Linked panel |
move_responses / copy_responses / split_ticket | tickets:write | Repair a thread: move or copy responses, or split them off into a new linked ticket |
change_originator | tickets:write | Change who raised a ticket |
delete_attachment | tickets:write | Remove one attachment (a malicious file, say), keeping a record of it |
get_ticket / list_responses | tickets:read | A ticket's thread, participants and links; fields / max_body_chars keep long email threads small |
get_response | tickets:read | One response by id |
query_tickets | tickets:read | Search tickets |
query_responses / export_responses | tickets:read | Responses across tickets; counts and group-by tallies; NDJSON export to disk |
get_attachment / download_attachment | tickets:read | Attachment bytes (download streams any size to a file) |
list_queues / list_teams / list_staff / list_resolutions / get_search_modes | tickets:read | Queue names and settings, team keys, staff addresses, resolution categories, the search vocabulary |
Settings, templates, mail, administration
| Tool | Ability | Purpose |
|---|---|---|
list_perspectives / get_perspective | settings:read | Saved views, with conditions and sort orders |
list_watchlists | settings:read | Watchlists |
list_stock_responses / get_stock_response | settings:read | Stock responses (search, bodies) |
create_stock_response / update_stock_response / delete_stock_response | settings:write | Edit stock responses |
get_template / search_templates / render_template | templates:read | Templates and FAQs; render one against data without sending |
create_template / update_template | templates:write | Edit templates (updates change only the fields given) |
upload_template_image | templates:write / settings:write | Upload an image for a template or stock response |
send_email / search_sent_mail | mail:write / mail:read | Send mail; search what was sent |
list_api_tokens / create_api_token / update_api_token / revoke_api_token | administration:* | API keys (a token only grants abilities it holds) |
list_workflow | workflow:read | Resolution categories, interventions, escalations |
run_report | reports:read | Analytics reports |
get_token_info | any | What this token can do: abilities, owner roles, plan |
list_instances | — | The Tickiti instances configured (see below) |
list_endpoints | — | Every API endpoint, with abilities, path and body parameters |
tickiti_call | per endpoint | Call any /api/v1 endpoint by family and action |
For anything beyond the named tools (mail, templates, workflow writes, administration, supervisor), the assistant uses list_endpoints to discover the action, then tickiti_call to run it — covering all of the v1 API.
git clone https://github.com/tickiti/tickiti-mcp.git
cd tickiti-mcp npm install npm run build
The built server is dist/server.js.
The server reads two environment variables (it fails fast on startup if either is missing):
| Variable | Purpose |
|---|---|
TICKITI_API_BASE | Your Tickiti install's public address, no trailing slash — e.g. https://support.example.com. The server appends /api/v1/…. |
TICKITI_API_TOKEN | The bearer token. Its abilities determine what the assistant can do. |
To reach several Tickiti installs from one server (production and staging, say), add TICKITI_INSTANCES: JSON, or the path of a JSON file, mapping a name to { "base", "token" }. The TICKITI_API_BASE / TICKITI_API_TOKEN pair stays the default instance, named by TICKITI_INSTANCE_NAME (default default).
TICKITI_INSTANCE_NAME=production
TICKITI_INSTANCES='{"staging": {"base": "https://staging.example.com", "token": "…"}}'
Every tool then takes an optional instance argument; list_instances shows the names.
claude mcp add tickiti \
--env TICKITI_API_BASE=https://support.example.com \ --env TICKITI_API_TOKEN=YOUR_TICKITI_API_TOKEN \ -- node /absolute/path/to/tickiti-mcp/dist/server.js
Confirm with claude mcp list (or /mcp in a session). Remove with claude mcp remove tickiti.
Other MCP clients configure servers in their own settings file, but the shape is the same: run node /absolute/path/to/tickiti-mcp/dist/server.js as a stdio server with TICKITI_API_BASE and TICKITI_API_TOKEN set in its environment.
The server adds no permissions of its own. Every call runs as the staff user the token belongs to, gated by the token's abilities — exactly as a direct API call would be. To limit what an assistant can do, mint a narrowly-scoped token:
tickets:read, reports:read) gives an assistant that can look but not change anything.The ticket-writing tools send an idempotency key with every call, so a retried request never creates a duplicate ticket or response.
Long bodies can be given as content_path (a local file) instead of content, and files and images always go by path: the server reads them, so their bytes never pass through the model.
| File | Role |
|---|---|
src/client.ts | Request core: base URL, bearer auth, idempotency, error normalisation |
src/result.ts | Maps an API result into the MCP tool-result envelope |
src/manifest.ts | Helpers over the generated route manifest (lookup, path building) |
src/generated/manifest.ts | Auto-generated route table (do not edit) |
src/tools/tickets.ts | Ticket writes — verified input schemas |
src/tools/ticket-reads.ts | Ticket, response and attachment reads |
src/tools/ticket-operations.ts | Delete, merge, link, move, originator, attachment delete, lookups |
src/tools/settings-writes.ts | Stock responses and templates |
src/tools/admin.ts | Mail, template rendering and images, perspectives, API keys, instances |
src/tools/reads.ts | Named read tools (settings / workflow / reports) |
src/tools/generic.ts | list_endpoints + tickiti_call |
src/param-hints.ts | Body parameters list_endpoints shows for endpoints without a dedicated tool |
src/server.ts | Entry point: registers tools, connects the stdio transport |
scripts/build-manifest.mjs | Regenerates the manifest from the Tickiti route table |
src/generated/manifest.ts is generated from Tickiti's own route table (php artisan route:list --json), so abilities, roles, plan gates and path params are never hand-maintained. Regenerate against a Tickiti checkout after the API changes:
TICKITI_DIR=/path/to/tickiti npm run manifest
There is an end-to-end sweep over every endpoint in tests/all-paths.mjs (npm run test:paths, needs a base URL and a full-ability token against a scratch instance), and an offline check of the tool registration in tests/smoke-tools.mjs (npm run build && node tests/smoke-tools.mjs).
Several tools call endpoints added to Tickiti in October 2026. Against an older install they return 404; list_endpoints describes the newest API.
MIT © Oxenic