Chatway Live Chat

Add Contact Tag

add-tag

Destructive

Attach a named tag to the visitor/contact associated with a Chatway conversation. If supported by Chatway, the tag may be created when it does not already exist. Use list-tags first to reuse an existing tag name, and remove-tag to undo.

Input Schema

Name	Required	Description
`name`	Yes	Tag name, up to 100 characters. An existing tag with this name is reused; otherwise a new tag is created.
`color`	No	Optional tag color, up to 50 characters (for example a hex code such as #2563EB). If the tag already exists, its color is changed to this value.
`conversation_id`	Yes	UUID of the conversation; the tag is attached to its visitor/contact.

Output Schema

Name	Required	Description
`tag`	No	Tag name.
`chat_contact_id`	No	Visitor/contact UUID the tag was attached to.
`conversation_id`	No	Conversation UUID.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 15, 2026

addedInput schema / properties / color / description

Added value: +"Optional tag color, up to 50 characters (for example a hex code such as #2563EB). If the tag already exists, its color is changed to this value."

addedInput schema / properties / conversation_id / description

Added value: +"UUID of the conversation; the tag is attached to its visitor/contact."

addedInput schema / properties / name / description

Added value: +"Tag name, up to 100 characters. An existing tag with this name is reused; otherwise a new tag is created."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "chat_contact_id": {
+      "description": "Visitor/contact UUID the tag was attached to.",
+      "type": "string"
+    },
+    "conversation_id": {
+      "description": "Conversation UUID.",
+      "type": "string"
+    },
+    "tag": {
+      "description": "Tag name.",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedOct 15, 2026

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=false, so the risk profile is covered. The description adds genuinely new context: a tag may be auto-created if it doesn't exist, which is a meaningful side effect. However, it never acknowledges the destructive nature surfaced by the annotation, nor mentions permissions, rate limits, or what happens to an existing tag's color beyond the 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?

Three short sentences, front-loaded with the core action, then sequencing guidance. The hedge 'If supported by Chatway, the tag may be created' is a bit vague but does carry real information about conditional behavior, so it earns its place.

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?

With an output schema present, return values needn't be explained, and all three parameters are documented. The remaining gap is that the destructive hint in annotations is never contextualized—an agent gets no sense of reversibility beyond the remove-tag pointer.

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, color, conversation_id) are already fully documented, including reuse and color-override behavior. The description adds no syntax, format, or constraint detail beyond the schema, so baseline 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?

Specific verb+resource: 'Attach a named tag to the visitor/contact associated with a Chatway conversation.' It clearly distinguishes itself from sibling tools like remove-tag, list-tags, and the custom-data tools, which operate on different objects.

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 prescribes the flow: call `list-tags` first to reuse an existing name, and use `remove-tag` to undo. Both the alternative and the condition selecting it are named, leaving nothing to inference.

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?