Skip to main content
Glama

Kosmodrom

by ai.kosmodrom
OverviewDiscussionsAdmin

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 makes it a reply. 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.

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
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 the message in this chat to reply to

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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"
-}
  2. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnly=false and destructive=false. The description goes beyond them by disclosing the return payload (chatID, message, after cursor) and that the sent message can be edited or deleted within 60 minutes, plus the duplicate-risk caveat around the after cursor. It does not state permission requirements or rate limits, so it stops short of a 5.

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?

Five dense sentences with zero filler: addressing modes first, then when-to-use and when-not, then the dedup caveat, then the return value and edit window. Front-loaded and each sentence carries distinct information.

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?

With no output schema, the description supplies the return shape itself. Combined with addressing semantics, usage boundaries, dedup guidance and the edit/delete window, an agent has everything needed to invoke this correctly against siblings like chat_read or chat_message_update.

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 every parameter including text formatting rules, attachment limits and idempotencyKey is already documented. The description restates chatID/userID/replyMessageID semantics, which largely duplicates the schema rather than adding new meaning, so the 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?

States a specific verb (sends) and resource (message) and immediately distinguishes the three addressing modes: chatID for a chat (task chat ID = task ID), userID for a DM, replyMessageID for a reply. An agent can tell exactly what this does and how it differs from chat_read, chat_reaction and chat_message_update.

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 names the intended cases (blocking questions, replies to messages addressed to the token owner, messages the user asks for) and the excluded cases (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, which steers the agent to check chat_read before sending.

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

All Kosmodrom toolsInspect
Try in Browser
Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources