Skip to main content
Glama

chat_send

Sends a message on behalf of the token owner to a chat (a task's chat ID is the task ID) or, with userID, a direct message to an employee; replyMessageID quotes a message that other messages already follow. Intended for blocking questions, replies to messages addressed to the token owner and messages the user asks for - not for status updates, summaries or links to created items. Messages newer than the last read (the after cursor) may already hold the same question or its answer. Returns chatID, the message and an after cursor; the message can be edited or deleted within 60 minutes.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "text": "<text>"
    },
    "name": "chat_send"
  }
}

Input Schema

NameRequiredDescriptionDefault
textYesMessage in the language of the workspace data: Markdown without headings, tables or images; bare URLs become links. Tasks and features go in as their link value, employees as their mention token where addressed; a direct chat has no mentions
chatIDNoChat ID; for a task's chat - the task ID, for the company's general chat - the company ID
userIDNoEmployee ID for a direct message, instead of chatID
attachmentsNoUp to 5 attachments: each is an uploaded file's fid or name with dataBase64
idempotencyKeyNoRetry-safety key: one key per chat yields one message
replyMessageIDNoID of a message in this chat to quote, only when it is no longer the last one; a reply to the last message has no quote

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / replyMessageID / description
      Previous value: -"ID of the message in this chat to reply to"New value: +"ID of a message in this chat to quote, only when it is no longer the last one; a reply to the last message has no quote"
    • changedInput schema / properties / text / description
      Previous value: -"Message in the language of the workspace data: Markdown without headings, tables or images; bare URLs become links. Tasks and features go in as their link value, employees as their mention token where addressed"New value: +"Message in the language of the workspace data: Markdown without headings, tables or images; bare URLs become links. Tasks and features go in as their link value, employees as their mention token where addressed; a direct chat has no mentions"
  2. Changed3 schema fields changed
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • changedInput schema / properties / chatID / description
      Previous value: -"Chat ID; for a task's chat - the task ID"New value: +"Chat ID; for a task's chat - the task ID, for the company's general chat - the company ID"
    • removedInput schema / properties / mentions
      Removed value: -{
      -  "description": "Not needed: mentions come from mention tokens in text",
      -  "items": {
      -    "format": "uuid",
      -    "type": "string"
      -  },
      -  "type": "array"
      -}
  3. First observed

TDQS

A4.4/5.0
Behavior4/5

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

The annotations already declare non-readonly, non-destructive, and non-open-world behavior, but the description adds useful context: it specifies the return payload (chatID, message, after cursor) and the 60-minute edit/delete window. It does not describe permission requirements, rate limits, or failure modes, so it stops short of fully rich 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 front-loaded with the core action and packs the important routing, usage, caveat, and return details into a compact paragraph. It is somewhat run-on and includes some schema-redundant detail, but the length is justified by the tool's complexity.

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 six-parameter mutation tool with no output schema, the description covers purpose, intended and excluded uses, duplicate-message caveat, and return shape. The remaining parameter details such as attachments and idempotency are fully covered by the input 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?

Schema description coverage is 100%, so the schema already documents chatID, userID, attachments, idempotencyKey, and replyMessageID in detail. The description reinforces the chat-vs-direct routing and reply-quote condition, but adds little parameter meaning beyond what the schema already 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?

The description states a specific verb and resource ('Sends a message') and distinguishes the two routing modes: chat messages vs. direct messages via userID. It also identifies the reply-quoting behavior, which separates it from sibling tools like chat_message_update and chat_message_delete.

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?

It gives explicit intended uses (blocking questions, replies to messages addressed to the token owner, user-requested messages) and explicit exclusions (status updates, summaries, links to created items). It also warns that messages newer than the last read may already contain the same question or answer.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources