How do I use servicedesk-plus?

1. Click on "Install 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., "@servicedesk-plus 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.

servicedesk-plus

by kaattaalan

Overview Schema Related Servers Score Discussions

Python

Remote

ServiceDesk Plus Model Context Protocol (MCP) Server

Python Version License: MIT

A production-ready Model Context Protocol (MCP) server that connects large language models (LLMs) securely with your ManageEngine ServiceDesk Plus (On-Premise / Self-Hosted) instance. This server allows AI agents (such as Claude Desktop, Cursor, and other MCP hosts) to query, search, create, update, and manage help desk tickets and technical notes in real-time.

🛠️ Features

List & Search Tickets: Rich server-side filtering by status, requester email, and advanced subject-contains keyword queries.
Get Ticket Details: Retrieve comprehensive information on a single ticket, including its subject, description, priority, and resolution content.
Create Tickets: Seamlessly open new help desk requests with custom subjects, HTML/plain-text descriptions, and priorities.
Update Tickets: Real-time updates to ticket statuses, descriptions, and subjects.
Manage Technical Notes: Exposes tools to list and append technical updates directly onto tickets.
Public & Secure: Rigorously designed for open-source safety. Zero hardcoded secrets, domains, or credentials.
Classic UI Integration: Automatically generates browser-viewable deep links tailored for the Classic UI layout.
Complete Offline Testing: Includes a 100% offline unit test suite with mock network interception (respx).

Related MCP server: freshservice-mcp

📐 Architecture Overview

 ┌─────────────────┐             ┌────────────────────┐             ┌─────────────────────┐
 │                 │    Stdio    │                    │    HTTPS    │  ManageEngine       │
 │    MCP Host     │  ─────────> │  servicedesk-plus  │  ─────────> │  ServiceDesk Plus   │
 │ (e.g. Claude)   │  <───────── │     (MCP Server)   │  <───────── │  (On-Premise API)   │
 │                 │             │                    │ (authtoken) │                     │
 └─────────────────┘             └────────────────────┘             └─────────────────────┘

📋 MCP Tools Exposed

This server exposes 6 robust tools to the AI client:

Tool Name	Parameters	Description
`list_tickets`	`status` (opt), `requester_email` (opt), `search_query` (opt), `row_count` (opt), `start_index` (opt)	Retrieve, paginated, and filter tickets. Performs efficient server-side query filtering.
`get_ticket`	`ticket_id` (req)	Retrieve full details of a single ticket (including HTML description and resolutions).
`create_ticket`	`subject` (req), `description` (req), `priority` (opt), `requester_email` (opt)	Create a new help desk request.
`update_ticket`	`ticket_id` (req), `subject` (opt), `description` (opt), `status` (opt)	Update fields on an existing ticket.
`add_ticket_note`	`ticket_id` (req), `note` (req)	Append a technical log or update note to a ticket.
`list_ticket_notes`	`ticket_id` (req)	Fetch all technical notes logged on a specific ticket.

🚀 Quick Start

Prerequisites

Python 3.10 or higher.
uv is highly recommended for lightning-fast package and tool management (or standard pip).

1. Configure Your Credentials

Copy the .env.example template to .env:

cp .env.example .env

Open .env and fill in your details:

SDP_API_KEY=your_technician_key_here
SDP_BASE_URL=productsupport.example.com
SDP_USERNAME=your_username_here

Note: Your SDP_API_KEY (Technician Key/Authtoken) is generated from your ServiceDesk Plus profile page.

📦 Local Installation & Build

Building the Package

You can build a clean local package artifact (wheel file) of the server using standard build tools:

Using uv:

uv build

Using standard Python:

python -m pip install --upgrade build
python -m build

This will compile and output the package to dist/servicedesk_plus-0.1.0-py3-none-any.whl.

🔌 Configuring Your MCP Host

1. Claude Desktop

Add this to your claude_desktop_config.json (typically located in %APPDATA%\Claude\claude_desktop_config.json on Windows or ~/Library/Application Support/Claude/claude_desktop_config.json on macOS):

Option A: Running from Built Local Wheel (Recommended)

This approach executes the server inside an isolated temporary sandbox with standard uvx:

