Which integrations are available for this server?

Provides integration with Atlassian products (beyond Jira) through a unified interface, handling authentication and API interactions. Enables interaction with Jira instances through a unified API, providing capabilities for accessing issues, managing tickets, and integrating with Jira workflows. Allows connection to Zendesk instances to manage tickets and support requests through a standardized interface that abstracts away Zendesk-specific API complexities.

How do I use MCP FOR ITSM?

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., "@MCP FOR ITSM create a high priority ticket for the server outage in ServiceNow" 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.

en es ja ko zh

MCP FOR ITSM

by madosh

Overview Schema Related Servers Score Discussions

JavaScript

Remote

MCP ITSM

Unified IT Service Management over the Model Context Protocol — create, track, and resolve tickets across ServiceNow, Jira, Zendesk, Ivanti Neurons, and Cherwell from any MCP-compatible LLM client.

MCP Spec SDK Node License Smithery

Related MCP server: ARC-1

Overview

MCP ITSM exposes a standardised set of MCP tools, resources, and prompts so that any LLM client (Claude, Cursor, custom agents) can manage IT tickets without knowing the underlying ITSM system's API.

What it is:

Layer	What's here
`index.js`	MCP server — 7 tools, 4 resources, 3 prompts over stdio
`backend/`	Express REST API that bridges HTTP clients to the MCP server via the official SDK `Client`
`frontend/`	React 18 web app — Ticket Manager UI + live Monitoring Dashboard

Why it matters:
Instead of writing separate integrations for ServiceNow, Jira, Zendesk, Ivanti, and Cherwell, an LLM calls create_ticket once and the correct system receives it. Every tool carries safety annotations (readOnlyHint, destructiveHint) so the model knows what it can call without risk.

Architecture

graph TB
    subgraph "MCP Clients"
        Claude["Claude / Cursor / Agent"]
        Inspector["MCP Inspector"]
        UI["React Frontend :3000"]
    end

    subgraph "Transport"
        Stdio["StdioServerTransport\n(Smithery / Inspector)"]
        Bridge["Express API :5000\nSDK Client + StdioClientTransport"]
    end

    subgraph "MCP Server  —  index.js  v3.0.0"
        McpSrv["McpServer\nspec 2025-11-25"]
        Tools["7 Tools\nZod · annotated"]
        Resources["4 Resources\nKB articles · Tickets"]
        Prompts["3 Prompts\nIncident · Status · KB-assist"]
        Store["In-Memory Store\nTickets & KB articles"]
    end

    subgraph "Backend Services"
        Auth["JWT Auth"]
        Metrics["Metrics Store"]
        Mongo[("MongoDB")]
    end

    Claude -->|stdio| Stdio
    Inspector -->|stdio| Stdio
    UI -->|HTTP + JWT| Bridge

    Stdio --> McpSrv
    Bridge -->|"MCP SDK Client\n(proper handshake)"| McpSrv

    McpSrv --> Tools
    McpSrv --> Resources
    McpSrv --> Prompts
    Tools <--> Store
    Resources --> Store

    Bridge --> Auth
    Bridge --> Metrics
    Auth --> Mongo

Request flow — browser tool call:

sequenceDiagram
    participant U as User
    participant UI as React UI :3000
    participant API as Express API :5000
    participant C as MCP SDK Client
    participant MCP as McpServer index.js

    U->>UI: Submit form
    UI->>API: POST /api/mcp/tools/call (JWT)
    API->>C: client.callTool(name, args)
    Note over C: StdioClientTransport
    C->>MCP: tools/call (MCP protocol)
    Note over MCP: Zod validates input
    MCP->>MCP: tool handler + in-memory store
    MCP-->>C: CallToolResult
    C-->>API: result
    API->>API: recordCall() → metrics
    API-->>UI: { success, data, _meta }
    UI->>U: Show result

Quick Start

Prerequisites

Node.js ≥ 18
MongoDB (local or Atlas — required by the backend)
Optional: Smithery CLI for cloud deployment

1 — Install dependencies

# Root (MCP server)
npm install

# Backend API
cd backend && npm install && cd ..

# Frontend
cd frontend && npm install && cd ..

2 — Configure environment

cp .env.example .env          # root — API key for Smithery / MCP auth
cp backend/.env.example backend/.env   # backend — Mongo URI, JWT secret, ITSM creds

