시스템 관리 → 웹 서비스로 이동
다음 작업이 포함된 웹 서비스(예: "TestInterface")를 생성하거나 확인:
- ✅ SessionCreate
- ✅ TicketCreate
- ✅ TicketGet
- ✅ TicketSearch
- ✅ TicketUpdate
- ✅ TicketHistoryGet

3단계: 웹 서비스 URL 확인

웹 서비스 URL은 다음과 같은 형식이어야 합니다:

https://your-otrs-server/otrs/nph-genericinterface.pl/Webservice/YourWebserviceName

4단계: 사용자 권한 확인

OTRS 사용자에게 다음에 대한 적절한 권한이 있는지 확인하세요:

티켓 생성 및 수정
구성 항목 접근
Generic Interface 사용

사용 방법

Docker (권장)

otrs-mcp를 Claude Desktop과 함께 실행하는 가장 쉬운 방법은 Docker를 사용하는 것입니다. Docker가 설치되어 있지 않다면 Docker 공식 웹사이트에서 설치할 수 있습니다.

사전 빌드된 이미지 사용

GitHub Container Registry의 사전 빌드된 Docker 이미지를 사용할 수 있습니다:

{
  "mcpServers": {
    "otrs": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "-i",
        "-e",
        "OTRS_BASE_URL=https://your-otrs-server/otrs/nph-genericinterface.pl/Webservice/TestInterface",
        "-e",
        "OTRS_USERNAME=your-username",
        "-e",
        "OTRS_PASSWORD=your-password",
        "-e",
        "OTRS_VERIFY_SSL=false",
        "-e",
        "OTRS_DEFAULT_QUEUE=Raw",
        "-e",
        "OTRS_DEFAULT_STATE=new",
        "-e",
        "OTRS_DEFAULT_PRIORITY=3 normal",
        "ghcr.io/eduardoantoniojunior/otrs-mcp-server:latest"
      ]
    }
  }
}

로컬에서 빌드

이미지를 로컬에서 빌드하려면:

# Clone the repository
git clone https://github.com/eduardoantoniojunior/otrs-mcp-server.git
cd otrs-mcp-server

# Build the Docker image
docker build -t otrs-mcp-server .

# Run the container
docker run --rm -i \
  -e OTRS_BASE_URL="https://your-otrs-server/otrs/nph-genericinterface.pl/Webservice/TestInterface" \
  -e OTRS_USERNAME="your-username" \
  -e OTRS_PASSWORD="your-password" \
  -e OTRS_VERIFY_SSL="false" \
  otrs-mcp-server

UV로 실행

또는 UV를 사용하여 서버를 직접 실행할 수 있습니다. 먼저 환경 변수를 설정하세요:

export OTRS_BASE_URL="https://your-otrs-server/otrs/nph-genericinterface.pl/Webservice/TestInterface"
export OTRS_USERNAME="your-username"
export OTRS_PASSWORD="your-password"
export OTRS_VERIFY_SSL="false"
export OTRS_DEFAULT_QUEUE="Raw"
export OTRS_DEFAULT_STATE="new"
export OTRS_DEFAULT_PRIORITY="3 normal"
export OTRS_DEFAULT_TYPE="Unclassified"

그런 다음 Claude Desktop 구성 파일을 편집하고 서버 구성을 추가하세요:

{
  "mcpServers": {
    "otrs": {
      "command": "uv",
      "args": [
        "--directory",
        "<full path to otrs-mcp-server directory>",
        "run",
        "src/otrs_mcp/main.py"
      ],
      "env": {
        "OTRS_BASE_URL": "https://your-otrs-server/otrs/nph-genericinterface.pl/Webservice/TestInterface",
        "OTRS_USERNAME": "your-username",
        "OTRS_PASSWORD": "your-password",
        "OTRS_VERIFY_SSL": "false"
      }
    }
  }
}

참고: Claude Desktop에서 Error: spawn uv ENOENT 오류가 표시되면 uv의 전체 경로를 지정하거나 구성에서 환경 변수 NO_UV=1을 설정해야 할 수 있습니다.

환경 변수

변수	필수	기본값	설명
`OTRS_BASE_URL`	✅	-	OTRS 웹 서비스 기본 URL
`OTRS_USERNAME`	✅	-	OTRS 사용자 이름
`OTRS_PASSWORD`	✅	-	OTRS 비밀번호
`OTRS_VERIFY_SSL`	❌	`false`	SSL 인증서 검증 활성화
`OTRS_DEFAULT_QUEUE`	❌	`Raw`	새 티켓의 기본 큐
`OTRS_DEFAULT_STATE`	❌	`new`	새 티켓의 기본 상태
`OTRS_DEFAULT_PRIORITY`	❌	`3 normal`	새 티켓의 기본 우선순위
`OTRS_DEFAULT_TYPE`	❌	`Unclassified`	새 티켓의 기본 유형

개발

기여는 언제나 환영합니다! 제안이나 개선 사항이 있으면 이슈를 열거나 풀 리퀘스트를 제출해 주세요.

이 프로젝트는 Python 3.12를 대상으로 하며(pyproject.toml의 requires-python 참조), 해당 버전에서 프로덕션 사용이 검증되었습니다.

이 프로젝트는 uv를 사용하여 의존성을 관리합니다. 플랫폼에 맞는 지침에 따라 uv를 설치하세요:

curl -LsSf https://astral.sh/uv/install.sh | sh

Python 3.12를 설치하고(아직 없는 경우) 고정된 의존성으로 가상 환경을 생성하세요:

# Install the interpreter (managed by uv)
uv python install 3.12

# Create the environment and install dependencies from uv.lock
uv sync --python 3.12 --extra dev

또는 기존 워크플로우를 사용할 수도 있습니다:

uv venv --python 3.12
source .venv/bin/activate  # On Unix/macOS
.venv\Scripts\activate     # On Windows
uv pip install -e .

테스트

OTRS 연결 및 API 기능을 테스트하세요:

# Set environment variables
export OTRS_BASE_URL="https://your-otrs-server/otrs/nph-genericinterface.pl/Webservice/TestInterface"
export OTRS_USERNAME="your-username"
export OTRS_PASSWORD="your-password"
export OTRS_VERIFY_SSL="false"

# Run connectivity test
uv run python tests/connectivity_test.py

# Run API functionality test
uv run python tests/test_working_api.py

# Run debug diagnostics
uv run python tests/debug_test.py

프로젝트에는 OTRS 구성과 API 연결을 확인하는 데 도움이 되는 테스트 스크립트가 포함되어 있습니다.

pytest로 테스트를 실행하세요:

# Install development dependencies
uv pip install -e ".[dev]"

# Run the tests
pytest

# Run with coverage report
pytest --cov=src --cov-report=term-missing

Docker 이미지 게시

공개 사용을 위해 Docker 이미지를 GitHub Container Registry에 게시하려면:

사전 요구 사항

이 프로젝트를 위한 GitHub 계정 및 저장소
write:packages 권한이 있는 GitHub Personal Access Token
로컬에 설치된 Docker

단계별 게시 방법

GitHub Personal Access Token 생성:
- GitHub 설정 → 개발자 설정 → Personal access tokens → Tokens (classic)로 이동
- write:packages 및 read:packages 권한으로 새 토큰 생성
- 토큰을 안전하게 보관

GitHub Container Registry에 로그인:

echo $GITHUB_TOKEN | docker login ghcr.io -u yourusername --password-stdin

이미지 빌드 및 태그 지정:

# Build the image
docker build -t otrs-mcp-server .

# Tag for GitHub Container Registry
docker tag otrs-mcp-server ghcr.io/yourusername/otrs-mcp-server:latest
docker tag otrs-mcp-server ghcr.io/yourusername/otrs-mcp-server:v0.1.0

레지스트리에 푸시:

# Push latest tag
docker push ghcr.io/yourusername/otrs-mcp-server:latest

