The Xalantis MCP Server connects MCP-compatible AI clients to the Xalantis business platform, enabling interaction with business data across multiple domains via the /api/v1 API.
Support / Service Desk
List tickets with filters (status, priority, requester email, search text), sorting, and pagination
Get full details of a single ticket by UUID
Create new tickets (subject, description, requester info, priority, category, channel)
Update existing tickets (status, priority, assignee, SLA due date, etc.)
Add public replies or internal notes (agent-only) to tickets
List all replies/notes for a ticket
Manage ticket lifecycle: merge, split, archive, delete, approve/reject/fulfill service requests
CRM
Manage clients, contacts, representatives, deals, and sales pipelines
Knowledge Base
Search and manage articles and categories
Billing & Finance
View subscription details and invoices
Read finance invoices and expenses (read-only)
Contracts
Manage contracts, comments, negotiations, obligations, approvals, signatures, clauses, requests, PDF designs, assets, and assignments
File Transfers
Upload attachments to tickets and other endpoints
Download files (returns base64 or saves to a local output_path)
Safety / Confirmation Model
Destructive or sensitive actions (create, update, delete, public replies, approvals, file downloads, etc.) require explicit confirm: true to prevent accidental execution
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Xalantis MCP Server list all open high-priority tickets"
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.
MCP server for Xalantis. It lets MCP-compatible AI clients read and act on Xalantis business data through the public /api/v1 API.
Release 0.2.0 covers every current public /api/v1 endpoint exposed by Xalantis at the time of release.
npm install -g @xalantis/mcp-serverRelated MCP server: gorgias-mcp
Add to claude_desktop_config.json:
{
"mcpServers": {
"xalantis": {
"command": "npx",
"args": ["-y", "@xalantis/mcp-server"],
"env": {
"XALANTIS_API_KEY": "sk_live_..."
}
}
}
}claude mcp add xalantis -- npx -y @xalantis/mcp-serverThen set XALANTIS_API_KEY in the shell/session that launches the MCP server.
Add to .cursor/mcp.json:
{
"mcpServers": {
"xalantis": {
"command": "npx",
"args": ["-y", "@xalantis/mcp-server"],
"env": {
"XALANTIS_API_KEY": "sk_live_..."
}
}
}
}Support / Service Desk: tickets, replies, attachments, reports, links, watchers, time entries, subtasks, incidents, service requests, SLA, automations, categories, tags, service catalog, agents.
CRM: clients, representatives, contacts, deals, pipelines.
Knowledge: articles, search, categories.
Billing: subscription and invoices.
Finance: invoices and expenses read-only APIs.
Contracts: contracts, comments, negotiations, obligations, approvals, signatures, clauses, requests, PDF designs, assets, assignments.
Tools that mutate data or may expose sensitive data require a confirm: true argument. The AI client should only pass this after the user explicitly confirms the action.
Examples of confirmed actions:
creating, updating or deleting records;
sending public ticket replies;
approving, rejecting, fulfilling or reopening service requests;
merging, splitting, archiving or deleting tickets;
requesting contract signatures;
downloading attachments or reports;
uploading files.
If confirmation is missing, the tool returns an error explaining that confirmation is required.
Binary endpoints are supported through file-aware tools:
{
"ticket_uuid": "ticket-uuid",
"file_path": "/local/path/evidence.pdf",
"confirm": true
}Downloads can either return base64 or write to a local path:
{
"ticket_uuid": "ticket-uuid",
"attachment_uuid": "attachment-uuid",
"output_path": "/tmp/evidence.pdf",
"confirm": true
}When output_path is omitted, the tool returns metadata plus base64 content.
Once connected, an MCP-compatible assistant can answer or act on prompts such as:
“List open urgent tickets and summarize the oldest ones.”
“Find client Acme and show related contacts.”
“Search the knowledge base for SLA configuration.”
“Create a ticket for this incident after I confirm.”
“Add an internal note to this ticket.”
“Show contract obligations due this month.”
“Submit this contract for approval after confirmation.”
“Download this ticket report to /tmp/report.xlsx.”
Variable | Required | Description |
| Yes | Tenant API key used for Xalantis |
The MCP server does not bypass Xalantis backend permissions, plan gates, tenant scoping or rate limits.
Destructive and externally visible actions require confirm: true.
File downloads can contain sensitive tenant data; use output_path carefully.
API keys should be stored in the MCP client environment configuration, not in prompts.
npm ci
npm run lint
npm run buildMIT
Create a new support ticket
| Name | Required | Description | Default |
|---|---|---|---|
| channel | No | Channel source | |
| subject | Yes | Ticket subject | |
| priority | No | Priority level (default: medium) | |
| description | Yes | Ticket description | |
| category_slug | No | Category slug | |
| requester_name | No | Name of the requester | |
| requester_email | Yes | Email of the person reporting the issue |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the creation action without any details on side effects, authentication requirements, rate limits, or what happens upon creation. The description lacks transparency regarding system behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no waste, achieving high conciseness. However, it is very brief and could benefit from slight elaboration without losing structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, 3 required, and no output schema, the description is incomplete. It does not explain return values, confirmation of creation, or any behavioral context beyond the basic action. More detail is needed for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 7 parameters. The description does not add any meaning beyond the schema, but baseline is 3 due to high coverage. No additional parameter context is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new support ticket', using a specific verb ('Create') and resource ('support ticket'). It distinguishes from sibling tools like update_ticket, get_ticket, and list_tickets by indicating a creation action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates use for creating tickets but provides no explicit guidance on when to use this tool versus alternatives, nor does it specify prerequisites or exclusions. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single ticket by UUID
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | Ticket UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description states 'Get' suggesting a read operation, but lacks disclosure of side effects, permissions, or return format. For a read tool, more detail on behavior would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no unnecessary words. Front-loaded with verb and resource. Every word is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and only one parameter, the description is minimal. It does not explain return values or error behavior (e.g., if ticket not found). For a get tool, this omission reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with 'Ticket UUID' for the uuid parameter. The description adds no extra meaning beyond the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and resource 'a single ticket' with the method 'by UUID', clearly differentiating from sibling tools like list_tickets (multiple) and create_ticket (mutation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use vs alternatives. The purpose is implied (fetch one ticket by UUID), but there is no mention of when not to use or comparison with list_tickets or update_ticket.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all replies and notes for a ticket
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number | |
| per_page | No | Results per page | |
| ticket_uuid | Yes | Ticket UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but only states 'list all replies and notes'. It does not mention that the operation is read-only, how pagination works (despite page/per_page in schema), or any ordering. The agent gains no safety or behavioral insight 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no waste. It is front-loaded with the core purpose. However, it is so brief that it sacrifices useful context, preventing a maximum score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, yet the description does not specify the return structure (e.g., fields in each reply, whether notes are included). For a list operation with 3 parameters, this omission leaves the agent uncertain about the response format, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter. The description adds no additional meaning or context about how parameters like 'ticket_uuid', 'page', or 'per_page' should be used, resulting in baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and resource 'all replies and notes for a ticket', distinguishing it from sibling tools like 'reply_to_ticket' (create) and 'get_ticket' (view ticket details). However, it could be more precise by specifying that it includes both public replies and internal notes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios where 'get_ticket' or 'reply_to_ticket' might be more appropriate, nor does it offer any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List support tickets with optional filters and pagination
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number | |
| search | No | Search in subject and description | |
| status | No | Filter by status | |
| sort_by | No | Sort field | |
| per_page | No | Results per page (max 100) | |
| priority | No | Filter by priority | |
| sort_dir | No | Sort direction | |
| requester_email | No | Filter by requester email |
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 only mentions listing, but doesn't state it's non-destructive, clarify auth needs, or describe rate limits or behavior with no results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the core functionality, but could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 optional parameters and no output schema, the description fails to mention return format, default pagination, or what happens when filters yield no results, leaving the agent with incomplete information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all parameters with descriptions, so the description adds no additional meaning beyond what's already available.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists support tickets with optional filters and pagination, distinguishing it from siblings like create_ticket and get_ticket.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing with filters but lacks explicit guidance on when to use this versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a reply or internal note to a ticket
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | Reply content | |
| is_internal | No | Set to true for an internal note (not visible to requester) | |
| ticket_uuid | Yes | Ticket UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It does not mention whether the ticket must be open, if notifications are sent, or what side effects occur (e.g., status changes). The only behavioral insight is that internal notes are not visible to the requester.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but arguably too brief. It lacks structure or front-loading of key information. A second sentence clarifying common use cases would improve it without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters, no output schema, and no annotations, the description is insufficient. It does not cover return values, prerequisites (e.g., ticket existence), or error conditions. The definition leaves significant gaps for an agent to understand correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all three parameters have descriptions). The description adds context by explaining that is_internal controls visibility, but does not go beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a reply or internal note') and the resource ('to a ticket'). It distinguishes itself from sibling tools like create_ticket (creates a new ticket) and list_ticket_replies (lists existing replies), making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., when to use is_internal vs a public reply, or when list_ticket_replies might be more appropriate). It only implies usage through the action description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing ticket (status, priority, subject, etc.)
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | Ticket UUID | |
| due_at | No | SLA due date (ISO 8601) | |
| status | No | New status | |
| subject | No | New subject | |
| priority | No | New priority | |
| assignee_id | No | Assign to agent by ID | |
| description | No | New description | |
| category_slug | No | Category slug |
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 indicates a mutation operation but lacks details on side effects, permissions, idempotency, or update behavior (e.g., partial vs full overwrite).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the action and resource, with no redundant phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 8 parameters, no output schema, and no annotations, the description is minimally complete. It covers the purpose and basic scope but does not explain return values or partial update semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter. The description lists some fields (status, priority, subject) overlapping with the schema, but does not add meaningful new information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update an existing ticket' with examples of updatable fields like status, priority, subject, etc. It effectively distinguishes from sibling tools such as create_ticket, get_ticket, list_tickets, and reply_to_ticket.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for modifying existing tickets, but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusion criteria or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0create_ticketget_ticketlist_ticket_replieslist_ticketsreply_to_ticketupdate_ticketEach tool has a clear, distinct purpose: creating, retrieving, listing, replying to, updating tickets, and listing replies. No two tools overlap in functionality.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_ticket, list_tickets, reply_to_ticket), making them predictable and easy to understand.
Six tools is an appropriate number for a focused ticketing system. Each tool addresses a core operation without unnecessary redundancy or bloat.
The tool set covers the main lifecycle of a ticket: create, read, update, list, and add replies. A delete ticket or advanced search tool is missing, but these are minor gaps for a basic implementation.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
List, search, create, update, and reply to support tickets across your Dispatch Tickets brands.
Read tickets, contacts, companies, agents and groups; create, update and reply to tickets.
Run AI customer support from your terminal: conversations, knowledge base, and chat widget.
Build and manage AI-native customer support agents from Claude or any MCP client.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/xalantis-hub/xalantis-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
