Server data from the Official MCP Registry
Connect AI assistants to the Tickiti helpdesk API: tickets, queries, reports and admin.
Connect AI assistants to the Tickiti helpdesk API: tickets, queries, reports and admin.
This is a well-designed MCP server that acts as a secure thin shim over the Tickiti API. Authentication and authorization are properly delegated to the underlying Tickiti API via bearer tokens with scope-based access control. The codebase is clean with appropriate input validation via Zod, proper error handling, and no malicious patterns detected. Minor code quality concerns around broad error handling and lack of request/response logging do not significantly impact security. Supply chain analysis found 3 known vulnerabilities in dependencies (0 critical, 3 high severity).
4 files analyzed · 6 issues found
Security scores are indicators to help you make informed decisions, not guarantees. Always review permissions before connecting any MCP server.
This plugin requests these system permissions. Most are normal for its category.
Add this to your MCP configuration file:
{
"mcpServers": {
"io-github-tickiti-tickiti-mcp": {
"args": [
"-y",
"tickiti-mcp"
],
"command": "npx"
}
}
}From the project's GitHub README.
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://docs.tickiti.com/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.
| Tool | Ability | Purpose |
|---|---|---|
create_ticket | tickets:write | Open a ticket (subject+content, template, or intervention) |
respond_to_ticket | tickets:write | Post a response to an existing ticket |
query_tickets | tickets:read | List tickets for a perspective |
list_perspectives | settings:read | List saved perspectives |
list_watchlists | settings:read | List watchlists |
list_stock_responses | settings:read | List stock responses |
list_queues | workflow:read | List ticket queues |
list_workflow | workflow:read | List resolution categories, interventions or escalations |
run_report | reports:read | Run an analytics report |
list_endpoints | — | Discover every available API endpoint, with abilities and 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. |
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 two ticket-writing tools send an idempotency key with every call, so a retried request never creates a duplicate ticket or response.
| 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 | Tickets family — verified input schemas |
src/tools/reads.ts | Named read tools (settings / workflow / reports) |
src/tools/generic.ts | list_endpoints + tickiti_call |
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).
MIT © Oxenic
Be the first to review this server!
by Modelcontextprotocol · Developer Tools
Read, search, and manipulate Git repositories programmatically
by Modelcontextprotocol · Developer Tools
Web content fetching and conversion for efficient LLM usage
by Toleno · Developer Tools
Toleno Network MCP Server — Manage your Toleno mining account with Claude AI using natural language.