How do I use tickiti-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@tickiti-mcp create a ticket about network latency in the office" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

tickiti-mcp

Official

by tickiti

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

tickiti-mcp

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/

Tools

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.

Related MCP server: Gorgias MCP Server

Requirements

Node.js 20 or newer
A Tickiti API token, minted from Administration → API keys, scoped to the abilities you want the assistant to have
An MCP-capable client — e.g. Claude Code or the Claude desktop app

Install

git clone https://github.com/tickiti/tickiti-mcp.git
cd tickiti-mcp
npm install
npm run build

The built server is dist/server.js.

Configure

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.

Use with Claude Code

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.

Permissions & security

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:

A read-only token (e.g. tickets:read, reports:read) gives an assistant that can look but not change anything.
Grant write abilities only for the families the assistant needs to act on.
If a call is refused, the server reports the reason (missing ability, role or plan).

The two ticket-writing tools send an idempotency key with every call, so a retried request never creates a duplicate ticket or response.

How it works

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

Maintainers

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).

License

MIT © Oxenic

Available Tools

11 tools

create_ticketCreate ticketA

Create a support ticket. Provide originator_email_address and EXACTLY ONE of: subject+content, OR template_identifier+data, OR intervention+data+uid. Omit queue_name to use the Inbox; queue_name is not allowed with intervention.

ParametersJSON Schema

Name	Required	Description
`originator_email_address`	Yes
`subject`	No	Pair with content (subject+content path)
`content`	No	HTML body; pair with subject
`template_identifier`	No	Template.identifier; pair with data
`intervention`	No	Intervention.name; pair with data and uid
`uid`	No	Required only when intervention is set
`data`	No	Token values for template/intervention paths
`queue_name`	No	TicketQueue.name; omit for Inbox
`is_public`	No
`use_passed_originator_as_responder`	No

TDQS

A3.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must convey behavioral traits. It only covers input constraints (mutual exclusivity, queue_name restriction) but does not mention side effects, permissions, idempotency, or return values. This is insufficient for an agent to understand the tool's behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that front-loads the main action and efficiently conveys all essential constraints without extraneous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description adequately covers input constraints for a tool with 10 parameters and conditional groups. However, it lacks information about return values, error handling, and omits any mention of is_public or use_passed_originator_as_responder. No output schema is provided, leaving the agent with gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 70% schema coverage, the description adds significant value by clearly defining the three mutual exclusive parameter paths and the restriction on queue_name. It groups related parameters semantically, which is not evident from the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create a support ticket' and specifies the exact three ways to provide content (subject+content, template+data, or intervention+data+uid). This distinguishes it from siblings like query_tickets or respond_to_ticket.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly instructs to provide EXACTLY ONE of three parameter groups and notes when queue_name is not allowed. However, it does not provide high-level guidance on when to use this tool versus others, such as for updating vs. creating.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_endpointsList Tickiti API endpointsA

Discover available Tickiti v1 endpoints. Optionally filter by family (one of: administration, idempotency_key, mail, reports, settings, supervisor, templates, tickets, workflow). Returns each endpoint's action key, required abilities, role, plan gates and path params — use these with tickiti_call.

ParametersJSON Schema

Name	Required	Description	Default
`family`	No	Filter to one family: administration, idempotency_key, mail, reports, settings, supervisor, templates, tickets, workflow

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It accurately describes a read-only discovery operation and lists the returned fields (action key, required abilities, etc.), providing sufficient transparency for a simple list tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: only two sentences. The first sentence states the main purpose, and the second adds details and usage guidance. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with a single optional parameter, the description is fully complete. It explains what the tool does, what it returns, and how to use the output, despite the lack of an explicit output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the description repeats the same information from the schema (the optional 'family' parameter and its possible values). It adds no new meaning beyond what the schema already provides, meeting the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Discover available Tickiti v1 endpoints.' It uses a specific verb ('discover/list') and resource ('endpoints'), and it is distinct from sibling tools that list other entities like queues or perspectives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains optional filtering by family and explicitly guides the agent to use the returned data with 'tickiti_call'. While it doesn't state when not to use the tool or name alternatives, the context is clear and helpful.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_perspectivesList saved perspectives (views)D