{
  "mcpServers": {
    "servicedesk-plus": {
      "command": "uvx",
      "args": [
        "--from",
        "C:\\Workspace\\google-cli\\productsupport-mcp\\dist\\servicedesk_plus-0.1.0-py3-none-any.whl",
        "servicedesk-plus"
      ],
      "env": {
        "SDP_API_KEY": "YOUR_API_KEY",
        "SDP_BASE_URL": "productsupport.example.com",
        "SDP_USERNAME": "your_email@domain.com"
      }
    }
  }
}

Option B: Running from Local Sources (Development)

{
  "mcpServers": {
    "servicedesk-plus": {
      "command": "C:\\Workspace\\google-cli\\productsupport-mcp\\.venv\\Scripts\\python.exe",
      "args": [
        "C:\\Workspace\\google-cli\\productsupport-mcp\\src\\servicedesk_plus\\main.py"
      ],
      "env": {
        "SDP_API_KEY": "YOUR_API_KEY",
        "SDP_BASE_URL": "productsupport.example.com",
        "SDP_USERNAME": "your_email@domain.com"
      }
    }
  }
}

🧪 Running Unit Tests

This project includes a comprehensive offline unit testing suite utilizing pytest and respx to mock ServiceDesk Plus API responses entirely.

Install development requirements in your virtual environment:
```
pip install -e .[dev]
```
Run tests:
```
pytest
```

All tests run 100% offline, allowing verification of tool registration, query formatting, body payload construction, and response unpacking with zero credentials or internet required.

📄 License

This project is licensed under the MIT License - see the LICENSE file for details.

Available Tools

6 tools

add_ticket_noteA

Append a technical update or administrative note to a ticket.

Args: ticket_id: The unique numeric ID of the ticket. note: Text content of the note to append.

ParametersJSON Schema

Name	Required	Description	Default
`note`	Yes
`ticket_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations, the description carries the burden. 'Append' conveys a non-destructive, additive write operation, which is helpful. However, it does not disclose potential requirements (e.g., ticket existence, authorization, formatting constraints) or response behavior beyond the append.

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 very concise: two sentences for purpose plus a compact Args list. No filler or redundant content, and essential parameter details are front-loaded.

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?

Given the tool's simplicity and the presence of an output schema (which removes need to describe return values), the description covers the core purpose and all parameter semantics. It lacks usage guidance and behavioral caveats, but overall it is reasonably complete for a straightforward append operation.

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

Parameters5/5

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

Schema description coverage is 0%, but the description's Args section explicitly explains both parameters: ticket_id is 'the unique numeric ID' (clarifying despite schema string type) and note is 'Text content of the note to append.' This fully compensates for the schema gap.

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 action with a specific verb ('Append') and resource ('note to a ticket'). It differentiates from siblings like list_ticket_notes (read operation) and create_ticket/update_ticket (ticket-level operations), making it unambiguous.

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, nor any context about prerequisites (e.g., ticket must exist) or outcomes. The sibling list is available but the description does not reference it.

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

create_ticketA

Create a new Help Desk ticket in ServiceDesk Plus.

Args: subject: Short summary or subject of the ticket. description: Full plain-text or HTML description detailing the issue. priority: Optional priority name (e.g. 'High', 'Medium', 'Low'). requester_email: Optional email of the requester. If omitted, uses default.

ParametersJSON Schema

Name	Required	Description	Default
`subject`	Yes
`priority`	No
`description`	Yes
`requester_email`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior3/5

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

With no annotations, the description must carry the full burden of behavioral disclosure. It does reveal that the description field accepts plain-text or HTML and that requester_email defaults when omitted, but it does not mention permissions, idempotency, side effects, or what the response contains.

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 purpose sentence plus a bullet list of four parameters. It is front-loaded with the primary action and each parameter gets a brief, informative line, with no wasted words.

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?

For a simple create operation, the description covers the main action and all parameters, and an output schema exists to define return values. However, it omits explicit usage guidance and any preconditions, making it adequate but not fully comprehensive.

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

Parameters5/5

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

The input schema has no descriptions (0% coverage), so the description fully compensates by explaining each parameter: subject, description, priority (with examples), and requester_email (with default behavior). This adds substantial meaning beyond the bare property names.

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 states 'Create a new Help Desk ticket in ServiceDesk Plus,' which is a specific verb (create) and resource (Help Desk ticket) with a clear system context. This clearly distinguishes it from sibling tools like list_tickets and update_ticket.

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

Usage Guidelines3/5

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

The description does not explicitly mention when to use this tool or any alternatives, so the usage is implied by the name and purpose. It offers no exclusions or comparison to sibling tools like update_ticket or add_ticket_note, leaving the agent to infer the correct context.

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

get_ticketA

Retrieve detailed information on a single ticket, including its status, resolution, and description.

Args: ticket_id: The unique numeric ID of the ticket to retrieve.

ParametersJSON Schema

Name	Required	Description	Default
`ticket_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/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 discloses the read-only nature via 'Retrieve' and indicates some return fields, but it does not address error conditions (e.g., non-existent ticket), authorization requirements, or any side effects. This is a moderate disclosure.

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 concise and front-loaded, with one sentence for purpose and a brief Args line. No wasted words or extraneous details.

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?

For a single-parameter read tool with an output schema, the description is largely complete. It specifies the input and the kind of information returned. It could mention not-found behavior, but that is not critical for a straightforward retrieval.

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 to ticket_id by describing it as a unique numeric ID for the ticket to retrieve. This goes beyond the schema's bare type/title, though the type mismatch (numeric vs string) could cause minor confusion. Overall, it meaningfully enhances 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 the tool retrieves detailed information on a single ticket, listing specific fields (status, resolution, description). This distinguishes it from siblings like list_tickets, create_ticket, and update_ticket, which handle different operations.

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 phrase 'single ticket' provides clear context that this is for retrieving one specific ticket, not multiple. However, it does not explicitly mention alternatives like list_tickets for multiple tickets or add any when-not-to-use guidance.

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

list_ticket_notesA

List all notes attached to a specific ticket.

Args: ticket_id: The unique numeric ID of the ticket.

ParametersJSON Schema

Name	Required	Description	Default
`ticket_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior2/5

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

No annotations are provided, and the description carries the full burden of behavioral disclosure. It does not mention read-only nature, error handling, pagination, ordering, or what happens if the ticket does not exist, leaving significant uncertainty for an agent.

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, with a one-sentence purpose followed by a single parameter explanation. It is well-structured, front-loaded, and contains no unnecessary information.

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?

For a simple single-parameter list tool, the description covers purpose and parameter adequately. However, it lacks behavioral details like error conditions, ordering, or pagination, which are not compensated by the existing output schema.

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 0% schema description coverage, the description compensates by explaining that ticket_id is 'the unique numeric ID of the ticket.' This adds meaning beyond the schema's bare type definition, clarifying that the ID is unique and numeric despite being typed as a string.

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 all notes attached to a specific ticket' with a specific verb (list), resource (notes), and scope (attached to a ticket). This distinguishes it from sibling tools like list_tickets (lists tickets) and add_ticket_note (adds a note).

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 makes it clear that this tool is for retrieving notes for a given ticket, providing clear context on when to use it. It implies the need for a valid ticket_id and is distinct from sibling tools, though it does not explicitly mention alternatives.

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

list_ticketsA

Retrieve, search, and filter ServiceDesk Plus tickets.

Args: status: Optional status filter (e.g. 'Open', 'In Progress', 'Closed'). requester_email: Optional requester email address filter. search_query: Optional text keyword search for ticket subjects. row_count: Number of tickets to retrieve (default: 20, max: 100). start_index: 1-based start index for paginated results (default: 1).

ParametersJSON Schema

Name	Required	Description	Default
`status`	No
`row_count`	No
`start_index`	No
`search_query`	No
`requester_email`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior3/5

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

With no annotations, the description carries the behavioral transparency burden. It discloses useful details like default row_count (20) and max (100), and that start_index is 1-based. However, it does not mention return structure, ordering, or how filters are combined, leaving some behavioral gaps.

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 concise and well-structured: a brief summary sentence followed by a clean argument list. Every line adds value, with no fluff or repetition.

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?

Given the presence of an output schema and clear parameter documentation, the description is largely complete for a listing tool. Minor gaps like default ordering and filter combination semantics prevent a perfect score, but these are not critical.

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

Parameters5/5

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

Schema description coverage is 0%, so the description is the sole source of parameter meaning. It explains every parameter, provides examples for status, and clarifies search_query searches ticket subjects. It also adds the row_count maximum and start_index base, going 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 the tool's function: 'Retrieve, search, and filter ServiceDesk Plus tickets.' This uses a specific verb and resource, and distinguishes it from siblings like get_ticket (singular), create_ticket, etc.

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

Usage Guidelines3/5

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

The description explains what the tool does but does not provide explicit when-to-use or when-not-to-use guidance, nor does it contrast with alternatives like get_ticket. 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.

update_ticketA

Update fields on an existing ticket in ServiceDesk Plus.

Args: ticket_id: The unique numeric ID of the ticket to update. subject: Optional new subject for the ticket. description: Optional new plain-text or HTML description. status: Optional new status name (e.g. 'Open', 'In Progress', 'Closed').

ParametersJSON Schema

Name	Required	Description	Default
`status`	No
`subject`	No
`ticket_id`	Yes
`description`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral details, but it only says 'update fields' without explaining null-value semantics, idempotency, behavior when a ticket doesn't exist, or response format. It leaves ambiguity about whether passing null clears a field or leaves it unchanged, which is critical for a mutation 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 concise: one purpose sentence plus a clean one-line-per-parameter list. It is front-loaded with the action and avoids unnecessary words, making it easy for an agent to quickly parse.

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?

For a simple update tool, the description covers purpose and parameter meanings, but it misses key operational context such as null semantics, minimum requirements, error behavior, and permissions. An output schema exists so return values are covered, but the lack of behavioral context and explicit usage guidance leaves gaps.

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

Parameters5/5

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

The schema has zero description coverage, so the description fully compensates by explaining every parameter: ticket_id as unique numeric ID, subject as optional new subject, description as plain-text/HTML, and status with examples. This adds significant meaning beyond the raw 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 uses a specific verb+resource: 'Update fields on an existing ticket in ServiceDesk Plus.' This clearly distinguishes from siblings like create_ticket (existing vs new) and list/get (fields vs retrieval). The Args section further reinforces the tool's purpose.

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

Usage Guidelines3/5

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

The description implies use on existing tickets, but it does not explicitly contrast with create_ticket or other alternatives, nor does it state when not to use it. There are no preconditions or exclusions described, so the guidance is implied rather than explicit.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Disambiguation5/5

Each tool has a distinct purpose: list, detail, create, update, add note, and list notes. No overlap or ambiguity between them.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with snake_case (e.g., list_tickets, create_ticket, update_ticket). This is uniform and predictable.

Tool Count5/5

Six tools is well-scoped for a help desk ticket server, covering core ticket operations and note management without unnecessary bloat.

Completeness4/5

The tool set covers create, read, update, list, and notes. Missing delete is acceptable for tickets, but lack of assign/transfer or note editing is a minor gap.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

mttrly
com.mttrly
AI-powered incident management and server monitoring via MCP.
Monitoring Observability
3
Zapier
com.zapier
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
App Automation Workplace & Productivity
2297
Support Service Management Mcp D
io.github.varvararatta
MCP server for Support & Service Management
Customer Support Project Management
2
Artificial Wit AI
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2

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 4 months ago (2026-04-29 15:02 UTC)
3
56
3
MIT
freshservice-mcp
Customer Support CRM
mchluba
A
license
Not graded
quality
C
maintenance
An MCP server that enables AI assistants to interact with Freshservice service desk, supporting ticket search, retrieval, and creation via a configurable, Docker-first deployment.
Updated 2 months ago (2026-07-14 15:00 UTC)
MIT
soporte-ti-mcp
Customer Support Search
raulperez0798
F
license
Not graded
quality
B
maintenance
MCP server that provides IT support tools to search known incidents, check ticket status, and create ticket drafts, enabling an AI assistant to help users with IT support queries.
Updated a month ago (2026-08-08 17:16 UTC)
i-net HelpDesk MCP Server
Customer Support App Automation
roddyst
A
license
A
quality
B
maintenance
MCP server that exposes the i-net HelpDesk Ticket Web-API as tools for AI agents, enabling ticket search, reading, creation, and actions like replying, closing, and escalating, with attachment support.
Updated 16 days ago (2026-08-18 14:12 UTC)
8
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/kaattaalan/servicedesk-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

ServiceDesk Plus Model Context Protocol (MCP) Server

🛠️ Features

📐 Architecture Overview

📋 MCP Tools Exposed

🚀 Quick Start

Prerequisites

1. Configure Your Credentials

📦 Local Installation & Build

Building the Package

🔌 Configuring Your MCP Host

1. Claude Desktop

Option A: Running from Built Local Wheel (Recommended)

Option B: Running from Local Sources (Development)

🧪 Running Unit Tests

📄 License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

jitbit-helpdesk-mcpofficial

Latest Blog Posts

MCP directory API