Minimum required for local dev (edit backend/.env):

MONGODB_URI=mongodb://localhost:27017/mcp-itsm
JWT_SECRET=change-me-in-production

3 — Start all services

Open three terminals:

# Terminal 1 — MCP server (stdio)
npm start

# Terminal 2 — Backend API
cd backend && npm start        # http://localhost:5000

# Terminal 3 — Frontend
cd frontend && npm start       # http://localhost:3000

flowchart LR
    T1["Terminal 1\nnpm start\nMCP server on stdio"]
    T2["Terminal 2\ncd backend\nnpm start  :5000"]
    T3["Terminal 3\ncd frontend\nnpm start  :3000"]
    UI["localhost:3000\nTicket Manager\nMonitor Dashboard"]

    T1 -->|"SDK Client\nStdioClientTransport"| T2
    T2 -->|"HTTP + JWT"| T3
    T3 --> UI

Access points

URL	What
`http://localhost:3000`	React web app
`http://localhost:3000/mcp-tickets`	MCP Ticket Manager
`http://localhost:3000/mcp-monitor`	Live Monitoring Dashboard
`http://localhost:5000/health`	Backend health check
`http://localhost:5000/api/mcp/health`	MCP server connectivity
`http://localhost:5000/api/mcp/metrics`	Tool-call metrics (auth required)

Project Structure

mcp-itsm/
├── index.js                  # MCP server (McpServer, Zod, stdio)
├── tools.json                # Static tool catalogue for Smithery browser
├── smithery.yaml             # Smithery deployment config
├── package.json              # Root deps: @modelcontextprotocol/sdk, zod
├── .env.example              # Root env template
│
├── backend/
│   ├── package.json          # Express, Mongoose, JWT, MCP SDK Client
│   ├── .env.example          # Backend env template
│   └── src/
│       ├── index.js          # Express app bootstrap
│       ├── config/config.js  # Env-driven configuration
│       ├── routes/
│       │   ├── mcp.routes.js      # MCP bridge + metrics endpoints
│       │   ├── auth.routes.js
│       │   ├── context.routes.js
│       │   ├── integration.routes.js
│       │   └── user.routes.js
│       ├── middleware/
│       │   ├── auth.middleware.js
│       │   └── validation.middleware.js
│       ├── models/
│       ├── validators/
│       └── utils/logger.js
│
├── frontend/
│   ├── package.json          # React 18, Bootstrap, react-router-dom
│   └── src/
│       ├── App.js
│       ├── pages/
│       │   ├── MCPTicketManager.js     # Ticket CRUD UI
│       │   ├── MCPMonitorDashboard.js  # Live monitoring (polls every 10s)
│       │   ├── Dashboard.js
│       │   ├── LLMChatClient.js
│       │   └── ...
│       ├── services/
│       │   ├── mcpService.js   # HTTP client for MCP tool calls
│       │   └── api.js          # Axios instance with JWT interceptor
│       └── components/
│           ├── Header.js
│           └── ...
│
└── docs/
    ├── api-documentation.md
    ├── mcp_relationship.md
    └── llm_enabled_tickets.md

MCP Tools

All 7 tools are registered via McpServer.tool() with Zod input schemas and safety annotations. LLM clients use the annotations to decide whether to call a tool without user confirmation.

Tool	Title	Read-only	Idempotent	Required params
`create_ticket`	Create Ticket	—	—	`title`, `description`
`get_ticket`	Get Ticket	✓	✓	`ticket_id`
`update_ticket`	Update Ticket	—	—	`ticket_id`
`list_tickets`	List Tickets	✓	✓	—
`assign_ticket`	Assign Ticket	—	✓	`ticket_id`, `user_id`
`add_comment`	Add Comment	—	—	`ticket_id`, `comment`
`search_knowledge_base`	Search KB	✓	✓	`query`

Supported systems (via the optional system parameter): servicenow · jira · zendesk · ivanti_neurons · cherwell (default: jira)

