Skip to main content
Glama
tiflux

TiFlux MCP Server

Official
by tiflux

create_ticket

Create tickets in TiFlux with automatic requester matching. Specify title, description, desk, client, and priority to open a new support ticket.

Instructions

Criar um novo ticket no TiFlux.

Heuristica mesa-first: Quando o usuario referencia um nome sem qualificar a entidade, use desk_name. So use client_name se o usuario disser explicitamente "cliente" ou "empresa". Para pessoa que vai abrir o ticket, use requestor_name ou requestor_email.

Auto-resolve de solicitante: Se requestor_name for fornecido sem requestor_id e sem requestor_email, o MCP tenta encontrar o solicitante ja existente no tenant automaticamente (evita criar solicitante fantasma). Se encontrar mais de um match, retorna lista para escolha. Se nao encontrar, cria com o nome informado.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleYesTítulo do ticket
descriptionYesDescrição do ticket. Aceita Markdown (negrito, listas, cabeçalhos, código) — o MCP converte automaticamente para HTML antes de enviar à API.
client_idNoID do cliente/empresa (opcional - usa TIFLUX_DEFAULT_CLIENT_ID se não informado)
client_nameNoNome do cliente (empresa contratante) para busca automática (alternativa ao client_id). Use **apenas** quando o usuario disser explicitamente "cliente" ou "empresa". Para pessoa fisica, use requestor_name.
desk_idNoID da mesa (opcional - usa TIFLUX_DEFAULT_DESK_ID se não informado)
desk_nameNoNome da mesa/equipe para busca automática (alternativa ao desk_id). Aceita nomes parciais (ex: "cansados" resolve para "Dev - Cansados"). **Prefira este campo quando o usuario der um nome sem qualificar a entidade.**
priority_idNoID da prioridade (opcional - usa TIFLUX_DEFAULT_PRIORITY_ID se não informado)
services_catalogs_item_idNoID do item de catálogo (opcional - usa TIFLUX_DEFAULT_CATALOG_ITEM_ID se não informado)
catalog_item_nameNoNome do item de catálogo para busca automática (alternativa ao services_catalogs_item_id, requer desk_id ou desk_name)
status_idNoID do status (opcional)
requestor_idNoID do solicitante (pessoa fisica que abre o ticket). Use quando ja tem o ID do solicitante existente no tenant. O solicitante deve pertencer ao cliente selecionado.
requestor_nameNoNome do solicitante (pessoa fisica). O MCP tenta resolver automaticamente para requestor_id se o solicitante ja existir no tenant (evita criar solicitante fantasma). Se preferir nao resolver automaticamente, passe requestor_id diretamente.
requestor_emailNoEmail do solicitante. Use quando voce ja tem o email exato — o MCP nao tentara resolver para requestor_id (o email e identificador suficiente).
requestor_telephoneNoTelefone do solicitante (opcional)
responsible_idNoID do responsável (opcional)
responsible_nameNoNome do responsável para busca automática (alternativa ao responsible_id)
followersNoEmails dos seguidores separados por vírgula (opcional)
parent_ticket_numberNoNúmero do ticket pai. O ticket criado será vinculado como filho deste ticket.
Behavior4/5

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

Given no annotations, the description carries full burden. It discloses auto-resolve logic for requestors (attempt to find existing, create if not found), Markdown-to-HTML conversion for description, and partial matching for desk_name. However, it does not mention idempotency, error handling, or whether creation is always successful.

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?

Well-structured with clear sections and front-loaded main purpose. Some redundancy in auto-resolve explanation could be tightened, but overall efficient for the complexity.

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

Completeness4/5

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

For a tool with 18 parameters and no output schema, the description covers key behaviors: auto-resolve, heuristic for entity names, Markdown support. Missing details on what happens when auto-resolve fails or returns multiple matches, and no description of the return value/created ticket. Still fairly comprehensive.

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

Parameters5/5

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

Schema description coverage is 100%, but the description adds significant value beyond schema: explains heuristics for desk_name vs client_name, partial name matching, auto-resolve heuristics, and Markdown conversion. Each parameter's purpose and behavior are enriched with context.

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

Purpose5/5

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

The description clearly states 'Criar um novo ticket no TiFlux' (create a new ticket), specifying the verb and resource. It is distinct from sibling tools like update_ticket, cancel_ticket, and close_ticket.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit heuristics: use desk_name when user references a name without qualifying entity, use client_name only when user explicitly says 'cliente' or 'empresa'. Also explains auto-resolve behavior for requestor_name and when to use requestor_email. Clearly differentiates when to use each parameter.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/tiflux/tiflux-mcp'

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