导航到：系统管理 → Web 服务
创建或确认您有一个包含以下操作的 Web 服务（例如“TestInterface”）：
- ✅ SessionCreate
- ✅ TicketCreate
- ✅ TicketGet
- ✅ TicketSearch
- ✅ TicketUpdate
- ✅ TicketHistoryGet

步骤 3：记下您的 Web 服务 URL

您的 Web 服务 URL 应类似于：

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

步骤 4：确保用户权限

确保您的 OTRS 用户具有适当的权限，以便：

创建和更新工单
访问配置项
使用通用接口

使用方法

Docker（推荐）

使用 Claude Desktop 运行 otrs-mcp 的最简单方式是使用 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 Web 服务的基础 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 账户，并拥有此项目的仓库
GitHub 个人访问令牌，具有 write:packages 权限
本地安装 Docker

分步发布

创建 GitHub 个人访问令牌：
- 转到 GitHub 设置 → 开发者设置 → 个人访问令牌 → 令牌（经典）
- 生成具有 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 仓库
- 导航到“包”部分
- 点击您的包
- 转到“包设置”
- 将可见性更改为“公开”

使用 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
身份验证失败：验证您的用户名、密码和 Web 服务配置
缺少操作：检查您的 OTRS Web 服务是否包含所有必需的操作

调试模式

运行调试脚本以诊断连接问题：

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 Web 服务操作

您的 OTRS Web 服务应包含以下操作：

操作名称	控制器	描述
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.

Resources

Related MCP Connectors

Bitrix24B
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
Station Zero
services.stationzero
One MCP server for the services your AI needs: memory, files, Microsoft 365, kanban and more.
Knowledge & Memory File Systems Workplace & Productivity
1
https://stationzero.services/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

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 13 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
B
maintenance
An MCP server that connects AI assistants to Zammad, providing tools for managing tickets, users, organizations, and attachments.
Updated a day ago (2026-11-06 23:00 UTC)
48
AGPL 3.0

OTRS MCP Server

功能特性

前提条件

OTRS 服务器配置

步骤 1：访问 OTRS 管理面板

步骤 2：配置 Web 服务

步骤 3：记下您的 Web 服务 URL

步骤 4：确保用户权限

使用方法

Docker（推荐）

使用预构建镜像

本地构建

使用 UV 运行

环境变量

开发

测试

发布 Docker 镜像

前提条件

分步发布

使用 GitHub Actions 自动发布

替代方案：Docker Hub

可用工具

🎫 工单管理

📊 资源

故障排除

常见问题

调试模式

示例工作配置

OTRS Web 服务操作

许可证

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Resources

Related MCP Connectors

Related MCP Servers

tickiti-mcpofficial