graph LR
    subgraph RO["Read-only  —  safe to call freely"]
        GT["get_ticket\nreadOnly · idempotent"]
        LT["list_tickets\nreadOnly · idempotent"]
        SK["search_knowledge_base\nreadOnly · idempotent"]
    end
    subgraph WR["Write  —  require user intent"]
        CT["create_ticket\nwrite"]
        UT["update_ticket\nwrite"]
        AT["assign_ticket\nwrite · idempotent"]
        AC["add_comment\nwrite"]
    end
    style RO fill:#f0fdf4,stroke:#86efac
    style WR fill:#fff1f2,stroke:#fecdd3

Example — create a ticket

// Tool call
{
  "name": "create_ticket",
  "arguments": {
    "title": "VPN not connecting after Windows update",
    "description": "Since the KB5034441 update, VPN client fails to authenticate on first attempt.",
    "priority": "high",
    "system": "jira"
  }
}

// Response
{
  "success": true,
  "ticket": {
    "id": "JIRA-1000",
    "title": "VPN not connecting after Windows update",
    "system": "jira",
    "status": "open",
    "priority": "high",
    "url": "https://example.com/jira/tickets/JIRA-1000"
  }
}

MCP Resources

Resources expose live data that LLM clients can read without a tool call.

URI	Name	Description
`kb://articles`	kb-articles	All knowledge base articles (JSON)
`kb://articles/{id}`	kb-article	Single KB article by ID (e.g. `KB-001`)
`itsm://tickets/open`	open-tickets	All currently open tickets (live)
`itsm://tickets/{ticketId}`	ticket	Single ticket by ID (e.g. `JIRA-1000`)

graph LR
    McpSrv["McpServer"]
    McpSrv -->|"static\nkb://articles"| KBAll["kb-articles\nAll KB articles as JSON"]
    McpSrv -->|"template\nkb://articles/{id}"| KBOne["kb-article\nSingle article by ID"]
    McpSrv -->|"static\nitsm://tickets/open"| TOpen["open-tickets\nLive filtered view"]
    McpSrv -->|"template\nitsm://tickets/{id}"| TOne["ticket\nSingle ticket by ID"]
    style McpSrv fill:#f0fdf4,stroke:#86efac

MCP Prompts

Prompts are guided message templates that clients present to users before a tool call sequence.

Name	Description	Arguments
`create-incident-ticket`	P1/P2 incident ticket template	`title` (req), `system`, `affected_service`
`ticket-status-report`	Structured queue summary	`filter_status`
`kb-search-assist`	Search KB before creating a ticket	`issue_description` (req)

sequenceDiagram
    participant U as User
    participant C as MCP Client
    participant MCP as McpServer

    U->>C: "My printer won't install"
    C->>MCP: prompts/get  kb-search-assist
    MCP-->>C: message template
    C->>MCP: tools/call  search_knowledge_base
    MCP-->>C: KB-005 Printer setup guide
    C->>U: Show article — no ticket needed
    Note over C,U: Only escalates to create_ticket if no article resolves it

Configuration

Root `.env` (MCP server + Smithery)

# API key used when running via Smithery (injected as API_KEY env var)
API_KEY=your-smithery-api-key

Backend `backend/.env`

# Server
PORT=5000
NODE_ENV=development

# Database
MONGODB_URI=mongodb://localhost:27017/mcp-itsm

# Auth
JWT_SECRET=change-me-to-a-long-random-string
JWT_EXPIRES_IN=1d

# ITSM integrations (all optional — only needed for live system calls)
SERVICENOW_BASE_URL=https://your-instance.service-now.com
SERVICENOW_USERNAME=admin
SERVICENOW_PASSWORD=

JIRA_BASE_URL=https://your-org.atlassian.net
JIRA_EMAIL=you@example.com
JIRA_API_TOKEN=

ZENDESK_BASE_URL=https://your-org.zendesk.com
ZENDESK_USERNAME=you@example.com
ZENDESK_TOKEN=

IVANTI_BASE_URL=https://your-instance.ivanti.com
IVANTI_CLIENT_ID=
IVANTI_CLIENT_SECRET=

CHERWELL_BASE_URL=https://your-instance.cherwell.com
CHERWELL_CLIENT_ID=
CHERWELL_USERNAME=
CHERWELL_PASSWORD=

# Logging
LOG_LEVEL=info

Monitoring Dashboard

The frontend includes a live monitoring dashboard at /mcp-monitor that polls the backend every 10 seconds.

What it shows:

