Ignix

Triage a conversation

update_conversation

Destructive

Triage a conversation in the inbox, the way an operator does from the app: pipeline stage, labels, assignee (a member or a team, or nobody), ticket priority and subject, mark it read, escalate it to a human (silences the bot on that thread and notifies the team) or mark it handled (clears the escalation and lets the bot answer this contact again). Several changes can go in one call. Nothing here is sent to the customer. Member and team ids come from list_team; labels are free text (max 10 per conversation, 30 characters each). Assigning notifies that person, so confirm who with the user when it is not obvious. Pass accountId (from list_conversations) when the conversation may be new to Ignix.

Input Schema

Name	Required	Description
`stage`	No
`labels`	No	Replaces the whole label list. Pass [] to clear. Use addLabels/removeLabels to change only some.
`subject`	No	Ticket subject (max 120 characters). Empty string clears it.
`markRead`	No
`platform`	No	Restrict to one network.
`priority`	No	Ticket priority. Meant for conversations already turned into a ticket (create_ticket).
`unassign`	No	Remove the member and team assignment.
`accountId`	No	Restrict to one account (Ignix account id from list_accounts).
`addLabels`	No	Labels to add, keeping the rest.
`markHandled`	No	The human took care of it: clears the "needs human" flag and resumes the bot for this contact.
`assignTeamId`	No	Assign to this team (team id from list_team). Can be combined with assignUserId.
`assignUserId`	No	Assign to this member (user id from list_team). Can be combined with assignTeamId.
`removeLabels`	No	Labels to remove, keeping the rest.
`conversationId`	Yes
`idempotencyKey`	No	Optional. A unique id for this action (16-128 chars: letters, digits, _ : . -). If you are unsure whether a call went through (timeout, network error), repeat it with the SAME idempotencyKey and the same arguments: you get the original result and nothing is done twice.
`escalateToHuman`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 17, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing what escalation does (silences the bot on the thread and notifies the team), what markHandled does (clears the flag and resumes the bot), that assigning notifies the person, that nothing is sent to the customer, and the labels-replacement semantics. These are exactly the side effects an agent needs before calling a destructive, open-world mutation.

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?

Dense but front-loaded: purpose first, then behaviors, then id sourcing. Every sentence carries information, though the single long paragraph mixes escalation, assignment and label rules together, which slightly hurts scannability.

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

Completeness5/5

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

For a 16-parameter mutation with no output schema, the description covers purpose, side effects, id provenance, idempotency expectations and limits. An agent has enough to call it correctly without opening other tools.

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?

With 75% schema coverage the schema carries much of the load, but the description adds real meaning: labels are free text capped at 10 per conversation / 30 chars each, assignee can be a member, a team, or nobody, and id sources are named. It doesn't explain stage, markRead, or platform beyond what the schema provides.

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?

States a specific verb (triage) and resource (a conversation in the inbox) and enumerates exactly what can be changed: pipeline stage, labels, assignee, priority, subject, read state, escalation. This clearly distinguishes it from get_conversation, list_conversations, add_conversation_note and send_message.

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?

Explicitly frames the operator workflow ('the way an operator does from the app'), names the id sources (list_team for member/team ids, list_conversations for accountId), and routes to alternatives: labels vs addLabels/removeLabels, and create_ticket for priority. It even adds a decision rule ('confirm who with the user when it is not obvious').

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

All Ignix tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?