# Push version tag
docker push ghcr.io/yourusername/otrs-mcp-server:v0.1.0

패키지 공개 설정 (선택 사항):
- GitHub 저장소로 이동
- Packages 섹션으로 이동
- 패키지 클릭
- Package settings로 이동
- 공개 범위를 Public으로 변경

GitHub Actions를 통한 자동 게시

.github/workflows/docker-publish.yml 생성:

name: Build and Push Docker Image

on:
  push:
    branches: [main]
    tags: ["v*"]
  pull_request:
    branches: [main]

env:
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}

jobs:
  build-and-push:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Log in to Container Registry
        uses: docker/login-action@v3
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Extract metadata
        id: meta
        uses: docker/metadata-action@v5
        with:
          images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
          tags: |
            type=ref,event=branch
            type=ref,event=pr
            type=semver,pattern={{version}}
            type=semver,pattern={{major}}.{{minor}}

      - name: Build and push Docker image
        uses: docker/build-push-action@v5
        with:
          context: .
          push: ${{ github.event_name != 'pull_request' }}
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}

대안: Docker Hub

대신 Docker Hub에 게시하려면:

# Login to Docker Hub
docker login

# Tag for Docker Hub
docker tag otrs-mcp-server yourusername/otrs-mcp-server:latest
docker tag otrs-mcp-server yourusername/otrs-mcp-server:v0.1.0

# Push to Docker Hub
docker push yourusername/otrs-mcp-server:latest
docker push yourusername/otrs-mcp-server:v0.1.0

그런 다음 Claude Desktop 구성을 다음과 같이 업데이트하세요:

"ghcr.io/yourusername/otrs-mcp-server:latest"

또는

"yourusername/otrs-mcp-server:latest"

사용 가능한 도구

🎫 티켓 관리

create_ticket - OTRS에 새 티켓 생성
get_ticket - 특정 티켓에 대한 상세 정보 조회
search_tickets - 다양한 기준으로 티켓 검색
update_ticket - 기존 티켓의 속성 수정
get_ticket_history - 티켓의 전체 이력 조회

📊 리소스

otrs://ticket/{ticket_id} - 티켓 데이터 직접 접근
otrs://ticket/{ticket_id}/history - 티켓 이력 접근
otrs://search/tickets - 최근 티켓 개요

문제 해결

일반적인 문제

SSL 인증서 오류: 자체 서명 인증서의 경우 OTRS_VERIFY_SSL=false로 설정
HTTP 301 리디렉션: OTRS 서버가 HTTP를 HTTPS로 리디렉션하는 경우 HTTPS URL을 사용하고 있는지 확인
인증 실패: 사용자 이름, 비밀번호, 웹 서비스 구성을 확인
누락된 작업: OTRS 웹 서비스에 필요한 모든 작업이 포함되어 있는지 확인

디버그 모드

연결 문제를 진단하려면 디버그 스크립트를 실행하세요:

uv run python tests/debug_test.py

이 스크립트는 HTTP와 HTTPS 연결을 모두 테스트하고 자세한 오류 정보를 제공합니다.

작동 구성 예시

참고용으로 작동하는 구성 예시는 다음과 같습니다:

# Environment variables
export OTRS_BASE_URL="https://your-otrs-server/otrs/nph-genericinterface.pl/Webservice/TestInterface"
export OTRS_USERNAME="your-username"
export OTRS_PASSWORD="your-password"
export OTRS_VERIFY_SSL="false"
export OTRS_DEFAULT_QUEUE="Raw"
export OTRS_DEFAULT_STATE="new"
export OTRS_DEFAULT_PRIORITY="3 normal"
export OTRS_DEFAULT_TYPE="Unclassified"

OTRS 웹 서비스 작업

OTRS 웹 서비스에는 다음 작업이 포함되어야 합니다:

작업 이름	컨트롤러	설명
TicketCreate	Ticket::TicketCreate	새 티켓 생성
TicketGet	Ticket::TicketGet	티켓 세부 정보 조회
TicketSearch	Ticket::TicketSearch	티켓 검색
TicketUpdate	Ticket::TicketUpdate	기존 티켓 수정
TicketHistoryGet	Ticket::TicketHistoryGet	티켓 이력 조회

라이선스

Apache-2.0

Available Tools

5 tools

create_ticketC

Create a new ticket in OTRS

Name	Required	Description	Default
`body`	Yes
`queue`	No
`state`	No
`title`	Yes
`priority`	No
`ticket_type`	No
`customer_user`	No

Output Schema

Name	Required	Description
No output parameters

TDQS

C2.7/5.0

Behavior2/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 of disclosing side effects. It only names the action without noting that a persistent OTRS record is created, whether calls are idempotent, whether authentication is required, or what errors may occur.

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?

A single 7-word sentence with zero filler and the verb front-loaded. It is appropriately brief, though it borders on under-specification rather than genuine explanatory economy.

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?

A 7-parameter tool with no annotations and no parameter descriptions needs far more than a purpose statement; the description omits the required title/body contract and how optional fields are validated. The presence of an output schema covers return values, which keeps this from a 1, but an agent still lacks essential calling context.

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

Parameters2/5

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

Schema description coverage is 0% across 7 parameters, so the description must compensate, but it names no parameters at all. An agent is left with bare parameter names (body, queue, state, priority, ticket_type, customer_user) plus title, with no format, allowable-value, or domain guidance.

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

Purpose4/5

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

States a specific verb ('Create') and resource ('a new ticket in OTRS'), and the word 'new' cleanly separates it from the update_ticket sibling. It is accurate and unambiguous, though it adds only the 'in OTRS' context beyond what the tool name already communicates.

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 get_ticket, search_tickets, or update_ticket. No prerequisites, ordering constraints, or when-not-to-use conditions are mentioned; usage context must be entirely inferred from the tool name.

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

get_ticketB

Get ticket details from OTRS

Name	Required	Description	Default
`ticket_id`	Yes
`include_extended_data`	No
`include_dynamic_fields`	No

Output Schema

Name	Required	Description
No output parameters

TDQS

B3.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 burden of indicating safety; the word 'Get' clearly conveys a read-only retrieval with no mutation, which is useful. However, it adds no detail about access requirements, behavior of the include flags, or potential response size, though some of this is covered by the output schema.

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 sentence, front-loaded with the verb and object, with no filler. It is appropriately sized for a simple retrieval tool.

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 output schema covers return shape, so that burden is lifted. Still, with no annotations and sibling tools present, the description doesn't clarify when to choose this tool or how extended data and dynamic fields affect the result, leaving clear gaps in context.

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

Parameters2/5

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

Schema description coverage is 0% and the description adds no parameter-specific meaning beyond the raw schema titles. The required ticket_id is inferable from tool name, but include_extended_data and include_dynamic_fields are not explained, making this less than adequate.

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

Purpose4/5

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

The description clearly identifies a get operation on ticket details from OTRS, which is the correct resource and verb. It does not explicitly contrast with siblings such as get_ticket_history or search_tickets, so it stops short of the top score.

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 given about when to use this tool over search_tickets, get_ticket_history, or other siblings. The meaning is inferable but not stated; an agent is not told that this is for fetching a single known ticket by ID.

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

get_ticket_historyC

Get ticket history from OTRS

Name	Required	Description	Default
`ticket_id`	Yes

Output Schema

Name	Required	Description
No output parameters

TDQS

C2.8/5.0

Behavior2/5

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

No annotations are present, so the description carries the full burden. It indicates a read operation but does not disclose what 'history' includes, whether it returns change logs versus messages, what auth or prerequisites are needed, or how results are ordered/limited.

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 efficient sentence with no filler. It could carry more useful detail, but it is well-structured and front-loaded for a simple tool.

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?

