tiflux-mcp - Tiflux任務管理AI集成MCP協議工具

探索

Tiflux MCP

#null .JavaScript

評分 : 2分

下載量 : 5.1K

更新時間 : 2026-06-17

打開站點

安裝

複製以下命令到你的Client進行配置

{
  "mcpServers": {
    "tiflux": {
      "type": "url",
      "url": "https://mcp.tiflux.com/mcp",
      "headers": {
        "x-tiflux-api-key": "YOUR_API_KEY"
      }
    }
  }
}

注意：您的密鑰屬於敏感信息，請勿與任何人分享。

🚀 TiFlux MCP 服務器

用於 TiFlux 與 Claude Code 及其他 AI 客戶端集成的 模型上下文協議 (MCP) 服務器。

藉助 MCP，AI 助手可以直接查詢和操作 TiFlux 平臺中的工單、客戶、聊天、預約等數據，實現智能化的服務檯自動化。

✨ 主要特性

🎫 工單管理：獲取、創建、更新、關閉和列出工單，支持全面的過濾條件
📊 階段與 SLA 歷史：查看工單階段完整流轉歷史及每個階段的 SLA 結果
💬 內部溝通：為工單創建和列出內部溝通，支持文件附件
⏱️ 時間跟蹤（預約）：為工單創建和列出工時預約記錄
🗨️ 聊天管理：列出收件箱 / 我的 / 服務中 / 已歸檔聊天，獲取聊天詳情，轉接 / 關聯聊天，發送 WhatsApp 消息並結束聊天
🖥️ 服務檯探索：無需離開聊天即可列出可用服務檯並查看完整配置（SLA、字段、行為）
🔍 自定義字段發現：在實體 → 字段 → 選項三個層級發現自定義字段，使 LLM 能夠使用正確的選項 ID 填寫 checkbox / single_select 字段
👥 客戶 CRUD：賬戶全生命週期管理 —— 獲取、創建、更新、帶過濾條件列表，關聯服務檯 / 技術組、門戶用戶以及郵件權限
📎 文件上傳支持：最多可向內部溝通附加 10 個文件（每個 25MB）
🔌 API 集成：與 TiFlux API v2 直接集成
⚙️ 環境配置：通過環境變量進行安全配置
🧪 全面測試：自動化測試，100% Mock 隔離

🚀 快速開始

📦 安裝

npm install -g @tiflux/mcp

💻 使用方式

與 Claude Code 配合使用

將以下內容添加到你的 MCP 配置中：

{
  "tiflux": {
    "command": "npx",
    "args": ["@tiflux/mcp@latest"]
  }
}

與其他 MCP 客戶端配合使用

npx @tiflux/mcp@latest

通過 URL（HTTP 傳輸）

服務端點： https://mcp.tiflux.com/mcp

claude mcp add tiflux-lambda --transport http https://mcp.tiflux.com/mcp --header "x-tiflux-api-key:APIKEY" -s project

手動配置

添加到 .claude/settings.json 或 ~/.claude.json：

{
  "mcpServers": {
    "tiflux": {
      "type": "url",
      "url": "https://mcp.tiflux.com/mcp",
      "headers": {
        "x-tiflux-api-key": "YOUR_API_KEY"
      }
    }
  }
}

端點說明

端點	方法	鑑權	說明
`/mcp`	GET	否	服務器信息
`/mcp`	POST	是	MCP 操作
`/health`	GET	否	健康檢查

通過 Web（OAuth 2.0）—— Claude web 與 ChatGPT 連接器

你可以在任何支持 MCP over OAuth 2.0 的 AI 平臺上將 TiFlux 作為連接器 (Connector) 使用 —— 例如 Claude（claude.ai / 桌面端） 和 ChatGPT —— 無需本地安裝。只需添加一個指向 TiFlux MCP 服務器 URL 的自定義連接器即可。

MCP 服務器 URL（在連接器中粘貼此地址）：

https://mcp.tiflux.com

添加連接器：

Claude（claude.ai / 桌面端）： 設置 → 連接器 → 添加自定義連接器 → 粘貼 https://mcp.tiflux.com → 連接。
ChatGPT： 設置 → 連接器（或在構建 GPT 時點擊添加連接器）→ 粘貼 https://mcp.tiflux.com → 連接。

授權流程如下：

添加連接器後，平臺會自動打開 TiFlux 授權頁面。
頁面會顯示生成 TiFlux API Key 的分步指南：
- 登錄 app.tiflux.com
- 點擊頭像 → Minha conta
- 打開 Sessões 標籤頁
- 在 Sessões API 下點擊 "Gerar novo token de sessão"
- 複製生成的 Key 並粘貼到授權表單中
授權完成後，平臺會收到一個 Bearer token，並用於後續所有 MCP 請求 —— 之後無需再次處理該 Key。

若使用 Claude Code 或本地 / 腳本方式並直接使用 API Key 頭，請參考上方的通過 URL（HTTP 傳輸）。

支持的鑑權方式：

方式	請求頭	適用場景
API Key（直接）	`x-tiflux-api-key: YOUR_API_KEY`	Claude Code、本地 SDK、腳本
Bearer token（OAuth）	`Authorization: Bearer <token>`	Claude.ai、ChatGPT、Web 連接器

OAuth 2.0 端點：

端點	說明
`GET /.well-known/oauth-authorization-server`	OAuth 服務器元數據 (RFC 8414)
`POST /register`	動態客戶端註冊 (RFC 7591)
`GET /authorize`	授權頁面（用戶輸入 API Key）
`POST /authorize`	表單提交 —— 簽發授權碼
`POST /token`	Token 交換與刷新

⚙️ 配置

創建 .env 文件並填入你的 TiFlux API 憑據：

# TiFlux API Configuration
TIFLUX_API_KEY=your_api_key_here

# Default values for ticket creation
TIFLUX_DEFAULT_CLIENT_ID=1
TIFLUX_DEFAULT_DESK_ID=1
TIFLUX_DEFAULT_PRIORITY_ID=1
TIFLUX_DEFAULT_CATALOG_ITEM_ID=1

🧰 可用工具

`get_ticket`

按 ID 獲取指定工單，返回包含狀態、優先級、服務檯、階段、服務目錄、負責人、客戶、審計數據、SLA 及 URL 在內的完整信息。

參數：

ticket_number (string, 必填)：要獲取的工單編號
show_entities (boolean, 可選)：包含所有關聯到該工單的自定義字段
include_filled_entity (boolean, 可選)：僅包含已填寫值的自定義字段

返回： 包含以下內容的完整工單信息：

狀態（ID、名稱、開啟 / 關閉標誌）
優先級（ID、名稱）
服務檯（ID、內部名稱、顯示名稱、激活狀態）
階段（ID、名稱、首 / 末階段標誌、最大耗時）
服務目錄（條目 ID、條目名、區域、目錄）
負責人（ID、姓名、郵箱、類型、技術組）
客戶（ID、名稱、社會名稱、激活狀態）
審計（創建人 ID、來源、創建 / 更新日期）
SLA（狀態、到期時間、截止時間）
附加信息（關注者、已用工時、重開次數、內部 / 外部 URL）

