Chatway Live Chat

Remove Contact Tag

remove-tag

Destructive

Remove a named tag from the visitor/contact associated with a Chatway conversation. This is destructive and requires user confirmation. Use view-tags to check the exact tag name.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	Exact name of the tag to remove.
`conversation_id`	Yes	UUID of the conversation whose visitor/contact the tag is removed from.
`confirmation_token`	No	Required after the confirmation challenge. Ask the user to approve before calling again with this token.

Output Schema

TableJSON Schema

Name	Required	Description
`message`	No	Message describing the action or its result.
`removed_tag`	No	Name of the removed tag.
`affected_count`	No	Number of records the action will change.
`chat_contact_id`	No	Visitor/contact UUID the tag was removed from.
`conversation_id`	No	Conversation UUID.
`confirmation_token`	No	Pass back as confirmation_token after the user approves.
`expires_in_seconds`	No	How long the confirmation token stays valid.
`confirmation_required`	No	True when the user must approve before the action runs.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 15, 2026

addedInput schema / properties / confirmation_token / description

Added value: +"Required after the confirmation challenge. Ask the user to approve before calling again with this token."

addedInput schema / properties / conversation_id / description

Added value: +"UUID of the conversation whose visitor/contact the tag is removed from."

addedInput schema / properties / name / description

Added value: +"Exact name of the tag to remove."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "affected_count": {
+      "description": "Number of records the action will change.",
+      "type": "integer"
+    },
+    "chat_contact_id": {
+      "description": "Visitor/contact UUID the tag was removed from.",
+      "type": "string"
+    },
+    "confirmation_required": {
+      "description": "True when the user must approve before the action runs.",
+      "type": "boolean"
+    },
+    "confirmation_token": {
+      "description": "Pass back as confirmation_token after the user approves.",
+      "type": "string"
+    },
+    "conversation_id": {
+      "description": "Conversation UUID.",
+      "type": "string"
+    },
+    "expires_in_seconds": {
+      "description": "How long the confirmation token stays valid.",
+      "type": "integer"
+    },
+    "message": {
+      "description": "Message describing the action or its result.",
+      "type": "string"
+    },
+    "removed_tag": {
+      "description": "Name of the removed tag.",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedOct 15, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds genuinely useful behavior beyond them: the operation requires user confirmation, and the agent is told to validate the tag name first, which explains the confirmation/two-step invocation pattern.

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?

Three short sentences, front-loaded with the action and target, followed by the destructive/confirmation caveat and the sibling pointer. Every sentence earns its place with no 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?

An output schema exists, so return values need no explanation, and the description covers the destructive nature, confirmation requirement, and tag-name validation. It is slightly incomplete on edge cases such as a nonexistent tag name or permission requirements, but nothing essential for a correct invocation is missing.

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 all three parameters (name, conversation_id, confirmation_token) are already documented in the schema, including the confirmation flow wording. The description's 'named tag' and 'requires user confirmation' restate rather than extend that information, so the baseline of 3 applies.

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 and resource ('Remove a named tag from the visitor/contact associated with a Chatway conversation'), scoping it to the visitor/contact tied to a conversation rather than the conversation object itself. This cleanly distinguishes it from the sibling add-tag and remove-custom-data operations.

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?

Explicitly routes the agent to the `view-tags` sibling to verify the exact tag name, which is the key precondition for a correct call. It also flags the user-confirmation requirement, though it does not spell out when *not* to use the tool (e.g., tag absent).

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

All Chatway Live Chat 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?