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

Figma Context MCP

Framelink Figma MCP Server是一个为AI编程工具（如Cursor）提供Figma设计数据访问的服务器，通过简化Figma API响应，帮助AI更准确地实现设计到代码的一键转换。

TypeScript

101.7K

4.5分

Duckduckgo MCP Server

已认证

DuckDuckGo搜索MCP服务器，为Claude等LLM提供网页搜索和内容抓取服务

Firecrawl MCP Server是一个集成Firecrawl网页抓取能力的模型上下文协议服务器，提供丰富的网页抓取、搜索和内容提取功能。

MiniMax Model Context Protocol (MCP) 是一个官方服务器，支持与强大的文本转语音、视频/图像生成API交互，适用于多种客户端工具如Claude Desktop、Cursor等。

百度地图MCP Server是国内首个兼容MCP协议的地图服务，提供地理编码、路线规划等10个标准化API接口，支持Python和Typescript快速接入，赋能智能体实现地图相关功能。

Python

74.4K

4.5分

Edgeone Pages MCP Server

EdgeOne Pages MCP是一个通过MCP协议快速部署HTML内容到EdgeOne Pages并获取公开URL的服务

Exa MCP Server是一个为AI助手（如Claude）提供网络搜索功能的服务器，通过Exa AI搜索API实现实时、安全的网络信息获取。

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`