v1.4.0 新增： 擴展字段，可在單次調用中獲取完整的工單元數據。

`create_ticket`

在 TiFlux 中創建新工單。

參數：

title (string, 必填)：工單標題
description (string, 必填)：工單描述。支持 Markdown（粗體、列表、標題、代碼）—— MCP 會在發送到 API 前自動轉換為 HTML。
client_id (number, 可選)：客戶（公司）ID
client_name (string, 可選)：客戶（公司）名稱，用於自動搜索（client_id 的替代方案）。僅在用戶明確提到"客戶"或"公司"時使用。
desk_id (number, 可選)：服務檯 ID
desk_name (string, 可選)：服務檯 / 團隊名稱，用於自動搜索（desk_id 的替代方案）。支持部分名稱 —— 例如 "cansados" 可解析為 "Dev - Cansados"（詳見智能名稱解析）。當用戶引用的名稱未明確實體類型時，優先使用此字段。
priority_id (number, 可選)：優先級 ID
services_catalogs_item_id (number, 可選)：服務目錄條目 ID
catalog_item_name (string, 可選)：目錄條目名稱，用於自動搜索（services_catalogs_item_id 的替代方案，需搭配 desk_id 或 desk_name）
status_id (number, 可選)：狀態 ID
requestor_id (number, 可選)：請求人 ID（開單人員，必須歸屬於選定的客戶）。如果你已知 ID，可直接傳入 —— 會跳過自動解析查詢。
requestor_name (string, 可選)：請求人姓名。若未提供 requestor_id 且未提供 requestor_email，MCP 會自動嘗試將其解析為已存在的 requestor_id（避免創建"幽靈"請求人）。若匹配到多個，將返回列表以便消歧。若無匹配，則回退到之前的行為（按原文發送姓名）。
requestor_email (string, 可選)：請求人郵箱。提供後，MCP 不會嘗試自動將姓名解析為 ID —— 郵箱已經是足夠精確的標識。
requestor_telephone (string, 可選)：請求人電話
responsible_id (number, 可選)：負責人用戶 ID
responsible_name (string, 可選)：負責人姓名，用於自動搜索（responsible_id 的替代方案）
followers (string, 可選)：逗號分隔的關注者郵箱
parent_ticket_number (number, 可選)：父工單編號 —— 新建的工單將作為該工單的子工單關聯
files_base64 (array, 可選)：base64 編碼的文件數組 [{content: "base64...", filename: "file.png"}]（最多 10 個文件，每個最大 25MB）

v2.4.0 新增： 通過 files_base64 支持 base64 文件上傳。工單將以 multipart/form-data 形式發送。服務器模式（Lambda）注意事項： files_base64 負載受 API Gateway 6MB 限制約束。

⚠️ 破壞性變更 (v2.8.0)： 參數 files（本地路徑）已被移除。請使用新工具 upload_ticket_files 通過 base64 上傳文件，或直接通過 files_base64 傳入文件。

`update_ticket`

更新 TiFlux 中已有的工單。

參數：

ticket_id (string, 必填)：要更新的工單 ID
title (string, 可選)：新的工單標題
description (string, 可選)：新的工單描述。支持 Markdown（粗體、列表、標題、代碼）—— MCP 會在發送到 API 前自動轉換為 HTML。
client_id (number, 可選)：新的客戶 ID
desk_id (number, 可選)：新的服務檯 ID
desk_name (string, 可選)：服務檯名稱，用於自動搜索（desk_id 的替代方案）。支持部分名稱 —— 例如 "cansados" 可解析為 "Dev - Cansados"（詳見智能名稱解析）
stage_id (number, 可選)：階段 / 環節 ID
stage_name (string, 可選)：階段名稱，用於自動搜索（stage_id 的替代方案，需搭配 desk_id 或 desk_name）
responsible_id (number, 可選)：負責人用戶 ID（使用 null 取消分配）
responsible_name (string, 可選)：負責人姓名，用於自動搜索（responsible_id 的替代方案）
followers (string, 可選)：逗號分隔的關注者郵箱
services_catalogs_item_id (number, 可選)：目錄條目 ID，用於以特定條目更新服務檯
catalog_item_name (string, 可選)：目錄條目名稱，用於自動搜索（services_catalogs_item_id 的替代方案，需搭配 desk_id 或 desk_name）

注意： 除 ticket_id 外，至少要提供一個可選字段。

`update_ticket_entities`

更新 TiFlux 中工單的自定義字段（實體）。單次請求最多支持 50 個字段。對於具有多個命名選項的 checkbox 字段，每個選項發送一個條目並帶上 entity_field_option_id。使用 list_entity_field_options 發現選項 ID。

參數：

ticket_number (string, 必填)：要更新的工單編號
entities (array, 必填)：要更新的自定義字段列表。對於多選題 checkbox 字段，每個選項發送一個條目。

實體對象結構：

entity_field_id (number, 必填)：自定義字段 ID（可通過 get_ticket 或 list_entity_fields 獲取）
value (string, 必填)：字段值。可接受類型：
- text：字符串
- text_area：字符串
- currency：字符串形式的浮點數（例如 "150.55"）
- phone：僅數字（例如 "47999999999"）
- email：字符串
- link：以 http/https/ftp 開頭的 URL
- date：格式 YYYY-MM-DD
- single_select：字符串形式的選項 ID
- checkbox：字符串形式的布爾值 "true" / "false"
- 使用 null 清空非必填字段
entity_field_option_id (number, 可選)：checkbox 多選題字段的選項 ID。使用 list_entity_field_options 獲取 ID。對於多選題 checkbox，每發送一個條目需使用相同的 entity_field_id 和不同的 entity_field_option_id。
country_code (string, 可選)：國家代碼（用於巴西以外的電話字段）

示例 —— 簡單的文本 / 日期字段：

{
  "ticket_number": "123",
  "entities": [
    {
      "entity_field_id": 72,
      "value": "New value"
    },
    {
      "entity_field_id": 73,
      "value": "2025-01-15"
    }
  ]
}

示例 —— 帶多個命名選項的 checkbox：

{
  "ticket_number": "12345",
  "entities": [
    { "entity_field_id": 81, "entity_field_option_id": 11, "value": "true" },
    { "entity_field_id": 81, "entity_field_option_id": 12, "value": "false" },
    { "entity_field_id": 81, "entity_field_option_id": 13, "value": "true" }
  ]
}

`cancel_ticket`

取消 TiFlux 中的指定工單。

參數：

ticket_number (string, 必填)：要取消的工單編號（例如 "37"、"123"）

示例：

{
  "ticket_number": "84429"
}

`list_tickets`

列出工單，支持過濾條件。

參數：