List saved perspectives (views)

ParametersJSON Schema

Name	Required	Description	Default
`filters`	No	Optional filter/query payload

TDQS

D1.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description implies a read-only listing operation but provides no details about behavior, such as pagination, filtering impact, or data delivery. With no annotations, this is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is overly terse, sacrificing informativeness for brevity. It is under-specified rather than appropriately concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of annotations and output schema, the description fails to provide essential context about the tool's purpose, parameter usage, or expected results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the schema describes the parameter. The description adds no value beyond the schema, meeting the baseline expectation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tautological: description restates name/title.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus alternatives like list_endpoints or list_queues; the description lacks any contextual clues for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_queuesList ticket queuesD

List ticket queues

ParametersJSON Schema

Name	Required	Description	Default
`filters`	No	Optional filter/query payload

TDQS

D1.3/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits, but it only states a list operation. No details on pagination, rate limits, or whether the call is read-only are given.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely short (one sentence), but it is under-specified rather than concise. It fails to provide essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity (one optional parameter, no output schema), the description is incomplete. It lacks explanation of what queues represent, how filters apply, and expected return structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single parameter 'filters', but the description adds no meaning beyond the schema. It does not explain acceptable filter properties or usage, falling short of the baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tautological: description restates name/title.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use list_queues versus alternatives, nor any prerequisites or context for its application.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_stock_responsesList stock (canned) responsesD

List stock (canned) responses

ParametersJSON Schema

Name	Required	Description	Default
`filters`	No	Optional filter/query payload

TDQS

D1.9/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description gives no behavioral details (e.g., authentication, pagination, side effects). This leaves the agent uninformed about critical usage traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is overly brief, essentially a tautology. It is underspecified rather than concise, failing to provide valuable information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Without output schema or behavioral hints, the description omits essential details like response structure, pagination, or filter format, making it incomplete for a list tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a basic description for the single parameter. The tool description adds no further context, but param meaning is already conveyed by the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tautological: description restates name/title.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The tool description fails to indicate any context or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_watchlistsList watchlistsD

List watchlists

ParametersJSON Schema

Name	Required	Description	Default
`filters`	No	Optional filter/query payload

TDQS

D1.3/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations and minimal description, the tool's behavior is opaque. It does not disclose whether the operation is read-only, if authentication is required, or any side effects. The description adds no value beyond the tool name.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

While the description is extremely concise, it sacrifices necessary clarity and completeness. It is too short to be useful; it should be at least one full sentence with meaningful context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that the tool has no annotations, no output schema, and sibling tools with similar semantics, the description is far from complete. It fails to explain what a watchlist is, how filters work, or what the tool returns.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100% (one parameter described), the description does not add any meaning beyond the schema. The 'filters' parameter is an open-ended object, and the description could provide examples or constraints, but it does not.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tautological: description restates name/title.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus alternatives such as list_perspectives or list_queues. There is no mention of prerequisites, filters, or typical use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_workflowList workflow configurationB

List a plan-gated workflow collection: resolution-categories, interventions, or escalations. Returns 403 if the instance's plan does not include the feature.

ParametersJSON Schema

Name	Required	Description	Default
`kind`	Yes
`filters`	No

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses the 403 error when the plan lacks the feature, but does not cover other behaviors like pagination or sorting; with no annotations, the description carries the burden but only partially meets it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two efficient sentences: first defines purpose and scope, second adds a critical error condition. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a simple list tool with one required enum parameter, but the unexplained nested `filters` object and lack of output schema details leave gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description only restates the enum values for `kind` which are already in the schema, and provides no insight into the `filters` parameter, leaving it entirely unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists plan-gated workflow collections for three specific kinds (resolution-categories, interventions, escalations), which is distinct from sibling list tools that target different resources.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like list_endpoints or list_queues; only implies plan eligibility via the 403 error.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

query_ticketsQuery ticketsA

List tickets for a perspective (saved view). Specify perspective_id or perspective_name; defaults to the 'All' perspective. Pass a ticket number via search_object for a direct lookup.

ParametersJSON Schema

Name	Required	Description
`perspective_id`	No
`perspective_name`	No	Resolved server-side via search_object.search_perspective
`search_object`	No	Raw search payload, e.g. { search_perspective, search_perspective_id, ... }

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. Discloses it's a list operation and can do direct lookup, but doesn't mention read-only nature, auth requirements, or rate limits. Adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with no fluff, front-loading purpose and usage. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers main use cases well given no output schema and three parameters. Could mention output format or pagination, but for a list tool it's fairly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Adds meaning beyond schema: explains defaults for perspective_id/name and clarifies search_object role as direct lookup. Schema coverage is 67%, and description compensates effectively.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List tickets for a perspective' with specific verb and resource, and distinguishes from sibling tools like create_ticket and respond_to_ticket by focusing on listing and direct lookup.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit guidance on specifying perspective_id or perspective_name, defaulting to 'All', and using search_object for direct lookup. Lacks explicit when-not scenarios, but context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

respond_to_ticketRespond to ticketA

Add a response to an existing ticket (reopens it if closed). Set is_internal=true for a staff-only note.

ParametersJSON Schema

Name	Required	Description
`ticket_number`	Yes	Ticket.number (the human ticket reference)
`from_email`	Yes	Author email; added as a participant if new
`content`	Yes	Response body (HTML)
`is_internal`	No

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It mentions reopening and internal notes, but lacks details on permissions, visibility, side effects, or return value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: one sentence with a key usage hint. Every word is purposeful and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations or output schema, the description covers the main action and reopening behavior, but omits error handling, prerequisites, and response format, leaving gaps for an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds meaning beyond the schema, especially for is_internal which has no schema description. It clarifies the role of each parameter (e.g., from_email added as participant).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool adds a response to an existing ticket, distinguishes from create_ticket by specifying 'existing ticket', and mentions reopening behavior and internal note functionality.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use (responding to existing tickets) vs alternatives like create_ticket, but does not explicitly mention other siblings or provide when-not scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

run_reportRun an analytics reportA

Run a Tickiti analytics report (requires the reports plan + admin). 'meta' returns the filterable queues; the others accept date/queue filters via filters.

ParametersJSON Schema

Name	Required	Description	Default
`report`	Yes
`filters`	No	e.g. { from, to, queue_id }

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses auth requirements and the special behavior of 'meta' vs. other reports. However, it does not mention side effects, error conditions, or rate limits. The behavioral info is adequate but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two sentences, front-loading the core purpose. Every sentence adds value, though it could be slightly more structured. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema is provided, so the description should explain return values. It mentions 'meta' returns filterable queues but not what others return. Also lacks details on pagination or result format. Given the tool's complexity, it is partially complete but has gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50%, and the description adds the distinction between 'meta' and other reports regarding filters. However, the schema already describes the filter parameter example. The description provides modest additional value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Run a Tickiti analytics report' with specific report types (meta, resolutions, etc.) and distinguishes from siblings like query_tickets and list_endpoints. It uses a specific verb and resource, making the tool's purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides prerequisites ('requires the reports plan + admin') and explains when to use 'meta' versus other reports ('returns the filterable queues; the others accept date/queue filters'). It does not explicitly state when not to use or name alternatives among siblings, but the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

tickiti_callCall any Tickiti v1 endpointA

Advanced escape hatch: invoke any Tickiti v1 endpoint not covered by a dedicated tool. Use list_endpoints first to find the family + action. payload becomes the JSON request body; for endpoints with path params (e.g. user, queue) include those keys in payload too.

ParametersJSON Schema

