TiFlux MCP Server

Official

by tiflux

Overview Schema Related Servers Score Discussions

JavaScript

Hybrid

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.3.0
Disambiguation4/5
Most tools have distinct purposes, with clear prefixes and context. Some potential confusion exists between list_tickets and get_ticket, and between get_chat and list_*_chats, but the descriptions are detailed enough to differentiate.
Naming Consistency4/5
Predominantly follows verb_noun pattern (e.g., create_ticket, get_ticket, list_tickets). Minor deviations include 'search_catalog_item' instead of 'find_catalog_item' and 'get_ticket_stages_slas' with an irregular plural, but overall consistent.
Tool Count3/5
31 tools is on the higher end but justifiable for a comprehensive ticketing and chat system. Some tools are very specific (e.g., list_entity_field_options), which might add unnecessary complexity for basic use cases.
Completeness4/5
Covers most lifecycle operations for tickets and chats, including search and customization. Missing delete_ticket and direct client/user management tools, but the core workflows are well-supported.
Average 3.7/5 across 31 of 31 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 58 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are available, so the description must disclose behavioral traits. It only states the basic action without mentioning side effects, prerequisites, or result format. Critical information such as whether cancellation is irreversible or requires permissions is missing.
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?
The description is a single concise sentence with no unnecessary words. It is front-loaded and efficient.
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 the simplicity (1 parameter, no output schema), the description is incomplete. It lacks details on return values, error conditions, and behavioral expectations. Without annotations, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3 applies. The description does not add any additional meaning beyond the schema; the schema already describes the parameter adequately.
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 states the action (cancel) and resource (ticket) in Portuguese. It is specific and distinct from many siblings like 'create_ticket' or 'list_tickets', but does not differentiate from 'close_ticket', which could be a similar action.
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 cancel vs. close or other alternatives. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks behavioral details beyond the basic action. With no annotations provided, the description bears full responsibility for transparency, yet it does not mention side effects, auth requirements, rate limits, or what happens on success/error. The only behavioral hint comes from the schema 'text' parameter about Markdown conversion, but that is not in the description.
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?
The description is a single, clear sentence that conveys the core purpose without any wasted words. It is efficiently front-loaded, stating the action and target immediately.
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 4 parameters, 2 required, and no output schema, the description is too minimal. It does not explain what the tool returns, any constraints (e.g., file size limits from schema are not mentioned), or prerequisites (e.g., ticket must exist). The combination of missing output schema and sparse description leaves gaps in understanding the complete behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description itself does not add any parameter-specific information; it is a single sentence about the overall tool purpose. Since the schema already describes all parameters thoroughly, the description adds no extra value.
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 states the verb 'criar' (create) and resource 'comunicação interna em um ticket específico' (internal communication on a specific ticket). It is not a tautology and adds specificity by mentioning the ticket context. However, it does not distinguish itself from sibling tools like 'create_ticket_answer' or 'create_ticket', which have overlapping purposes.
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?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., ticket existence), expected context, or when not to use it. Sibling tools like 'get_internal_communication' and 'create_ticket_answer' imply different use cases, but the description offers no differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions optional filters and pagination but does not indicate that the operation is read-only, safe, or idempotent. There is no mention of authorization needs, rate limits, or response structure.
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, clear sentence with no unnecessary words or repetition. It front-loads the main purpose and includes key filter categories efficiently.
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?
Given the tool has 10 optional parameters and no output schema or annotations, the description is adequate but not complete. It does not explain the meaning of 'em atendimento' or typical usage patterns. However, the schema covers parameter details, so the description only needs to provide high-level context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds a high-level summary of filters (responsible, status, pagination) but does not provide additional meaning beyond the schema. The extra value is minimal.
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 states it lists all chats in attendance with optional filters, specifying the resource (chats em atendimento) and scope (da organização). However, it does not explicitly distinguish from sibling tools like list_archived_chats or list_inbox_chats, relying on the name for differentiation.
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?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites, exclusions, or typical use cases. The agent receives no direction on selecting this over other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, required permissions, or pagination details. It only states the basic function without addressing side effects or constraints.
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 clear sentence with no unnecessary words. It could be more structured, but it is efficient and front-loaded.
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 the lack of output schema and annotations, the description is incomplete. It does not explain the return format (e.g., list of stage objects) or how to use the results for ticket updates, leaving gaps for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters having descriptions. The tool description does not add meaning beyond the schema, so a baseline of 3 is appropriate.
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 states the tool searches for stages of a desk in TiFlux for use in ticket updates. It uses specific verb 'Buscar' and resource 'estagios de uma mesa', and the context of ticket updates distinguishes it from siblings like 'get_ticket_stages_slas'.
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 alternatives. While it mentions the use case (ticket updates), it does not specify when not to use it or name sibling tools that might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It does not disclose side effects, permissions, or irreversibility of closing a ticket.
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?
Single sentence that is concise and directly states the tool's purpose. No wasted words.
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?
For a simple one-parameter tool with no output schema, the description is minimally adequate but lacks details on return values, confirmation, or constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for ticket_number. The tool description adds no additional context beyond the schema, so baseline 3 is appropriate.
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 states the action (fechar) and resource (ticket específico no TiFlux), but does not differentiate from sibling tools like cancel_ticket.
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 alternatives like cancel_ticket or update_ticket. No when-not-to conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not mention that the operation is read-only, any authorization requirements, pagination behavior, or side effects. The description is insufficient for an uninformed agent.
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, short sentence with no redundancy. It is concise but could incorporate more useful information without sacrificing brevity.
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 the tool's simplicity (list with pagination) and no output schema, the description is incomplete. It does not hint at the return format, ordering, or how pagination works. The presence of sibling tools like 'get_internal_communication' is not leveraged to clarify distinctions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter described. The description adds no extra meaning beyond the schema (e.g., clarifying the return format or pagination behavior). Baseline 3 is appropriate.
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 the tool's purpose: listing internal communications for a specific ticket. The verb 'list' and resource 'internal communications' are specific, distinguishing it from siblings like 'get_internal_communication' and 'create_internal_communication'.
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?
The description provides no guidance on when to use this tool versus alternatives (e.g., 'get_internal_communication' for a single item). It lacks when-not-to-use or prerequisite information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It only states the action, omitting side effects (e.g., whether the ticket status changes, if notifications are sent). Parameter descriptions in the schema provide some detail, but the tool description itself is insufficient.
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?
The description is a single sentence that concisely captures the tool's purpose without extraneous information. It is front-loaded and efficient.
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 5 parameters, no output schema, and no annotations, the description is too minimal. It lacks information about what happens upon creation (e.g., return value, confirmation), prerequisites, or constraints beyond parameter definitions. The sibling tools imply context, but the description itself is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters are described in the input schema. The tool description adds no additional parameter semantics beyond what is already present, meeting the baseline but not exceeding it.
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 the tool creates a new response (customer communication) on a specific ticket. It uses a specific verb and resource, distinguishing it from sibling tools like create_internal_communication.
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?
The description does not provide any guidance on when to use this tool compared to alternatives (e.g., create_internal_communication, update_ticket). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. However, it does not disclose any behavioral traits beyond the basic purpose, such as whether it is read-only, pagination, error handling, or performance implications. The description is minimal.
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, concise sentence. It is appropriately sized for a simple tool. However, it is in Portuguese while the tool name is in English, which may slightly hinder immediate clarity, but overall it is efficient.
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?
Given the tool's simplicity (one required parameter, no output schema), the description is adequate but incomplete. It does not describe the return format, possible file types, or any additional context needed for effective use. It meets minimal requirements but lacks completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with ticket_number described. The description does not add significant meaning beyond what the schema provides; it merely reiterates the parameter. However, since coverage is high, a baseline of 3 is appropriate, but no extra value is added.
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 the tool's purpose: retrieving files attached to a specific ticket in TiFlux. It uses a specific verb-resource combination ('buscar arquivos anexados a um ticket') and distinguishes itself from sibling tools like create_ticket or get_ticket which serve different functions.
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. There is no mention of prerequisites, context for usage, or conditions where it should not be used. The description only states the basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the basic operation (listing unassigned chats) but does not disclose behavioral traits like read-only nature, pagination behavior, or potential side effects.
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?
The description is a single, front-loaded sentence that efficiently conveys the core purpose. Every word is necessary, and it avoids redundancy.
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 the tool has 8 parameters and no output schema, the description is too minimal. It fails to mention what the response contains, pagination details, or any additional context needed for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description lists some filters (department, client, origin, pagination) but misses several parameters (requestor_id, number, started_by). It does not add significant meaning beyond the schema descriptions.
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 it lists chats in the inbox (unassigned chats) with optional filters, distinguishing it from siblings like list_archived_chats and list_in_attendance_chats.
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?
The description provides no guidance on when to use this tool versus alternatives like list_my_chats or list_in_attendance_chats. It only mentions filters but does not explain context for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It reveals that the tool shows service evaluation and cancellation status, which adds value. However, it does not describe scope, ordering, pagination behavior, or potential performance impacts. Some key behavior (e.g., what 'archived' means, if results are limited to the user) is omitted.
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?
The description is two sentences in Portuguese, very concise and front-loaded. The first sentence states the core purpose, and the second adds key output details. No extraneous words or filler.
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 tool has 9 optional parameters and no output schema. The description covers the basic operation and mentions two output fields (evaluation, cancellation). However, it does not describe the overall return structure (e.g., pagination metadata, fields like client, department, etc.), which would be helpful given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 9 parameters are fully described in the input schema (100% coverage). The description only mentions 'optional filters' without adding any extra context or clarifying parameter relationships. Since the schema already handles parameter semantics, the description provides no additional value beyond the baseline of 3.
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 states that the tool lists archived (finished or canceled) chats with optional filters. It specifies the resource and action, and mentions output details like evaluation and cancellation status. However, it does not explicitly differentiate from sibling tools like list_in_attendance_chats or list_my_chats, though the term 'archived' implies a specific state.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that this is for archived chats only, nor any prerequisites or exclusions. The agent must infer from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool retrieves a communication with full text, but does not disclose behavioral traits such as authentication requirements, error handling, or whether it is read-only. Minimal transparency beyond the basic action.
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 sentence of 8 words, very concise and efficient. It could be slightly more structured by separating the action from the parameters, but it is appropriately sized.
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 description mentions 'com texto completo' (with full text), indicating the return includes the full text, but it lacks details on other return information or error scenarios. For a simple get operation with no output schema, it is minimally adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add extra meaning beyond the parameter descriptions in the schema, such as clarifying required fields or providing example values.
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 'Obter uma comunicação interna específica com texto completo' clearly states the verb 'obter' (get) and the resource 'comunicação interna' (internal communication). It distinguishes from sibling tools like list_internal_communications (list) and create_internal_communication (create) by specifying a single specific communication.
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?
The description implies usage for retrieving a single communication by ticket_number and communication_id, but lacks explicit guidance on when to use this tool versus listing or creating. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It confirms the tool creates records (mutation) but lacks details on permissions, reversibility, output, or error conditions.
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?
The description is extremely concise with two sentences. The first sentence states the primary action, and the second adds a critical constraint. No wasted words.
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 5 required parameters, no output schema, and no annotations, the description is too minimal. It fails to cover return values, error scenarios, or post-creation behavior, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no additional parameter semantics beyond the schema, resulting in a neutral score.
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 the verb 'criar' (create) and the resource 'apontamento em um ticket específico' (appointment in a specific ticket), distinguishing it from sibling tools like list_appointments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an explicit condition for usage: only works on tickets of desks configured with appointments without valuation. It does not mention alternatives or when not to use it, but the condition provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It mentions that valuation info and geolocation are included when available, adding some behavioral context, but it does not disclose pagination behavior or confirm it is read-only.
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?
Two sentences with no waste. The first sentence states the core purpose, and the second adds valuable context. Highly concise and front-loaded.
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 6 parameters and no output schema, the description is adequate but not fully complete. It hints at return content (valuation, geolocation) but does not describe the structure of the returned list or pagination behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no additional semantic meaning beyond the schema for the parameters, only a general note about included information.
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 the verb 'listar' and the resource 'apontamentos' (hour records) for a specific ticket, with optional filters. It distinguishes from sibling tools like create_appointment and list_tickets.
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?
The description implies usage for listing work logs of a ticket but provides no explicit guidance on when to use vs alternatives or when not to use it. No exclusions or comparisons are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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. It states the tool lists chats assumed by the authenticated user and supports pagination, but it does not disclose whether the operation is read-only, any ordering, or the state of chats returned (e.g., in attendance or archived). More behavioral detail would be beneficial.
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?
The description is a single sentence that is front-loaded with the core purpose. It is concise and to the point, with no extraneous information.
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 tool has no output schema, but as a list operation, the return format is important. The description does not specify what fields are returned or pagination metadata. Given the complexity (8 parameters) and sibling tools, the description is adequate but could be more complete by mentioning the output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 8 parameters. The description mentions 'optional filters and pagination' but does not add meaningful detail beyond what the schema provides. A baseline of 3 is appropriate.
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 the verb 'Listar' (list), resource 'chats', and scope 'assumidos pelo usuário autenticado' (assumed by the authenticated user). It also mentions filters and pagination, distinguishing it from siblings like 'list_in_attendance_chats' or 'list_inbox_chats' which likely have different scopes.
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?
The description implies the tool is for listing chats taken by the authenticated user but does not provide explicit guidance on when to use it versus alternatives such as 'list_in_attendance_chats' or 'list_inbox_chats'. There is no mention of when not to use it or comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states the tool returns a card with specific fields, which implies read-only behavior, but does not explicitly confirm read-only operation, permissions, rate limits, or error handling. The lack of explicit safety info is a gap.
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?
The description is a single concise sentence in Portuguese that immediately states the purpose and return value. No filler or redundant information.
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 simple get-by-ID tool, the description adequately covers the purpose and return content. However, it lacks information about error cases (e.g., chat not found) or permission requirements, which would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a thorough parameter description explaining that the ID accepts numeric strings and that the handler parses them. This adds value beyond the type definition.
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 the tool retrieves a specific chat by ID and returns a card with status, client, responsible, department, origin, evaluation, and dates. This distinguishes it from sibling tools like list_inbox_chats or get_ticket.
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?
The description implies usage for fetching a single chat by ID but provides no explicit guidance on when to use this versus alternatives like list_my_chats or list_in_attendance_chats. No 'when not to use' or alternative tool references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description discloses what the tool returns but does not explicitly state that it is read-only, idempotent, or mention authentication or rate limits. It adequately conveys safe retrieval behavior but lacks explicit behavioral traits.
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 description is a single long sentence that lists many return fields. While informative, it could be more structured with bullet points or shorter sentences. It is not verbose but could be better organized.
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?
No output schema exists, but the description compensates by comprehensively listing the returned fields (status, priority, desk, stage, service catalog, etc.) and mentions optional custom fields. This provides sufficient context for understanding the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 3 parameters are described in the schema (100% coverage). The description adds context by explaining that show_entities includes all custom fields and include_filled_entity filters to filled ones, providing meaning beyond the schema's brief descriptions.
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?
Clearly states 'Buscar um ticket específico no TiFlux pelo número'—a specific verb and resource. The description differentiates from sibling tools like list_tickets (returns multiple) and get_ticket_files (specific subset), making its purpose unambiguous.
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?
The description implies when to use (when you need full details of a specific ticket) but does not explicitly state when not to use or suggest alternatives. No direct guidance on choosing among siblings like get_ticket_files or get_ticket_stages_slas.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the search functionality without mentioning any behavioral traits such as idempotency, rate limits, or pagination. For a read-only tool, this is insufficient.
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?
The description is a single sentence that is front-loaded with the key information. Every word serves a purpose, making it highly concise and efficient.
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?
Despite the absence of an output schema, the description is fairly complete for a simple search tool with one parameter. It could mention that the output is a list of matching clients, but the tool name and context imply this. No major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'client_name' already described as partial search. The tool description adds no additional meaning beyond what the schema provides, so a baseline score of 3 is appropriate.
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 the verb 'Buscar' (search), the resource 'clientes' (clients), and the context 'no TiFlux' (in TiFlux) with the criterion 'por nome' (by name). This distinguishes it from sibling search tools like search_user or search_stage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (to search clients by name), but does not explicitly mention when not to use it or provide alternatives. The context is clear enough for an agent to differentiate from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description bears full burden. It discloses return fields (nome, tipo, obrigatoriedade, selectable options indicator) but lacks detail on authentication, rate limits, or pagination behavior beyond schema.
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 concise, front-loading purpose in a single sentence. It avoids redundancy but could be slightly more structured.
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 list tool with 6 parameters and no output schema, the description adequately covers return values and provides a usage hint for a related tool. It is sufficient for the agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; description adds no extra meaning beyond schema. It reiterates that entity_id is required and obtainable via list_entities, which is already in schema.
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 the verb 'Listar' and the resource 'subcampos (entity_fields) de um campo personalizado (entity)'. It distinguishes from sibling tools like list_entities and list_entity_field_options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells when to use list_entity_field_options instead, providing explicit guidance for fields with selectable options. However, it does not explicitly contrast with other sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It implies a read-only search but does not disclose behavioral traits like authentication needs, pagination details, or that it returns user data. Minimal beyond 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, well-structured sentence that front-loads the purpose. No unnecessary words or redundancy.
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 description is adequate for a simple search tool but lacks information about return values and how results relate to the intended use case. Given no output schema, this is a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context about the use case but no new parameter semantics beyond what the schema already provides (e.g., partial search for name).
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 the tool searches users by name in TiFlux for the specific purpose of assigning them as responsible for tickets. It distinguishes from sibling tools like search_client and search_stage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear context: to find users to set as ticket responsible. However, it does not explicitly exclude other uses or compare to alternatives like search_client.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden. It declares the tool lists desks but does not mention authorization, side effects, or confirm it is read-only. For a list operation, this is minimally acceptable but lacks explicit behavioral details.
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?
The description is two sentences, front-loaded with purpose and immediate usage guidance. Every sentence adds value; no wasted words.
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 list tool with no output schema, the description and schema together provide sufficient context for using the tool. It could mention expected return structure, but the parameters and purpose are well-covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a clear description. The tool description does not add additional meaning beyond the schema, so it meets the baseline of 3.
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?
Description clearly states the tool lists desks (mesas) in TiFlux for discovery and exploration, with specific use cases (before creating/updating tickets, inspecting configurations). It differentiates from sibling tools like get_desk (singular) and related list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly advises when to use the tool ('antes de criar/atualizar tickets ou para inspecionar configuracoes'), providing clear context. It does not explicitly state when not to use it, but alternatives are implied by sibling tools such as get_desk.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It describes a read operation but does not explicitly state read-only nature or mention pagination, rate limits, or side effects. Sufficient for a simple list operation.
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?
Two efficient sentences with no wasted words. Purpose and use case are front-loaded, and key information is delivered succinctly.
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?
While lacking output schema and annotations, the description provides sufficient context for discovering entities and linking to list_entity_fields. Does not mention pagination details but schema covers limit/offset.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameter details are already in schema. Description adds no extra meaning beyond mentioning 'aplicacoes' which maps to applied_in, but schema already covers that.
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?
Description clearly states the tool lists custom fields/entities, specifying it discovers groups, applications, and IDs. It distinguishes from sibling 'list_entity_fields' by noting the IDs are necessary for that tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly says 'Use to discover...' providing clear usage context. While it does not list when not to use, the purpose is well-defined among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses behavioral traits: server-side vs client-side search, partial matching, case-insensitive, hierarchy in results, collapse to single detail on exact match, and error with list on multiple matches. It does not mention auth needs or rate limits, but for a search tool this is adequate.
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 paragraph that is front-loaded with the overall purpose, then explains the two main search modes. It is concise and structured logically, with no redundant information.
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?
Given the tool complexity (8 parameters, no output schema, no annotations), the description covers all parameter semantics and search behaviors. It describes the return format (list with hierarchy or detail) and error condition. It is complete enough for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 8 parameters have descriptions in the schema (100% coverage). The description adds significant value by explaining the semantic difference between `search` and `catalog_item_name`, the behavior of `desk_name` as a fuzzy match, and how parameters interact (e.g., combine with area_id). This goes beyond what the schema provides.
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 states the tool searches for service catalog items by free text or by name/filter within a specific desk. It identifies the action (search), resource (catalog items), and method (by term or name). It does not explicitly differentiate from sibling tools, but the domain is distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use `search` (server-side, approximate term) vs `catalog_item_name` (client-side, specific name). It also mentions combining with `area_id` or `catalog_id` to restrict scope. It lacks explicit when-not-to-use scenarios but covers parameter usage well.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It mentions the 50-field limit and checkbox handling, but does not disclose whether the operation is atomic, if it overwrites or merges entities, permissions required, or error handling behavior.
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?
The description is concise, front-loaded with the purpose, and each sentence adds necessary information without redundancy.
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?
The description covers key aspects like field limits, checkbox handling, and value formatting. However, it lacks information about error scenarios, what happens on partial failures, and the return value (no output schema). Given the tool's complexity, these gaps are minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The tool description adds value beyond the schema by explaining the 50-field limit, how to find option IDs using list_entity_field_options, and the exact formatting for different entity types (e.g., currency, phone, date).
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 the tool updates custom fields (entities) of a ticket in TiFlux, specifies a 50-field limit, and explains how to handle checkbox fields. It distinguishes itself from the sibling 'update_ticket' tool which likely handles standard fields.
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?
The description provides some contextual usage (e.g., how to handle checkboxes and use list_entity_field_options), but does not explicitly state when to use this tool versus alternatives like update_ticket, nor does it give when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavior. It mentions pagination (offset/limit defaults and max) and filter logic, but does not disclose the return format, potential errors (e.g., missing filter), authentication needs, or rate limits. It is adequate but lacks full behavioral disclosure.
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 longer than average but well-structured with a table and clear sections. It frontloads the main purpose and then provides detailed heuristics. Every sentence adds value, though some repetition exists between schema descriptions and the heuristic. Overall, it is concise relative to the complexity.
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?
Given 15 parameters and no output schema, the description covers filter logic thoroughly but misses the return value format and any constraints like the required filter (schema says required is empty, but description states 'at least one filter required' – a minor contradiction). It also doesn't mention when to use list_tickets vs get_ticket. The heuristic is strong, but completeness is not fully achieved.
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?
Despite 100% schema coverage, the description adds significant value beyond the schema with a heuristic table, examples (e.g., 'cansados' for desk_name), and resolution strategies (using search_user for IDs). It transforms parameter understanding into a decision tree for user intents, making it highly semantic.
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 states it lists tickets from TiFlux with filters, using a specific verb and resource. It distinguishes itself from create, get, and close siblings by focusing on listing. However, it doesn't explicitly differentiate from other list tools like list_appointments, though the name and context make it clear.
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?
The description provides explicit when-to-use guidance, including a heuristic table mapping user input types to the correct filters (e.g., desk_name vs client_name vs requestor_email). It also advises when not to use certain parameters and how to resolve IDs via search_user, offering comprehensive decision context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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. It discloses the tool returns 'complete settings' and mentions Smart Name Resolution. However, it lacks explicit safety guarantees, side effects, or error behavior. Given no read-only annotation, the agent cannot be sure it's non-destructive.
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?
The description is two sentences, concise, and front-loaded with the main purpose. Every word contributes; no fluff or repetition.
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 simple retrieval tool with two optional parameters and no output schema, the description covers the essentials: what is returned, how to specify the desk, and parameter interaction. It omits error handling (e.g., desk not found) and assumes the agent knows the structure of returned settings, but is sufficient given the tool's simplicity.
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 coverage is 100% with descriptions for both parameters. The description adds value beyond the schema by explaining the fuzzy match behavior for desk_name (Smart Name Resolution) and the precedence rule when both are provided.
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 the tool retrieves complete desk settings (configurações completas de uma mesa), specifying the resource and action. It distinguishes from siblings like list_desks by focusing on a single desk's full details, and from other get_* tools by the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each parameter (desk_id for direct, desk_name for fuzzy) and the precedence rule. However, it does not explicitly guide when to use this tool over alternatives like list_desks or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses key behavioral traits: acceptance of numeric ID or fuzzy-matched name for desk, precedence rules, and client-side fuzzy filtering for priorities. However, it does not explicitly state whether the operation is read-only or non-destructive, which is implied but not confirmed for an agent.
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?
The description is three sentences covering purpose, parameter usage, and a behavioral detail. Every sentence is relevant and efficiently communicates essential information without redundancy.
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 description covers the primary use case and parameter options but omits details about the response format (e.g., list of priorities with IDs and names) and pagination behavior (limit/offset). Given 5 parameters and no output schema, more context on expected output would improve completeness for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds some context beyond the schema, such as the precedence of desk_id over desk_name when both are provided, but the schema already describes this. The client-side fuzzy match for priority_name is also described in the schema. Thus, minimal additional meaning.
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 the tool lists configured priorities for a desk in TiFlux, with the specific use case of discovering priority IDs before creating or updating tickets. It uniquely identifies the resource (desk priorities) and distinguishes from sibling tools like list_desks or list_tickets, which cover different entities.
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?
The description provides explicit guidance on when to use the tool ('para descobrir os IDs de prioridade antes de criar ou atualizar tickets'), explains parameter alternatives (desk_id vs desk_name with precedence), and describes the client-side fuzzy filter behavior for priority_name. No exclusions are needed due to lack of overlapping siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It discloses that the tool returns stage history with duration, expiration, and SLA status, and that desks without SLA yield an empty list. It implies a read operation. No destructive behavior is indicated, and the description is consistent.
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?
The description is two sentences, each adding essential information: the core function and an important behavioral caveat. No redundant or verbose language.
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?
Given the lack of output schema and annotations, the description explains what the tool returns (stage history with timings and SLA status) and its boundary conditions (SLA active desks only). It is sufficient for an agent to decide when to invoke the tool and what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are fully described in the schema (100% coverage). The description adds value by clarifying that 'offset' represents page number and that pagination is supported, which aids understanding beyond the raw schema fields.
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 the tool lists the history of ticket stage passages with SLA-related data. It specifies the resource ('histórico de passagens do ticket pelos estágios da mesa') and distinguishes from siblings like 'get_ticket' or 'list_tickets'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a key usage condition: 'Retorna apenas tickets de mesas com SLA ativo (mesas sem SLA retornam lista vazia)', guiding when to expect results. It also mentions pagination support. However, it does not explicitly list alternatives or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description implies a safe read-only operation by stating it lists options. It does not mention destructive behavior or side effects. The description is sufficient for understanding the tool's behavior.
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?
The description is a single sentence that is front-loaded with the purpose. It is concise with no wasted words.
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?
While there is no output schema, the description adequately explains the tool's purpose and how to use the parameters. It could mention the return format, but given the tool's simplicity, it is still complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds value by explaining how to obtain entity_field_id (via list_entity_fields) and that value enables partial search. It also mentions defaults for limit and offset, adding meaning beyond the schema.
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 the tool lists options of entity fields of types single_select or checkbox, and specifies its purpose: to obtain option IDs needed for update_ticket_entities. This is a specific verb-resource combination that distinguishes from sibling tools like list_entity_fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool to get option IDs for update_ticket_entities, and references list_entity_fields for obtaining entity_field_id. It provides clear context but does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully discloses behavior: listing parent containers, fuzzy matching, precedence when both desk_id and desk_name are provided, and client-side filtering. It does not explicitly state read-only nature, but 'listar' implies it. No contradictions.
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?
The description is concise with 4 sentences, each adding value. It starts with the main purpose, then covers desk identification, precedence, and filtering. No extraneous words.
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?
Given the tool has 5 parameters, no required ones, no output schema, and no annotations, the description provides sufficient context: behavioral details, fuzzy matching, precedence, and client-side filtering. It could mention the return format (list of catalog objects) but is not necessary per rules.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context beyond schema by explaining fuzzy matching for desk_name and catalog_name, the precedence rule, and the distinction between catalog and catalog item. This enriches the parameter semantics.
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 the tool lists catalogs (parent containers) associated with a desk, and distinguishes it from catalog items by directing users to search_catalog_item. The verb 'listar' and resource 'catalogos de servicos vinculados a uma mesa' are specific, differentiating it from siblings.
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?
The description explicitly states when to use this tool (listing catalogs) and when to use an alternative (search_catalog_item for items). It provides clear guidance on desk identification via desk_id or desk_name with precedence rules, and mentions fuzzy matching for desk_name and catalog_name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Nenhuma anotação fornecida, então a descrição carrega todo o peso. Revela que a API v2 não permite alterar solicitante, que desk_id não suporta transferência via update, que o campo description aceita Markdown e é convertido para HTML, e que responsible_id pode ser null para remover responsável. Esses comportamentos vão além do que está no schema.
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 descrição tem seções claras (propósito, heurística, nota) e informações importantes estão no início. É um pouco longa devido aos detalhes, mas cada frase contribui para a clareza. Não é excessivamente prolixa.
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?
A descrição cobre comportamento, parâmetros, limitações e alternativas. A ausência de schema de saída não é compensada por menção ao retorno, mas para uma ferramenta de atualização, isso pode ser inferido. Dados os 13 parâmetros e a complexidade, a descrição é bastante completa.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
A cobertura do schema é 100% (todos os parâmetros com descrição), então a linha de base é 3. A descrição adiciona valor extra, como a preferência por desk_name sobre client_id, a conversão automática de Markdown em description, e a busca automática por nome em desk_name, stage_name, catalog_item_name. Isso justifica um 4.
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?
A primeira frase define claramente a ação: 'Atualizar um ticket existente no TiFlux.' O verbo 'atualizar' e o recurso 'ticket' são específicos. Distingue-se de ferramentas irmãs como create_ticket, cancel_ticket e 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?
Fornece orientação explícita sobre quando usar desk_name vs client_id ('heurística mesa-first'), e indica explicitamente uma alternativa (create_ticket) para vincular solicitante, uma vez que a API v2 não permite alterá-lo via update. Também menciona a limitação de transferência de mesa.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![tiflux-mcp MCP server](https://glama.ai/mcp/servers/tiflux/tiflux-mcp/badges/card.svg)](https://glama.ai/mcp/servers/tiflux/tiflux-mcp)

Score Badge

Copy to your README.md:

[![tiflux-mcp MCP server](https://glama.ai/mcp/servers/tiflux/tiflux-mcp/badges/score.svg)](https://glama.ai/mcp/servers/tiflux/tiflux-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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