desk_ids (string, 可選)：逗號分隔的服務檯 ID（例如 "1,2,3"）
desk_name (string, 可選)：服務檯 / 團隊名稱，用於自動 ID 解析。支持部分名稱 —— 例如 "cansados" 可解析為 "Dev - Cansados"（詳見智能名稱解析）。當用戶引用的名稱未明確實體類型時，優先使用此字段。
client_ids (string, 可選)：逗號分隔的客戶（公司）ID（例如 "1,2,3"）
client_name (string, 可選)：客戶（公司）名稱，用於自動搜索。僅當用戶明確提到"客戶"、"公司"或給出已知企業名稱時使用。若為個人，優先使用 requestor_email。
stage_ids (string, 可選)：逗號分隔的階段 ID（例如 "1,2,3"）
stage_name (string, 可選)：階段名稱（必須與 desk_name 配合使用）
responsible_ids (string, 可選)：逗號分隔的負責人（被分配的服務人員）用戶 ID（已知 ID 時使用）
responsible_name (string, 可選)：負責人姓名，用於自動解析。對管理員用戶（通過 GET /users）和非管理員用戶（通過服務人員組回退）均有效。當用戶說"分配給" / "負責"並給出姓名時使用。
requestor_ids (string, 可選)：逗號分隔的請求人（開單人員）ID（例如 "1,2,3"）。用於按個人（而非公司）過濾。通過 search_user(type="client") 解析 ID。
requestor_email (string, 可選)：請求人（開單人員）郵箱。當用戶引用個人或直接提供郵箱時使用。可避免一次解析 ID 的往返調用。
offset (number, 可選)：頁碼（默認 1）
limit (number, 可選)：每頁條目數（默認 20，最大 200）
is_closed (boolean, 可選)：是否包含已關閉工單（默認 false）
date_type (string, 可選)：日期過濾類型："created_at"（創建日期，默認）或 "solved_in_time"（解決 / 關閉日期）
start_datetime (string, 可選)：起始日期 / 時間過濾，ISO 8601 格式（例如 "2024-05-15T00:00:00Z"）。篩選日期 >= start_datetime 的工單
end_datetime (string, 可選)：結束日期 / 時間過濾，ISO 8601 格式（例如 "2024-05-15T23:59:59Z"）。篩選日期 <= end_datetime 的工單

注意： 至少需要一個過濾條件（desk_ids/desk_name、client_ids/client_name、stage_ids/stage_name、responsible_ids/responsible_name、requestor_ids 或 requestor_email）。

示例 —— 按請求人郵箱過濾：

{
  "requestor_email": "joao@empresa.com",
  "is_closed": false
}

日期過濾示例：

// List tickets created in a specific date range (including closed ones)
{
  "desk_name": "Support",
  "date_type": "created_at",
  "start_datetime": "2024-01-01T00:00:00Z",
  "end_datetime": "2024-01-31T23:59:59Z",
  "is_closed": true
}

// List tickets resolved in a specific period
{
  "desk_name": "Support",
  "date_type": "solved_in_time",
  "start_datetime": "2024-01-01T00:00:00Z",
  "end_datetime": "2024-01-31T23:59:59Z",
  "is_closed": true
}

`close_ticket`

關閉 TiFlux 中的指定工單。

參數：

ticket_number (string, 必填)：要關閉的工單編號（例如 "37"、"123"）

示例：

{
  "ticket_number": "84429"
}

成功響應：

**Ticket #84429 fechado com sucesso!**

**Mensagem:** Ticket 84429 closed successfully

*Ticket fechado via API TiFlux*

`create_ticket_answer`

在指定工單中創建新答覆（面向客戶的溝通）。

參數：

ticket_number (string, 必填)：要創建答覆的工單編號
text (string, 必填)：將發送給客戶的答覆內容。支持 Markdown（粗體、列表、標題、代碼）—— MCP 會在發送到 API 前自動轉換為 HTML。
with_signature (boolean, 可選)：在答覆中包含用戶簽名（默認 false）
files_base64 (array, 可選)：base64 編碼的文件數組 [{content: "base64...", filename: "file.pdf"}]（最多 10 個文件，每個最大 40MB）

v1.3.0 新增： 通過 files_base64 參數支持 base64 文件上傳。

⚠️ 破壞性變更 (v2.8.0)： 參數 files（本地路徑）已被移除。請使用新工具 upload_ticket_files 通過 base64 上傳文件，或直接通過 files_base64 傳入文件。

示例：

{
  "ticket_number": "123",
  "text": "Hello, your issue has been resolved.",
  "with_signature": true,
  "files_base64": [{"content": "JVBERi0x...", "filename": "attachment.pdf"}]
}

`search_client`

按名稱搜索客戶（快捷方式 —— 僅按名稱）。完整過濾條件和分頁請使用 list_clients。

參數：

client_name (string, 必填)：要搜索的客戶名稱（支持部分匹配）

`list_clients`

列出客戶，支持過濾和分頁。search_client 的完整版本 —— 接受狀態、名稱和 CPF/CNPJ 過濾。

參數：

active (boolean, 可選)：按狀態過濾：true = 僅激活，false = 僅停用。省略表示全部。
name (string, 可選)：按名稱過濾（部分匹配）
social_revenue (string, 可選)：按 CPF/CNPJ 過濾
offset (number, 可選)：頁碼（默認 1）
limit (number, 可選)：每頁結果數（默認 20，最大 200）

示例：

{
  "active": true,
  "name": "Acme",
  "limit": 10
}

`get_client`

按 ID 獲取客戶的完整詳情。

參數：

client_id (number, 必填)：客戶 ID（可通過 search_client 或 list_clients 獲取）
show_entities (boolean, 可選)：在響應中包含自定義字段（實體）（默認 false）

示例：

{
  "client_id": 42,
  "show_entities": true
}

`create_client`

在 TiFlux 中創建新客戶。只有 name 和 social 為必填；其他所有字段均為可選，僅在提供時發送。

參數：

name (string, 必填)：客戶商號（nome fantasia）
social (string, 必填)：客戶法定名稱（razão social）
social_revenue (string, 可選)：CPF 或 CNPJ
desk_ids (number 數組, 可選)：要關聯的服務檯 ID
add_all_desks (boolean, 可選)：關聯所有服務檯
technical_group_ids (number 數組, 可選)：要關聯的技術組 ID
status (boolean, 可選)：激活 (true) 或停用 (false) —— 默認 true
max_agents (number, 可選)：允許的最大服務人員數
email_financial (string, 可選)：財務聯繫郵箱
anotations (string, 可選)：內部備註
billing_report_type (string, 可選)：detailed_with_appointment、detailed、synthetic 或 ""（空）

示例：

{
  "name": "Acme Corp",
  "social": "Acme Corporação Ltda",
  "social_revenue": "12.345.678/0001-99",
  "desk_ids": [1, 2]
}

`update_client`

更新已有客戶（部分更新 —— 僅發送提供的字段）。

參數：

client_id (number, 必填)：要更新的客戶 ID
create_client 的所有字段（均為可選）

示例：

{
  "client_id": 42,
  "status": false,
  "email_financial": "novo@empresa.com"
}

`update_client_entities`

更新客戶的自定義字段（實體）。單次請求最多支持 50 個字段。對於具有多個選項的 checkbox 字段，每個選項發送一個條目並帶上 entity_field_id + entity_field_option_id + value: "true"/"false"。

參數：

client_id (number, 必填)：要更新的客戶 ID
entities (array, 必填)：自定義字段列表。每個條目：
- entity_field_id (number, 必填)：自定義字段 ID
- value (string, 必填)：字段值（或 null 表示清空）
- entity_field_option_id (number, 可選)：checkbox/single_select 的選項 ID
- country_code (string, 可選)：電話字段的國家代碼