Name	Required	Description
`family`	Yes	One of: administration, idempotency_key, mail, reports, settings, supervisor, templates, tickets, workflow
`action`	Yes	Action key from list_endpoints, e.g. 'queues.index'
`payload`	No	JSON request body (and any path-param values)

TDQS

A3.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description lacks details on whether the tool is read-only or mutating, authentication requirements, rate limits, or side effects. It only mentions that payload becomes the JSON body and path params.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences efficiently convey purpose and usage instructions without redundancy. Front-loaded with key purpose, then clear actionable guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description should explain return format or error handling, which it does not. It also lacks mention of authentication prerequisites or expected behaviors for common endpoints.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers all parameters (family, action, payload). Description adds value by explaining that family is one of the listed strings, action comes from list_endpoints, and payload includes path-param values, going beyond the schema's descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it is an advanced escape hatch for invoking Tickiti v1 endpoints not covered by dedicated tools, and specifies that it uses family and action from list_endpoints. This distinguishes it from sibling tools like create_ticket or list_endpoints.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description instructs to use list_endpoints first to find the family and action, providing clear guidance on preparation. However, it does not explicitly state when not to use it (e.g., prefer dedicated tools).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

11 tool updatesv0.1.0Jun 7, 2026
- First observedcreate_ticket
- First observedlist_endpoints
- First observedlist_perspectives
- First observedlist_queues
- First observedlist_stock_responses
- First observedlist_watchlists
- First observedlist_workflow
- First observedquery_tickets
- First observedrespond_to_ticket
- First observedrun_report
- First observedtickiti_call

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.1/5.0

Scored 2026-06-07 18:50 across 11 tools

Disambiguation5/5

Each tool targets a distinct operation: ticket creation, listing different resources, querying, responding, reporting, and an escape hatch. No overlapping purposes.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern using snake_case (e.g., create_ticket, list_endpoints, query_tickets). Even the generic 'tickiti_call' fits the pattern.

Tool Count5/5

11 tools is well-scoped for a ticket management system, covering creation, listing, querying, responding, reporting, and advanced operations without unnecessary bloat.

Completeness4/5

The set covers the main ticket lifecycle (create, query, respond) and auxiliary lists. Minor gaps like explicit close or update are mitigated by the generic tickiti_call tool, so agents can work around them.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

OneSchema MCP Server
co.oneschema
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
Data Platforms App Automation
1
jumpcloud-genaiOAuth
com.jumpcloud
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Cloud Platforms Security Developer Tools
2
mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
ZapierOAuth
com.zapier
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
App Automation Workplace & Productivity
2297

Related MCP Servers

jitbit-helpdesk-mcpofficial
Customer Support Search App Automation
jitbit
A
license
A
quality
D
maintenance
An MCP server that lets AI assistants search and read support tickets from Jitbit Helpdesk. Works with both SaaS and on-premise installations.
Updated 5 months ago (2026-04-29 15:02 UTC)
3
16 npm
3
MIT
Gorgias MCP Server
Customer Support Communication
benpalmer1
A
license
A
quality
C
maintenance
An MCP server that exposes the full Gorgias helpdesk API to AI assistants, enabling ticket management, analytics, and customer operations through natural language.
Updated 5 months ago (2026-04-16 03:07 UTC)
100
528 npm
2
MIT
TDX MCP Server
Customer Support Search Documentation Access
uidaho-nsummers
F
license
Not graded
quality
D
maintenance
An MCP server that wraps the TeamDynamix Web API, enabling AI assistants to search tickets, manage assets, query the knowledge base, and look up people in your TDX instance.
Updated 3 months ago (2026-06-11 03:04 UTC)
1
-
ticksy-mcp
Customer Support CRM
artkrsk
A
license
A
quality
C
maintenance
MCP server for the Ticksy support ticket API, enabling AI agents to read and write support tickets.
Updated 2 months ago (2026-07-24 16:18 UTC)
16
4 npm
MIT

tickiti-mcp

Tools

Requirements

Install

Configure

Use with Claude Code

Permissions & security

How it works

Maintainers

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

jitbit-helpdesk-mcpofficial