Server connected / disconnected status with uptime
Total calls, success rate, failed call count
Per-tool call statistics with average latency badges
Available tools with annotation labels (read-only, write, idempotent)
Registered resources and prompts
Live activity log of the last 20 tool calls

The data is sourced from the in-memory metrics store in backend/src/routes/mcp.routes.js and reset on backend restart.

flowchart TD
    DB["React Dashboard\n/mcp-monitor\npoll every 10 s"]
    DB -->|"GET /api/mcp/health"| H["connected · uptimeSeconds"]
    DB -->|"GET /api/mcp/metrics"| M["totalCalls · successRate\ntoolStats · recentCalls"]
    DB -->|"GET /api/mcp/tools/list"| T["tool names + annotations"]
    DB -->|"GET /api/mcp/resources/list"| R["resource URIs"]
    DB -->|"GET /api/mcp/prompts/list"| P["prompt names"]

API Reference

All /api/mcp/* endpoints require a valid JWT in the Authorization: Bearer <token> header.

Method	Path	Description
`GET`	`/api/mcp/health`	MCP server connectivity + backend uptime
`GET`	`/api/mcp/metrics`	Tool-call metrics (counts, latency, recent calls)
`GET`	`/api/mcp/tools/list`	List all registered tools with schemas + annotations
`POST`	`/api/mcp/tools/call`	Call a tool — body: `{ name, arguments }`
`GET`	`/api/mcp/resources/list`	List registered MCP resources
`GET`	`/api/mcp/prompts/list`	List registered MCP prompts

Tool call example (curl)

# Authenticate first
TOKEN=$(curl -s -X POST http://localhost:5000/api/auth/login \
  -H "Content-Type: application/json" \
  -d '{"email":"admin@example.com","password":"password"}' | jq -r '.token')

# Call a tool
curl -X POST http://localhost:5000/api/mcp/tools/call \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "search_knowledge_base",
    "arguments": { "query": "vpn", "limit": 3 }
  }'

Smithery Deployment

The server is published at @madosh/mcp-itsm on Smithery.

flowchart LR
    Dev["Developer\nnpm publish via\nsmithery publish"]
    Smithery["Smithery Cloud\nDocker container\nenv API_KEY injected"]
    MCPSrv["McpServer v3.0.0\nnpm start → stdio"]
    Client["Claude / Cursor\nany MCP client"]

    Dev -->|"smithery.yaml\ntools.json"| Smithery
    Smithery -->|"spawn"| MCPSrv
    Client -->|"MCP protocol\nstdio"| Smithery
    Smithery <-->|"proxy"| MCPSrv

Install via Smithery CLI

npx -y @smithery/cli install @madosh/mcp-itsm --client claude

Manual Smithery deploy

npm install -g @smithery/cli
smithery login
smithery publish

The smithery.yaml configuration:

startCommand:
  type: stdio
  configSchema:
    type: object
    required: [apiKey]
    properties:
      apiKey:
        type: string
  commandFunction: |-
    (config) => ({ command: 'npm', args: ['start'], env: { API_KEY: config.apiKey } })
tools:
  path: ./tools.json

Use with Claude Desktop

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "mcp-itsm": {
      "command": "node",
      "args": ["/absolute/path/to/mcp-itsm/index.js"],
      "env": { "API_KEY": "your-key" }
    }
  }
}

Debug with MCP Inspector

npm run debug-mcp
# Opens MCP Inspector at http://localhost:5173

Development

Available scripts

# Root
npm start              # Start MCP server on stdio
npm run debug-mcp      # Start with MCP Inspector attached

# Backend
cd backend
npm start              # Production
npm run dev            # Development (nodemon hot-reload)
npm test               # Jest test suite

# Frontend
cd frontend
npm start              # Dev server on :3000
npm run build          # Production build

Tech stack

Layer	Technologies
MCP Server	Node.js 18+, `@modelcontextprotocol/sdk` 1.28.0, Zod 3.23
Backend	Express 4, Mongoose 7, JWT, Helmet, Winston
Frontend	React 18, React Router 6, Bootstrap 5
MCP Spec	2025-11-25
Deployment	Smithery (stdio), Docker

Running with Docker

docker build -t mcp-itsm .
docker run -e API_KEY=your-key mcp-itsm

Contributing

Contributions are welcome. Please:

Fork the repository
Create a feature branch (git checkout -b feat/my-feature)
Commit your changes (git commit -m 'feat: add my feature')
Push to the branch (git push origin feat/my-feature)
Open a Pull Request

Roadmap

OAuth 2.1 / OIDC authorization for external clients
Elicitation — server-initiated mid-call user prompts
Experimental Tasks — durable async ticket workflows
Live ITSM system adapters (ServiceNow, Jira, Zendesk)
outputSchema / structuredContent on all tools

graph LR
    subgraph Done["Shipped in v3.0.0"]
        D1["SDK 1.28.0 + Zod"]
        D2["McpServer API"]
        D3["Tool annotations"]
        D4["Resources + Prompts"]
        D5["SDK Client transport"]
        D6["Metrics + Dashboard"]
    end
    subgraph Next["Next"]
        N1["OAuth 2.1 / OIDC"]
        N2["Elicitation"]
        N3["Tasks API"]
        N4["Live ITSM adapters"]
    end
    style Done fill:#f0fdf4,stroke:#86efac
    style Next fill:#eff6ff,stroke:#bfdbfe

License

MIT — see LICENSE for details.

Resources

Available Tools

7 tools

add_commentA

Add a comment (public or internal) to an existing ticket

ParametersJSON Schema

Name	Required	Description	Default
`ticket_id`	Yes	ID of the ticket to comment on
`comment`	Yes	Comment text
`internal`	No	True = internal note not visible to end users
`system`	No	ITSM system to use	jira

TDQS

A3.6/5.0

Behavior3/5

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

Annotations (readOnlyHint=false, destructiveHint=false) are consistent with a write operation. Description adds the 'public or internal' nuance already present in schema parameter. No additional behavioral traits (e.g., auth requirements, side effects) are disclosed, but annotations cover basic safety profile.

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?

Single sentence, front-loaded, zero fluff. Every word contributes to conveying purpose. Appropriate length for a simple tool.

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?

No output schema exists, but description does not hint at return values or response format. For a comment addition tool, the agent might expect to know if the comment ID is returned. Lacks this context.

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%, so parameters are fully documented. Description adds no extra meaning beyond summarizing the 'internal' parameter. Baseline score of 3 is appropriate as schema does the heavy lifting.

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 verb 'Add', resource 'comment', and context 'to an existing ticket'. Distinguishes between public and internal comments. Sibling tools (create_ticket, update_ticket) are distinct, so purpose is unambiguous.

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?

Description implies usage for adding comments to existing tickets but does not explicitly state when not to use this tool (e.g., for creating tickets) or mention alternatives like update_ticket. Guidance is inferred rather than explicit.

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

assign_ticketA

Idempotent

Assign a ticket to a specific user

ParametersJSON Schema

Name	Required	Description	Default
`ticket_id`	Yes	ID of the ticket to assign
`user_id`	Yes	Username or ID of the user to assign to
`system`	No	ITSM system to use	jira

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already indicate non-readOnly, non-destructive, idempotent. Description adds 'assign' but no further behavioral details (e.g., reassignment effects, notifications). Minimal additional value beyond annotations.

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?

Single sentence with no wasted words, front-loads the core purpose.

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 assign action, but lacks usage guidance and return value indication. With annotations present, no major gaps but not rich.

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 covers all parameters with descriptions (100% coverage). Description does not add extra meaning beyond summarizing the action.

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?

Clearly states the action ('assign'), the resource ('a ticket'), and the target ('to a specific user'). Distinguishes from sibling tools like create_ticket, get_ticket, 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 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, no prerequisites mentioned (e.g., ticket existence, user permissions), and no when-not-to-use context.

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

create_ticketB

Create a new support ticket in the appropriate ITSM system

ParametersJSON Schema

Name	Required	Description	Default
`title`	Yes	Title of the ticket
`description`	Yes	Detailed description of the issue
`priority`	No	Priority level	medium
`system`	No	ITSM system to use	jira

TDQS

B3.4/5.0

Behavior2/5

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

Annotations provide basic hints (non-readOnly, non-destructive), but the description adds no behavioral context beyond creation. It does not disclose side effects like notifications, system validation, or error behavior, which are not covered by annotations.

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 a single, concise sentence. It is well-structured and gets to the point without unnecessary details, though it could be slightly expanded for clarity.

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 tool is simple with 4 parameters and no output schema. The description provides enough to understand the basic action but lacks details on return values, system selection logic, or potential errors. It is minimally complete.

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?

The input schema has 100% coverage with descriptions for all parameters. The description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.

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 it creates a new support ticket in an ITSM system, with a specific verb and resource. It effectively distinguishes from sibling tools like 'get_ticket' or 'update_ticket' by focusing on creation.

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 state when to use this tool versus alternatives like 'add_comment' or 'assign_ticket'. It implicitly suggests it's for creating new tickets, but offers no exclusions or context for 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.

get_ticketA

Read-onlyIdempotent

Retrieve full details of an existing ticket by ID

ParametersJSON Schema

Name	Required	Description	Default
`ticket_id`	Yes	ID of the ticket to retrieve (e.g. JIRA-1000)
`system`	No	ITSM system to use	jira

TDQS

A4/5.0

Behavior3/5

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

Annotations fully cover safety profile (readOnly, idempotent). Description adds only 'Retrieve full details', consistent with annotations, no additional behavioral context beyond that.

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?

Single sentence with no wasted words, front-loaded with the key action and resource.

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 read tool with two parameters and no output schema, description adequately states purpose. Could mention that result includes full ticket details, but not necessary.

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 has 100% coverage with descriptions for both parameters. Description does not add further meaning; the schema already explains ticket_id and system.

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 uses specific verb 'Retrieve' and resource 'full details of an existing ticket by ID', clearly distinguishing from siblings like list_tickets (list multiple) or update_ticket (modify).

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?

Clear that tool is for retrieving a single ticket by ID, but lacks explicit 'when not to use' or comparison to alternatives like list_tickets for browsing.

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

list_ticketsA

Read-onlyIdempotent

List tickets with optional filtering by status, assignee, or system

ParametersJSON Schema

Name	Required	Description	Default
`status`	No	Filter by status
`assigned_to`	No	Filter by assignee username
`limit`	No	Max number of tickets to return
`system`	No	ITSM system to use	jira

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds no new behavioral details (e.g., pagination, sorting, API limits) beyond what the schema and annotations imply, so it provides moderate added 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?

A single 10-word sentence that efficiently conveys the tool's purpose and key filters. No extraneous information, and the core action is 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 the tool's simplicity (list operation with 4 optional parameters, no output schema), the description covers the basics but omits usage guidelines and details about return format or pagination, leaving some gaps for an agent to infer.

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 description coverage is 100%, meaning all parameters are documented in the schema. The description merely restates the filter options without adding new semantic context, meeting the baseline but not exceeding it.

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 explicitly states 'list tickets' with optional filters by status, assignee, or system, providing a specific verb and resource that clearly differentiates from sibling tools which involve creation or modification.

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 search_knowledge_base, nor any mention of prerequisites or exclusions. The description only lists optional filters without context on when each is appropriate.

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

search_knowledge_baseA

Read-onlyIdempotent

Search the knowledge base for articles related to an issue

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Search query — keywords, error messages, or topic
`limit`	No	Max articles to return
`system`	No	ITSM system to use	jira

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds no further behavioral details beyond the search action, such as authentication needs or result format. No contradiction with annotations.

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 a single, clear sentence with no wasted words. It could be slightly expanded to include when to use, but it is appropriately front-loaded and efficient.

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 simple nature of the tool (search with query, limit, system), the description is sufficient. No output schema exists, but the tool's behavior is straightforward and well-covered by annotations and 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?

All three parameters have descriptive schema documentation (100% coverage). The description does not add meaning beyond what the schema already provides, so baseline 3 is appropriate.

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 verb 'search' and the resource 'knowledge base' with a specific goal: finding articles related to an issue. It distinguishes itself from sibling tools, which are all ticket-related actions.

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 usage when articles about an issue are needed, but does not explicitly state when to use or not use this tool, nor does it mention alternative tools or context for exclusion.

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

update_ticketB

Update the status, priority, or add a comment to an existing ticket

ParametersJSON Schema

Name	Required	Description	Default
`ticket_id`	Yes	ID of the ticket to update
`status`	No	New status
`priority`	No	Priority level	medium
`comment`	No	Comment to add to the ticket
`system`	No	ITSM system to use	jira

TDQS

B3.4/5.0

Behavior2/5

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

Annotations provide minimal behavioral info. Description only says 'update', missing details on authentication, rate limits, or side effects. Bare minimum disclosure.

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?

Single sentence, front-loaded, efficient. Minor awkwardness with 'or' list.

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 given 5 parameters explained in schema, no output schema. Lacks explanation of updating multiple fields simultaneously, but overall covers main purpose.

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%, so baseline 3. Description adds list of updatable fields but uses 'or' which could imply exclusivity, slightly misleading. No significant extra meaning.

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 updates status, priority, or adds a comment to an existing ticket, distinguishing it from siblings like create_ticket and assign_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?

Implied usage through listing updatable fields, but no explicit guidance on when to use versus add_comment or assign_ticket, nor prerequisites.

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. Dates show when Glama detected each change.

7 tool updatesv2.0.0May 13, 2026
- First observedadd_comment
- First observedassign_ticket
- First observedcreate_ticket
- First observedget_ticket
- First observedlist_tickets
- First observedsearch_knowledge_base
- First observedupdate_ticket

Install Server

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

TDQS

A3.7/5.0

Disambiguation3/5

Most tools have distinct purposes, but add_comment and update_ticket both allow adding comments, creating ambiguity. The other tools are clearly separated.

Naming Consistency5/5

All tools follow a consistent verb_noun snake_case pattern (e.g., create_ticket, list_tickets, search_knowledge_base), making it easy to infer functionality.

Tool Count5/5

Seven tools cover the essential ticket lifecycle and knowledge base search without being excessive, fitting well for an ITSM server.

Completeness4/5

The tool set covers create, read, update, assignment, and knowledge search, but lacks a delete or archive operation, which may be needed in some workflows.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Support Service Management Mcp D
io.github.varvararatta
MCP server for Support & Service Management
Customer Support Project Management
2
Os Automation Mcp C
io.github.varvararatta
MCP server for OS Automation
OS Automation Command Line
2
llm-orchestration-agent-2
ai.getvda
MCP-Native LLM Orchestration Agent
1
agentic-opsOAuth
io.buildforce
Orchestration & technical-consulting MCP for end-to-end Salesforce, ServiceNow & HubSpot back-end.
CRM Customer Support App Automation
2

Related MCP Servers

Freshservice MCP server
Customer Support Autonomous Agents
effytech
A
license
B
quality
D
maintenance
MCP server created for Freshservice, allowing AI models to interact with Freshservice modules
Updated 5 months ago (2026-04-10 05:32 UTC)
59
36
MIT
ARC-1
Developer Tools ERP Systems
arc-mcp
A
license
A
quality
A
maintenance
MCP server for SAP ABAP systems
Updated 10 hours ago (2026-09-05 21:38 UTC)
8
880
179
MIT
servicenow-api
Customer Support Project Management CI/CD & DevOps
Knuckles-Team
A
license
Not graded
quality
C
maintenance
MCP server enabling interaction with ServiceNow API for managing incidents, CMDB, change management, and other ServiceNow operations via natural language.
Updated 9 days ago (2026-08-28 18:39 UTC)
19
MIT
ServiceNow-MCP
Customer Support Cloud Platforms Developer Tools
tedorigawa001
A
license
B
quality
B
maintenance
Enables natural language control of ServiceNow from AI clients like Claude and Cursor. Provides 400+ tools for incidents, changes, CMDB, and scripts via MCP protocol.
Updated a day ago (2026-09-05 00:30 UTC)
100
434
1
MIT

Appeared in Searches

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/madosh/MCP-ITSM'

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

MCP ITSM

Table of Contents

Overview

Architecture

Quick Start

Prerequisites

1 — Install dependencies

2 — Configure environment

3 — Start all services

Access points

Project Structure

MCP Tools

Example — create a ticket

MCP Resources

MCP Prompts

Configuration

Root .env (MCP server + Smithery)

Backend backend/.env

Monitoring Dashboard

API Reference

Tool call example (curl)

Smithery Deployment

Install via Smithery CLI

Manual Smithery deploy

Use with Claude Desktop

Debug with MCP Inspector

Development

Available scripts

Tech stack

Running with Docker

Contributing

Roadmap

License

Resources

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API

Root `.env` (MCP server + Smithery)

Backend `backend/.env`