示例：

{
  "client_id": 42,
  "entities": [
    { "entity_field_id": 72, "value": "TI" },
    { "entity_field_id": 80, "entity_field_option_id": 12, "value": "true" }
  ]
}

`get_client_desks`

列出與客戶關聯的服務檯。

參數：

client_id (number, 必填)：客戶 ID
offset (number, 可選)：頁碼（默認 1）
limit (number, 可選)：每頁結果數（默認 20，最大 200）

`get_client_technical_groups`

列出與客戶關聯的技術組。

參數：

client_id (number, 必填)：客戶 ID
offset (number, 可選)：頁碼（默認 1）
limit (number, 可選)：每頁結果數（默認 20，最大 200）

`create_client_user`

為客戶創建門戶用戶。允許該用戶訪問客戶門戶。

參數：

client_id (number, 必填)：要關聯該用戶的客戶 ID
name (string, 必填)：用戶全名
email (string, 必填)：用戶郵箱 —— 用於門戶登錄
extension (string, 可選)：電話分機
authorization_flow (boolean, 可選)：門戶訪問是否要求授權
telephone (string, 可選)：電話號碼
country_code (string, 可選)：電話號碼的國家代碼

示例：

{
  "client_id": 42,
  "name": "João Silva",
  "email": "joao@empresa.com",
  "telephone": "11999999999"
}

`add_client_email_permission`

添加授權域名或郵箱，以便代表客戶開單。

參數：

client_id (number, 必填)：客戶 ID
address (string, 必填)：域名（例如 @empresa.com.br）或特定郵箱，授權其為該客戶開單

示例：

{
  "client_id": 42,
  "address": "@empresa.com.br"
}

`search_user`

按名稱搜索用戶，以便用作工單負責人。

參數：

name (string, 必填)：要搜索的用戶名稱（支持部分匹配，會在名稱和郵箱中搜索）
type (string, 可選)：用戶類型過濾（client、attendant、admin）
active (boolean, 可選)：過濾激活 (true) 或停用 (false) 用戶
limit (number, 可選)：每頁結果數（默認 20，最大 200）
offset (number, 可選)：頁碼（默認 1）

非管理員支持（經由服務人員組回退）： 如果 API Key 屬於非管理員用戶，GET /users 會返回 403。在這種情況下，工具會自動回退到枚舉服務人員組（GET /technical-groups）及其成員（GET /technical-groups/{id}/users），然後按名稱進行模糊匹配。結果與管理員路徑相同 —— 無需更改參數。使用回退時會在輸出中添加一條說明。

實現說明： 對於管理員用戶，TiFlux API 的 /users 端點不支持基於名稱的過濾 —— 該工具最多獲取 200 個用戶並在客戶端進行過濾。對於非管理員用戶，該工具使用技術組鏈路，並對出現在多個組中的用戶去重。

示例：

{
  "name": "John",
  "type": "attendant",
  "active": true
}

`search_stage`

搜索特定服務檯的階段，用於工單更新。

參數：

desk_id (number, 可選)：要搜索階段的服務檯 ID
desk_name (string, 可選)：服務檯名稱，用於自動搜索（desk_id 的替代方案）。支持部分名稱 —— 例如 "cansados" 可解析為 "Dev - Cansados"（詳見智能名稱解析）
limit (number, 可選)：每頁結果數（默認 20，最大 200）
offset (number, 可選)：頁碼（默認 1）

注意： 必須至少提供 desk_id 或 desk_name 之一。

示例：

{
  "desk_name": "Suporte",
  "limit": 20
}

`search_catalog_item`

在特定服務檯內，按自由文本詞或名稱 / 過濾條件搜索服務目錄條目。使用 search 按關鍵字探索條目（服務端，匹配目錄名、區域名或條目名）。使用 catalog_item_name 按名稱定位特定條目（客戶端，恰好 1 個匹配時摺疊為詳情視圖）。

參數：

desk_id (number, 可選)：要搜索目錄條目的服務檯 ID
desk_name (string, 可選)：服務檯名稱，用於自動搜索（desk_id 的替代方案）。支持部分名稱 —— 例如 "cansados" 可解析為 "Dev - Cansados"（詳見智能名稱解析）
search (string, 可選)：用於服務端搜索的自由文本詞，覆蓋目錄名、區域名和條目名。部分匹配，大小寫不敏感，重音不敏感。返回帶完整層級（目錄 → 區域 → 條目）的列表。可與 area_id/catalog_id 組合以縮小範圍。
catalog_item_name (string, 可選)：要搜索的目錄條目名稱（客戶端對條目名進行部分匹配）。1 個匹配 → 詳情視圖；多個 → 返回錯誤並帶列表。若需更廣泛的探索，請使用 search。
area_id (number, 可選)：要過濾結果的服務區域 ID
catalog_id (number, 可選)：要過濾結果的服務目錄 ID
limit (number, 可選)：每頁結果數（默認 20，最大 200）
offset (number, 可選)：頁碼（默認 1）

注意： 必須至少提供 desk_id 或 desk_name 之一，並且至少提供 search、catalog_item_name、area_id 或 catalog_id 之一。

示例 —— 自由文本搜索（推薦用於探索）：

{
  "desk_name": "Support",
  "search": "infra",
  "limit": 10
}

示例 —— 按名稱定位特定條目：

{
  "desk_name": "Support",
  "catalog_item_name": "Installation",
  "limit": 10
}

💬 內部溝通

`create_internal_communication`

在工單中創建新的內部溝通。

參數：

ticket_number (string, 必填)：要創建溝通的工單編號
text (string, 必填)：溝通內容。支持 Markdown（粗體、列表、標題、代碼）—— MCP 會在發送到 API 前自動轉換為 HTML。
files_base64 (array, 可選)：base64 編碼的文件數組 [{content: "base64...", filename: "file.pdf"}]（最多 10 個文件，每個最大 25MB）

v1.3.0 新增： 通過 files_base64 參數支持 base64 文件上傳。

⚠️ 破壞性變更 (v2.8.0)： 參數 files（本地路徑）已被移除。請使用新工具 upload_ticket_files 通過 base64 上傳文件，或直接通過 files_base64 傳入文件。

示例：

{
  "ticket_number": "123",
  "text": "Internal communication content",
  "files_base64": [{"content": "base64...", "filename": "relatorio.pdf"}]
}

`list_internal_communications`

列出工單的內部溝通。

參數：

ticket_number (string, 必填)：要列出溝通的工單編號
offset (number, 可選)：頁碼（默認 1）
limit (number, 可選)：每頁溝通數（默認 20，最大 200）

`get_ticket_files`

獲取附加到指定工單的所有文件。

參數：

ticket_number (string, 必填)：要獲取文件所在的工單編號

返回： 文件列表，包含以下詳細信息：

文件 ID、名稱、內容類型
文件大小（格式化為 KB/MB/GB）
下載 URL
創建日期和創建人信息

示例：

{
  "ticket_number": "123"
}

`upload_ticket_files`

將文件上傳到 TiFlux 中的已有工單。文件必須以 base64 編碼內容提供。

參數：

ticket_number (string, 必填)：要附加文件的工單編號（例如 "123"、"456"）
files_base64 (array, 必填)：base64 編碼的文件數組 [{content: "base64...", filename: "file.pdf"}]（最多 10 個文件，每個最大 25MB）

示例：

{
  "ticket_number": "123",
  "files_base64": [
    {"content": "base64encodedcontent...", "filename": "relatorio.md"},
    {"content": "base64encodedcontent...", "filename": "screenshot.png"}
  ]
}

返回： 包含已上傳文件列表的確認信息。

注意： 上傳的文本文件（.md、.txt、.csv、.json）會以適當的 charset=utf-8 內容類型發送，可避免 TiFlux 門戶中出現字符編碼問題（亂碼）。

`delete_ticket_file`

移除 TiFlux 中附加到工單的文件。

參數：

ticket_number (string, 必填)：要移除文件的工單編號（例如 "123"、"456"）
file_id (string, 必填)：要移除的文件 ID（可通過 get_ticket_files 獲取）

示例：

{
  "ticket_number": "123",
  "file_id": "456"
}

返回： 文件已移除的確認信息。

`get_ticket_stages_slas`

列出工單在服務檯各階段流轉的完整歷史，並顯示每個階段的 SLA 結果。適用於 SLA 審計、升級審查和瓶頸分析。

參數：

ticket_number (string, 必填)：工單編號（例如 "123"、"456"）
offset (number, 可選)：頁碼（默認 1）
limit (number, 可選)：每頁記錄數（默認 20，最大 200）

返回： 每次階段流轉的格式化輸出包含：

階段名稱和服務檯
在工作時間內的耗時（HH:MM）
SLA 是否達標（✅ Sim / ❌ Não）
SLA 到期時間戳
工單何時進入該階段以及由誰移動
工單何時（如發生）在該階段被響應以及由誰響應

空結果： 處於 未啟用 SLA 服務檯的工單會返回空列表並附帶解釋性消息 —— 這是預期行為，不是錯誤。

示例：

{
  "ticket_number": "32",
  "offset": 1,
  "limit": 20
}

`list_ticket_answers`

列出指定工單的答覆（與客戶的溝通），分頁。

參數：

ticket_number (integer, 必填)：要列出答覆的工單編號
offset (number, 可選)：頁碼（默認 1）
limit (number, 可選)：每頁答覆數（默認 20，最大 200）

返回： 每條答覆包括：

作者姓名、日期 / 時間、來源（agent、client 等）
文件數量指示
內容預覽（前 200 個字符）
分頁信息以及下一頁提示

示例：

{
  "ticket_number": 123,
  "offset": 1,
  "limit": 20
}

`get_ticket_answer`

獲取工單中指定答覆的完整詳情，包括附加文件。

參數：

ticket_number (integer, 必填)：工單編號
answer_id (integer, 必填)：要獲取的答覆 ID

返回：

完整答覆內容（未截斷）、作者、日期、來源
附加文件的完整列表，含名稱、類型、大小和下載 URL

示例：

{
  "ticket_number": 123,
  "answer_id": 501
}

`delete_ticket_answer`

從 TiFlux 工單中移除答覆（客戶溝通）。

參數：

ticket_number (string, 必填)：要移除答覆的工單編號（例如 "123"、"456"）
answer_id (string, 必填)：要移除的答覆 ID（可通過 list_ticket_answers 或 get_ticket_answer 獲取）

示例：

{
  "ticket_number": "123",
  "answer_id": "501"
}

返回： 答覆已移除的確認信息。

`delete_ticket_answer_file`

移除附加到指定工單答覆的文件。

參數：

answer_id (string, 必填)：要移除文件的答覆 ID（可通過 list_ticket_answers 或 get_ticket_answer 獲取）
file_id (string, 必填)：要移除的文件 ID（可通過 get_ticket_answer 獲取，字段為 files[].id）

示例：

{
  "answer_id": "501",
  "file_id": "1"
}

返回： 文件已移除的確認信息。

`get_ticket_histories`

列出工單的事件歷史（時間線），顯示字段變更、階段流轉及其他事件。分頁。

參數：

ticket_number (integer, 必填)：要獲取歷史的工單編號
offset (number, 可選)：頁碼（默認 1）
limit (number, 可選)：每頁事件數（默認 20，最大 200）
history_of (integer, 可選)：按工單區域過濾（例如 1 = 預約）
type_id_attr (integer, 可選)：按屬性類型過濾
operation (integer, 可選)：按操作類型過濾 —— 僅在 history_of=1 時有效

返回： 每個事件：

動作描述、用戶、日期 / 時間、事件類型和操作
變更字段的差異，含舊值 → 新值

示例：

{
  "ticket_number": 123,
  "history_of": 1
}

`reopen_ticket`

重新打開已關閉或已取消的工單。已開票的工單無法重新打開。

參數：

ticket_number (integer, 必填)：要重新打開的工單編號
disapproval_reason (string, 可選)：重新打開待審核工單時必填（基於駁回的重新打開）

業務規則：

已開票的工單無法重新打開（API 返回 422）
重新打開處於待審核 / 審批狀態的工單時，disapproval_reason 為必填

示例：

{
  "ticket_number": 123,
  "disapproval_reason": "The solution did not resolve the issue"
}

`get_internal_communication`

獲取指定內部溝通的完整內容。

參數：

ticket_number (string, 必填)：包含該溝通的工單編號
communication_id (string, 必填)：要獲取的內部溝通 ID

`update_internal_communication`

更新工單中已有內部溝通的文本。只有該溝通的作者可以編輯。

參數：

ticket_number (string, 必填)：包含該溝通的工單編號（例如 "123"、"456"）
communication_id (string, 必填)：要更新的內部溝通 ID（可通過 list_internal_communications 或 get_internal_communication 獲取）
text (string, 必填)：內部溝通的新內容。支持 Markdown（粗體、列表、標題、代碼）—— MCP 會在發送到 API 前自動轉換為 HTML。

示例：

{
  "ticket_number": "123",
  "communication_id": "101",
  "text": "Updated communication content with **important** details."
}

返回： 包含更新後溝通內容的確認信息。

注意： TiFlux API 僅允許該溝通的作者進行編輯。如果已鑑權用戶不是該溝通的創建者，將返回 403 錯誤。

`delete_internal_communication`

從 TiFlux 工單中移除內部溝通。

參數：

ticket_number (string, 必填)：要移除溝通的工單編號（例如 "123"、"456"）
communication_id (string, 必填)：要移除的內部溝通 ID（可通過 list_internal_communications 獲取）

示例：

{
  "ticket_number": "123",
  "communication_id": "101"
}

返回： 內部溝通已移除的確認信息。

⏱️ 預約（時間跟蹤）

⚠️ 免責聲明： 創建預約（create_appointment）僅支持配置了非計價預約的服務檯工單。列出預約（list_appointments）適用於任何服務檯，並在可用時渲染計價詳情。

`create_appointment`

在指定工單上創建新預約（工時記錄）。僅在配置了非計價預約的服務檯工單上有效。

參數：

