Skip to main content
Glama
ati-hh-mcp

ati-hh-mcp

by timur-ai

Send Chat Message

send_chat_message

Sends a text message or file to a specified chat after confirmation, enabling agents to deliver updates or share documents directly.

Instructions

Send a message to a chat: either a text message ({"text": "..."}) or a file ({"file_upload_id": "..."} from create_chat_file_upload_link). Mutation: requires confirm=True.

Input Schema

NameRequiredDescriptionDefault
bodyYes
chat_idYes
confirmNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior3/5

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

With no annotations supplied, the description carries the full burden and does disclose the two most important traits: this is a mutation and it requires confirm=True. It says nothing about write-permission prerequisites (the existence of set_chat_write_possibility hints at them), what happens on failure, or whether the call creates visible side effects beyond the message itself.

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 compact sentence pair with zero filler; the payload variants and the confirm requirement are front-loaded where an agent needs them before constructing the call.

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 3-parameter mutation with a free-form nested body, no annotations, and no output schema, the description covers the call-critical facts: payload shape, prerequisite tool, and confirmation flag. Gaps remain around return value, permission requirements, and error conditions, but none prevent a correct invocation.

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 description coverage is 0% and body is an unconstrained nested object, so the schema alone would leave an agent unable to construct a payload. The description compensates well by giving the exact body shapes ({'text': ...} or {'file_upload_id': ...}) and explaining confirm. It still leaves chat_id uncharacterized and does not say whether text and file_upload_id can be combined or whether other body keys are honored.

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 ('Send a message to a chat') and immediately disambiguates the two payload forms (text vs. file). The 'to a chat' scoping also separates it from send_negotiation_message, and the name/description combination makes clear it is not update_chat_message or list_chat_messages.

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?

Gives concrete when-to-use guidance by naming the prerequisite for the file path (create_chat_file_upload_link) and by flagging the mandatory confirm=True for this mutation. It stops short of stating when not to use it (e.g. for negotiation threads or for editing an existing message), but the operative routing information is present.

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