With only one parameter and an output schema available, the basic invocation path is reasonably clear. However, the description lacks enough detail about what constitutes ticket history and under what circumstances to choose this over get_ticket, leaving some ambiguity.

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

Parameters2/5

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

Schema description coverage is 0%, and the description does not explain the ticket_id parameter beyond its name and string type. The parameter name is fairly self-explanatory, but the description adds no semantic value to compensate for the missing schema documentation.

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

Purpose4/5

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

The description states a clear verb ('Get'), a specific resource ('ticket history'), and the system ('OTRS'). It is distinguishable from siblings like get_ticket by name and resource, though it does not explicitly contrast itself with them.

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?

There is no guidance on when to use this tool versus get_ticket or search_tickets. The intended context is implied by the name and description, but no exclusions, alternatives, or conditions are provided.

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

search_ticketsC

Search for tickets in OTRS

Name	Required	Default
`limit`	No
`queue`	No
`state`	No
`title`	No
`sort_by`	No	Age
`order_by`	No	Down
`priority`	No
`customer_id`	No
`customer_user`	No

Output Schema

Name	Required	Description
No output parameters

TDQS

C2.4/5.0

Behavior2/5

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

No annotations exist, so the description carries the full disclosure burden, yet it reveals nothing about match semantics, how filters combine, the default sort (Age/Down), or limit/pagination behavior. The output schema helps with return shape but not with behavioral traits an agent needs to predict the tool's effect.

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

Conciseness3/5

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

The single sentence is lean and front-loaded with the core action, but for a tool with 9 optional parameters, this brevity is under-specification rather than efficient structure. There are no wasted words, yet no additional context is packed into the available space.

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

Completeness2/5

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

Given moderate complexity (9 optional filters, no annotations, 0% schema coverage), the description is far too thin to support correct invocation. An agent would not know how filters behave, what values queue/state accept, or how sorting works; the output schema covers only what is returned, not how to call the tool properly.

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

Parameters1/5

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

Schema description coverage is 0% across 9 parameters, and the description does nothing to compensate. It never mentions the filter parameters, does not explain valid values for sort_by/order_by, and does not clarify the distinction between customer_id and customer_user, leaving the agent to guess parameter meaning.

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

Purpose4/5

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

The description states a specific verb ('Search') and resource ('tickets in OTRS'), clearly identifying the tool's core action. The sibling tools use distinct verbs (create, get, update, get_history), so search is implicitly differentiated as the query-multiple-tickets operation, though no explicit contrast is given.

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. An agent must infer that get_ticket retrieves a single ticket while search_tickets finds tickets by criteria, but nothing states this, and no exclusions or alternative recommendations are offered.

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

update_ticketC

Update an existing ticket in OTRS

Name	Required	Description	Default
`owner`	No
`queue`	No
`state`	No
`title`	No
`priority`	No
`ticket_id`	Yes
`customer_user`	No

Output Schema

Name	Required	Description
No output parameters

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations provided, the description must disclose behavioral details on its own. It communicates that the tool mutates an existing ticket, but it does not explain whether updates are partial, what fields are affected, what authorization is needed, or how invalid ticket IDs are handled.

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 front-loaded sentence with no filler or redundancy. It is concise, though its brevity contributes to the under-specification penalized in other dimensions.

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?

For a tool with 7 parameters and no annotation or schema descriptions, one short sentence is insufficient. The description covers the core operation but omits field-level update semantics, optionality behavior, and error conditions; the presence of an output schema only accounts for return values, not input behavior.

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

Parameters1/5

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

Schema description coverage is 0% and the description adds no parameter information. The 7 parameters, including optional nullable fields like state, priority, and owner, are left entirely to the agent to infer from their titles, so the description fails to compensate for the schema's lack of explanations.

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

Purpose4/5

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

The description states a specific action and resource: 'Update an existing ticket in OTRS'. It clearly indicates this tool modifies an already-created ticket, which distinguishes it from create_ticket and the read-only siblings, but it does not enumerate the updatable fields or explicitly name alternatives.

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?

Usage is only implied: use this tool when an existing OTRS ticket needs to be modified. There is no explicit guidance on when to prefer it over create_ticket or get_ticket, and no conditions, prerequisites, or exclusions are provided.

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.

5 tool updatesv0.2.0Aug 30, 2026
- First observedcreate_ticket
- First observedget_ticket
- First observedget_ticket_history
- First observedsearch_tickets
- First observedupdate_ticket

Deploy Server

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

TDQS

B3.3/5.0

Scored 2026-08-30 07:00 across 5 tools

Disambiguation5/5

Each tool targets a distinct operation on tickets: create, retrieve individual details, search, update, and retrieve history. There is no meaningful overlap between get_ticket and get_ticket_history because one returns current state and the other returns the audit trail.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with snake_case: create_ticket, get_ticket, search_tickets, update_ticket, get_ticket_history. The only minor variation is the plural 'tickets' in search_tickets, which is natural and does not break the pattern.

Tool Count5/5

Five tools is well-scoped for a ticket management server. Each tool represents a core operation without unnecessary redundancy, making the set easy to navigate.

Completeness5/5

The tool surface covers the essential ticket lifecycle: creation, retrieval, search, update, and history lookup. For OTRS, this is a complete and practical set with no obvious dead ends.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

Related MCP Connectors

Bitrix24 B
io.github.bitrix24
MCP server enabling AI agents to manage Bitrix24 features via standardized protocol
ERP Systems Project Management Communication
2
https://mcp.bitrix24.com/mcp/
inbrix
ai.inbrix
AI-native helpdesk hosted in Germany: tickets, replies, KPIs and knowledge base over MCP.
Customer Support
1
https://app.inbrix.ai/api/mcp
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
https://api.artificialwit.com/mcp
mttrly
com.mttrly
AI-powered incident management and server monitoring via MCP.
Monitoring Observability
3
https://api.mttrly.com/mcp

Related MCP Servers

Personal JIRA MCP
Project Management App Automation
yuezheng2006
A
license
C
quality
C
maintenance
An MCP server that enables AI assistants to interact with JIRA, allowing for querying issue details, creating and updating work items, and managing attachments through a standardized interface.
Updated a year ago (2025-05-20 17:01 UTC)
12
4
MIT
tickiti-mcpofficial
Customer Support Communication
tickiti
A
license
B
quality
B
maintenance
An MCP server that exposes the Tickiti helpdesk API to AI assistants, enabling ticket management and helpdesk operations via natural language.
Updated 12 days ago (2026-10-25 11:19 UTC)
11
MIT
mcp-otobo
Customer Support Project Management
domnussbaum
A
license
A
quality
D
maintenance
MCP server for Otobo ITSM enabling AI assistants to search, create, update, and manage tickets via the Generic Interface REST API.
Updated 8 months ago (2026-02-27 14:46 UTC)
10
6 npm
1
MIT
Zammad MCP Server
Customer Support CRM
basher83
A
license
Not graded
quality
A
maintenance
An MCP server that connects AI assistants to Zammad, providing tools for managing tickets, users, organizations, and attachments.
Updated 16 hours ago (2026-11-05 12:26 UTC)
48
AGPL 3.0

OTRS MCP 서버

기능

사전 요구 사항

OTRS 서버 구성

1단계: OTRS 관리자 패널 접속

2단계: 웹 서비스 구성

3단계: 웹 서비스 URL 확인

4단계: 사용자 권한 확인

사용 방법

Docker (권장)

사전 빌드된 이미지 사용

로컬에서 빌드

UV로 실행

환경 변수

개발

테스트

Docker 이미지 게시

사전 요구 사항

단계별 게시 방법

GitHub Actions를 통한 자동 게시

대안: Docker Hub

사용 가능한 도구

🎫 티켓 관리

📊 리소스

문제 해결

일반적인 문제

디버그 모드

작동 구성 예시

OTRS 웹 서비스 작업

라이선스

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

tickiti-mcpofficial