ticket_number (string, 必填)：要創建預約的工單編號
date (string, 必填)：預約日期，格式 YYYY-MM-DD。不允許未來日期。
init_time (string, 必填)：開始時間，格式 HH:MM（例如 "09:00"、"14:30"）
end_time (string, 必填)：結束時間，格式 HH:MM。必須大於或等於 init_time。
description (string, 必填)：所執行工作的描述

示例：

{
  "ticket_number": "123",
  "date": "2025-01-15",
  "init_time": "09:00",
  "end_time": "10:30",
  "description": "Investigation and fix of the reported issue"
}

`list_appointments`

列出指定工單的預約（工時記錄），支持可選過濾。當可用時，每張預約卡片會包含計價詳情（服務類型、合同或散單服務、差旅班次、金額）以及地理定位條目。

參數：

ticket_number (string, 必填)：要列出預約的工單編號
user_id (number, 可選)：按做該預約的用戶 ID 過濾
start_date (string, 可選)：返回該日期開始的預約（YYYY-MM-DD）
end_date (string, 可選)：返回截至該日期的預約（YYYY-MM-DD）
offset (number, 可選)：頁碼（默認 1）
limit (number, 可選)：每頁預約數（默認 20，最大 200）

返回： 每張預約卡片顯示日期、時間段、服務人員、客戶（如可用）以及描述。當服務檯啟用了計價時，卡片還會包含：

服務類型：External (Externo)、Remote (Remoto) 或 Internal (Interno)
服務性質：Loose (Avulso) 附帶散單服務名稱，或 Contract 附帶合同名稱
差旅班次名稱及金額（適用時）
保修和手動金額標誌（僅在為 true 時顯示）
格式為 R$ X,XX 的金額

當 valorization 為 null（服務檯配置為不計價）時，上述字段均不顯示。

當 API 為預約返回 locations 時，會渲染出地理定位行（📍 Localização: lat, lon）。

示例：

{
  "ticket_number": "123",
  "start_date": "2025-01-01",
  "end_date": "2025-01-31",
  "limit": 50
}

🗨️ 聊天

`get_chat`

按 ID 顯示指定聊天的詳情。返回包含狀態、客戶、負責人、部門、來源、評價和日期的卡片。

參數：

id (number, 必填)：聊天的數字 ID（也接受數字字符串 —— handler 會調用 parseInt）

返回： 包含所有相關聊天字段的卡片，包括：

狀態（archived、canceled、online、waiting for answer）
客戶和請求人名稱
部門與負責服務人員
來源渠道和房間
關聯的工單編號
評價評分（1–5，如可用）
最後一條客戶消息（截斷至 150 字符）
時間戳（created、updated、assumed）

示例：

{
  "id": 42
}

`list_inbox_chats`

列出收件箱中的聊天（未接管的聊天），支持可選的部門、客戶、來源過濾和分頁。

參數：

offset (number, 可選)：頁碼（默認 1，最小值 1）
limit (number, 可選)：每頁聊天數（默認 20，最大 200）
department_id (number, 可選)：按部門 ID 過濾
client_id (number, 可選)：按客戶 ID 過濾
requestor_id (number, 可選)：按請求人 ID 過濾 —— 必須大於 0
number (number, 可選)：按 WhatsApp 聯繫人號碼過濾 —— 需要 WhatsApp 許可
origins (string, 可選)：逗號分隔的來源渠道：chat、site_widget、campaign、whatsapp、whatsapp_web、gupshup、whatsapp_cloud
started_by (string, 可選)：聊天發起方類型：Client、Attendant、Campaign、API

示例：

{
  "origins": "whatsapp",
  "limit": 10,
  "offset": 1
}

`list_my_chats`

列出由已鑑權用戶（API Key 的持有者）接管的聊天，支持可選過濾和分頁。

參數：

offset (number, 可選)：頁碼（默認 1，最小值 1）
limit (number, 可選)：每頁聊天數（默認 20，最大 200）
department_id (number, 可選)：按部門 ID 過濾
client_id (number, 可選)：按客戶 ID 過濾
requestor_id (number, 可選)：按請求人 ID 過濾 —— 必須大於 0
number (number, 可選)：按 WhatsApp 聯繫人號碼過濾 —— 需要 WhatsApp 許可
origins (string, 可選)：逗號分隔的來源渠道（參見 list_inbox_chats）
started_by (string, 可選)：聊天發起方類型（參見 list_inbox_chats）

示例：

{
  "department_id": 3,
  "limit": 20
}

`list_in_attendance_chats`

列出組織中所有服務中的聊天，支持可選的負責人、狀態過濾和分頁。

參數：

offset (number, 可選)：頁碼（默認 1，最小值 1）
limit (number, 可選)：每頁聊天數（默認 20，最大 200）
department_id (number, 可選)：按部門 ID 過濾
client_id (number, 可選)：按客戶 ID 過濾
requestor_id (number, 可選)：按請求人 ID 過濾 —— 必須大於 0
number (number, 可選)：按 WhatsApp 聯繫人號碼過濾 —— 需要 WhatsApp 許可
origins (string, 可選)：逗號分隔的來源渠道（參見 list_inbox_chats）
started_by (string, 可選)：聊天發起方類型（參見 list_inbox_chats）
user_id (number, 可選)：按負責服務人員 ID 過濾
status (string, 可選)：按服務狀態過濾：waiting_client、waiting_attendance、triage

示例：

{
  "user_id": 7,
  "status": "triage"
}

`list_archived_chats`

列出已歸檔聊天（已完成或已取消），支持可選過濾。顯示服務評價和取消狀態。

參數：

offset (number, 可選)：頁碼（默認 1，最小值 1）
limit (number, 可選)：每頁聊天數（默認 20，最大 200）
department_id (number, 可選)：按部門 ID 過濾
client_id (number, 可選)：按客戶 ID 過濾
requestor_id (number, 可選)：按請求人 ID 過濾 —— 必須大於 0
number (number, 可選)：按 WhatsApp 聯繫人號碼過濾 —— 需要 WhatsApp 許可
origins (string, 可選)：逗號分隔的來源渠道（參見 list_inbox_chats）
started_by (string, 可選)：聊天發起方類型（參見 list_inbox_chats）
canceled (boolean, 可選)：true = 僅已取消聊天，false = 僅正常完成，省略 = 所有已歸檔聊天

示例：

{
  "canceled": false,
  "limit": 50
}

`update_chat`

更新已有聊天：轉接服務人員（user_id）、轉接部門（department_id）和 / 或將聊天關聯到工單（ticket_number）。僅能更新非已取消或已結束的聊天。

參數：

id (number, 必填)：聊天 ID（接受數字字符串 —— handler 會運行 parseInt）
user_id (number, 可選)：聊天將轉接至的服務人員
user_name (string, 可選)：服務人員姓名，用於自動查詢（user_id 的替代方案；user_id 優先）。注意事項 (BL-007)： 需要管理員 API Key —— GET /users 對非管理員賬戶返回 403；此時請直接使用 user_id。
department_id (number, 可選)：聊天將轉接至的部門。沒有 department_name —— v2 API 沒有部門搜索端點。
ticket_number (number, 可選)：要關聯到該聊天的工單編號

注意： 至少要提供 user_id / user_name / department_id / ticket_number 之一。若均未提供，工具將返回友好警告而不調用 API。

示例：

{
  "id": 37,
  "user_id": 1,
  "ticket_number": 127
}

返回： 包含所應用變更列表的 Markdown 確認信息。

`send_message`

通過 WhatsApp 發送消息，發送時會創建聊天。使用自由文本（message）或 HSM / 聊天模板（template_id），兩者不可同時使用。

message 為純文本（非 Markdown/HTML）。 WhatsApp 使用其自有的標記語法（星號表示粗體，下劃線表示斜體）；HTML 會以字面形式顯示。因此，與工單的 description/answer 不同，其內容不會被轉換為 HTML。

參數：

number (number, 必填)：目標電話號碼。默認按巴西號碼校驗；其他國家需同時傳入 country_code。
integration_id (number, 必填)：WhatsApp 集成 ID。接受類型：gupshup、whatsapp_cloud。
message (string, 可選)：自由文本消息（純文本）。使用 message 或 template_id 二選一。
template_id (number, 可選)：HSM / 聊天模板 ID。使用 parameters/header_parameters 傳入變量。
country_code (string, 可選)：ISO 3166-1 alpha-2 國家代碼（例如 US）。默認 BR。
name (string, 可選)：請求人姓名。
department_id (number, 可選)：將創建的聊天關聯到指定部門。
ticket_number (number, 可選)：將創建的聊天關聯到指定工單。
client_id (number, 可選)：將創建的聊天關聯到指定客戶。
parameters (string[], 可選)：HSM 正文變量的值（template_id）。
header_parameters (string[], 可選)：HSM 頭部變量的值 —— 僅 whatsapp_cloud 支持。
archive (boolean, 可選)：默認 false。true = 創建並直接發送到已完成 / 已歸檔箱。

注意： 除 number + integration_id 外，還需至少提供 message / template_id 之一（本地校驗）。API 的成功狀態為 201。

示例（自由消息）：

{
  "number": 5568976728276,
  "integration_id": 1,
  "message": "Olá, tudo bem?"
}

示例（帶參數的 HSM 模板）：

{
  "number": 5519993017428,
  "integration_id": 1,
  "template_id": 1,
  "parameters": ["Valor 1", "Valor 2"]
}

返回： 包含發送詳情的 Markdown 確認信息（類型、號碼、集成、關聯信息）。

`archive_chat`

結束（關閉）聊天。API 返回 202 (Accepted) —— 結束可能異步處理；該工具將 202 視為成功。

參數：

id (number, 必填)：要結束的聊天 ID（接受數字字符串 —— handler 會運行 parseInt）
services_catalogs_item_id (number, 可選)：服務目錄條目 ID。條件性： 僅當組織配置為"在聊天中使用服務目錄"時必填 —— 否則 API 返回 422。沒有 catalog_item_name：目錄條目搜索需要 desk_id，而聊天不提供該字段；需要時請直接傳入 ID。

示例：

{
  "id": 37,
  "services_catalogs_item_id": 1
}

返回： 標記聊天已結束的 Markdown 確認信息（202 Accepted）。

🖥️ 服務檯工具

無需離開聊天即可探索和檢查服務檯（服務隊列）。使用 list_desks 發現可用服務檯，使用 get_desk 檢查完整配置，使用 list_desk_priorities 在創建工單前發現優先級 ID，使用 list_desk_services_catalogs 列出與服務檯關聯的服務目錄容器。

`list_desks`

列出租戶中可用的服務檯 (desks)，用於發現和探索。返回包含 id、名稱、顯示名稱、激活狀態和服務類型的表。在創建工單前使用，或用於探索存在哪些服務檯。

參數：

active (boolean, 可選)：過濾激活 (true) 或停用 (false) 服務檯。默認：true（僅激活）
name (string, 可選)：按名稱或 display_name 進行服務端過濾（大小寫不敏感精確匹配）
limit (number, 可選)：每頁結果數（默認 20，最大 200）
offset (number, 可選)：頁碼（默認 1）

返回： 包含 id、name、display_name、激活狀態和 appointment_type 的 Markdown 表格。

示例：

{
  "active": true,
  "limit": 50
}

`get_desk`

返回一個服務檯的完整配置（30+ 個字段），按以下分區組織：識別信息、服務、SLA、工單行為、表單必填字段。空值或 falsy 字段會自動省略。

接受 desk_id（直接）或 desk_name（模糊，使用與智能名稱解析相同的機制）。若兩者都提供，desk_id 優先。

參數：

desk_id (number, 可選)：數字服務檯 ID。若提供，將直接使用，不做名稱解析
desk_name (string, 可選)：部分或完整服務檯名稱 —— 例如 "cansados" 可解析為 "Dev - Cansados"（詳見智能名稱解析）。desk_id 的替代方案

注意： 必須至少提供 desk_id 或 desk_name 之一。

返回： 包含以下分區的 Markdown：

Identificação：名稱、顯示名稱、描述、激活狀態、內部服務檯標誌、是否接收新工單
Atendimento：預約類型、服務類型、權限、可取消工單、反饋、郵件設置、服務檯交換
SLA：SLA 激活標誌、SLA 目標、可否暫停 SLA、SLA 時間跟蹤
工單行為：工單審核設置、重開規則、時間限制、計費行為
表單必填字段：必填字段、服務目錄要求

示例：

{
  "desk_id": 3
}

或使用模糊名稱解析：

{
  "desk_name": "cansados"
}

`list_desk_priorities`

列出 TiFlux 中某個服務檯已配置的優先級。用於在創建或更新工單前發現優先級 ID（例如："alta prioridade" → priority_id）。priority_name 過濾在獲取 API 記錄後於客戶端進行模糊匹配。

接受 desk_id（直接）或 desk_name（模糊）。若兩者都提供，desk_id 優先。

參數：

參數	類型	必填	默認值	說明
`desk_id`	number	二選一	—	數字服務檯 ID。直接使用，不做名稱查詢
`desk_name`	string	二選一	—	部分或精確的服務檯名稱（模糊解析）。`desk_id` 的替代方案
`priority_name`	string	否	—	可選的優先級名稱模糊過濾（客戶端）。例如 `"alta"`
`limit`	number	否	20	每頁結果數（最大 200）
`offset`	number	否	1	頁碼

返回： 包含 id、name、order、start_time、end_time 的 Markdown 表格。

示例 —— 按 desk_id 列出所有優先級：

{
  "desk_id": 3
}

示例 —— 使用 desk_name 按優先級名稱過濾：

{
  "desk_name": "suporte",
  "priority_name": "alta"
}

示例響應：

| ID | Nome | Ordem | Inicio | Fim |
|---|---|---|---|---|
| 17 | High | 1 | 04:00 | 24:00 |
| 18 | Low | 2 | 10:00 | 48:00 |

`list_desk_services_catalogs`

列出與 TiFlux 服務檯關聯的服務目錄。目錄是父容器 —— 不同於目錄條目（條目請使用 search_catalog_item）。catalog_name 過濾在客戶端進行模糊匹配。

接受 desk_id（直接）或 desk_name（模糊）。若兩者都提供，desk_id 優先。

參數：

參數	類型	必填	默認值	說明
`desk_id`	number	二選一	—	數字服務檯 ID。直接使用，不做名稱查詢
`desk_name`	string	二選一	—	部分或精確的服務檯名稱（模糊解析）。`desk_id` 的替代方案
`catalog_name`	string	否	—	可選的目錄名稱模糊過濾（客戶端）。例如 `"infra"`
`limit`	number	否	20	每頁結果數（最大 200）
`offset`	number	否	1	頁碼

返回： 包含 id、name 的 Markdown 表格。

示例 —— 列出所有目錄：

{
  "desk_name": "suporte"
}

示例 —— 按目錄名稱過濾：

{
  "desk_id": 3,
  "catalog_name": "infra"
}

示例響應：

| ID | Nome |
|---|---|
| 6 | Catalogo 1 |
| 7 | Catalogo 2 |

`list_entities`

列出 TiFlux 組織中可用的自定義字段組（實體）。用於發現存在哪些自定義字段組、它們適用於哪些應用（ticket、client 等）以及它們的 ID —— 這是 list_entity_fields 所必需的。

參數：

參數	類型	必填	默認值	說明
`active`	boolean	否	—	過濾激活 (`true`) 或停用 (`false`) 實體
`applied_in`	string	否	—	按應用過濾：`"ticket"`、`"client"`、`"solicitant"`、`"services_catalog"`、`"services_catalogs_area"`、`"services_catalogs_item"`、`"equipment"`
`name`	string	否	—	按實體名稱過濾（部分匹配）
`limit`	number	否	20	每頁結果數（最大 200）
`offset`	number	否	1	頁碼

返回： 包含 id、name、applied_in、active 的 Markdown 表格。

示例：

{
  "applied_in": "ticket"
}

示例響應：

| ID | Nome | Applied In | Ativa |
|---|---|---|---|
| 10 | Classificação do Chamado | ticket | Sim |
| 11 | Dados do Atendimento | ticket | Sim |

`list_entity_fields`

列出 TiFlux 中某個自定義字段組的子字段 (entity_fields)。返回名稱、類型、是否必填，並指示哪些字段有可選選項（single_select/checkbox）—— 這些情況請使用 list_entity_field_options。

參數：

參數	類型	必填	默認值	說明
`entity_id`	number	是	—	自定義字段組（實體）ID。通過 `list_entities` 獲取
`field_type`	string	否	—	按類型過濾：`"text"`、`"text_area"`、`"currency"`、`"phone"`、`"email"`、`"link"`、`"date"`、`"single_select"`、`"checkbox"`
`required`	boolean	否	—	過濾必填 (`true`) 或可選 (`false`) 字段
`name`	string	否	—	按字段名稱過濾
`limit`	number	否	20	每頁結果數（最大 200）
`offset`	number	否	1	頁碼

返回： 包含 id、name、field_type、required 的 Markdown 表格，以及對 single_select/checkbox 字段的 options 提示。

示例：

{
  "entity_id": 10,
  "field_type": "checkbox"
}

示例響應：

| ID | Nome | Tipo | O

Baidu Map

已認證

百度地圖MCP Server是國內首個兼容MCP協議的地圖服務，提供地理編碼、路線規劃等10個標準化API接口，支持Python和Typescript快速接入，賦能智能體實現地圖相關功能。

Markdownify是一個多功能文件轉換服務，支持將PDF、圖片、音頻等多種格式及網頁內容轉換為Markdown格式。

Firecrawl MCP Server是一個集成Firecrawl網頁抓取能力的模型上下文協議服務器，提供豐富的網頁抓取、搜索和內容提取功能。

TypeScript

170.6K

5分

Sequential Thinking MCP Server

一個基於MCP協議的結構化思維服務器，通過定義思考階段幫助分解複雜問題並生成總結

Python

43.1K

4.5分

Edgeone Pages MCP Server

EdgeOne Pages MCP是一個通過MCP協議快速部署HTML內容到EdgeOne Pages並獲取公開URL的服務

一個基於Python的MCP服務器，通過Notion API提供高級待辦事項管理和內容組織功能，實現AI模型與Notion的無縫集成。

Magic Component Platform (MCP) 是一個AI驅動的UI組件生成工具，通過自然語言描述幫助開發者快速創建現代化UI組件，支持多種IDE集成。

Context7 MCP是一個為AI編程助手提供即時、版本特定文檔和代碼示例的服務，通過Model Context Protocol直接集成到提示中，解決LLM使用過時信息的問題。

智啟未來，您的人工智慧解決方案智庫

Tiflux MCP

安裝

內容詳情

安裝

🚀 TiFlux MCP 服務器

✨ 主要特性

🚀 快速開始

📦 安裝

💻 使用方式

與 Claude Code 配合使用

與其他 MCP 客戶端配合使用

通過 URL（HTTP 傳輸）

手動配置

端點說明

通過 Web（OAuth 2.0）—— Claude web 與 ChatGPT 連接器

⚙️ 配置

🧰 可用工具

get_ticket

create_ticket

update_ticket

update_ticket_entities

cancel_ticket

list_tickets

close_ticket

create_ticket_answer

search_client

list_clients

get_client

create_client

update_client

update_client_entities

get_client_desks

get_client_technical_groups

create_client_user

add_client_email_permission

search_user

search_stage

search_catalog_item

💬 內部溝通

create_internal_communication

list_internal_communications

get_ticket_files

upload_ticket_files

delete_ticket_file

get_ticket_stages_slas

list_ticket_answers

get_ticket_answer

delete_ticket_answer

delete_ticket_answer_file

get_ticket_histories

reopen_ticket

get_internal_communication

update_internal_communication

delete_internal_communication

⏱️ 預約（時間跟蹤）

create_appointment

list_appointments

🗨️ 聊天

get_chat

list_inbox_chats

list_my_chats

list_in_attendance_chats

list_archived_chats

update_chat

send_message

archive_chat

🖥️ 服務檯工具

list_desks

get_desk

list_desk_priorities

list_desk_services_catalogs

list_entities

list_entity_fields

替代品

`get_ticket`

`create_ticket`

`update_ticket`

`update_ticket_entities`

`cancel_ticket`

`list_tickets`

`close_ticket`

`create_ticket_answer`

`search_client`

`list_clients`

`get_client`

`create_client`

`update_client`

`update_client_entities`

`get_client_desks`

`get_client_technical_groups`

`create_client_user`

`add_client_email_permission`

`search_user`

`search_stage`

`search_catalog_item`

`create_internal_communication`

`list_internal_communications`

`get_ticket_files`

`upload_ticket_files`

`delete_ticket_file`

`get_ticket_stages_slas`

`list_ticket_answers`

`get_ticket_answer`

`delete_ticket_answer`

`delete_ticket_answer_file`

`get_ticket_histories`

`reopen_ticket`

`get_internal_communication`

`update_internal_communication`

`delete_internal_communication`

`create_appointment`

`list_appointments`

`get_chat`

`list_inbox_chats`

`list_my_chats`

`list_in_attendance_chats`

`list_archived_chats`

`update_chat`

`send_message`

`archive_chat`

`list_desks`

`get_desk`

`list_desk_priorities`

`list_desk_services_catalogs`

`list_entities`

`list_entity_fields`