Google Workspace MCP Server - Control Gmail, Calendar, Docs, Sheets, Slides, Chat, Forms & Drive

Send Message

send_message

Destructive

Send or edit messages in Google Chat spaces. Post new messages, reply in threads, or update your existing messages using thread keys, resource names, or message identifiers.

Instructions

Sends a message to a Google Chat space, or edits a message already sent there.

Input Schema

TableJSON Schema

Name	Required	Description
`space_id`	Yes
`thread_key`	No	Reply in a thread by app-defined key (creates thread if not found).
`thread_name`	No	Reply in an existing thread by its resource name (e.g. spaces/X/threads/Y).
`message_name`	No	Edit this message in place instead of sending a new one (e.g. spaces/X/messages/Y, as returned by send_message or get_messages). Must be a message of space_id. Only the text is replaced, and only the author can edit their own message.
`message_text`	Yes
`user_google_email`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv1.28.0Sep 24, 2026
- removedInput schema / properties / message_name / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedInput schema / properties / message_name / type
```
Added value: +"string"
```
- removedInput schema / properties / thread_key / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedInput schema / properties / thread_key / type
```
Added value: +"string"
```
- removedInput schema / properties / thread_name / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedInput schema / properties / thread_name / type
```
Added value: +"string"
```

Changed1 schema field changedv1.26.0Sep 6, 2026

addedInput schema / properties / message_name

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Edit this message in place instead of sending a new one\n(e.g. spaces/X/messages/Y, as returned by send_message or get_messages).\nMust be a message of space_id. Only the text is replaced, and only the\nauthor can edit their own message."
+}

Changed11 schema fields changedv1.0.1Jul 31, 2026

addedInput schema / additionalProperties
```
Added value: +false
```
removedInput schema / properties / message_text / title
```
Removed value: -"Message Text"
```

removedInput schema / properties / service

Removed value: -{
-  "title": "service",
-  "type": "string"
-}

removedInput schema / properties / space_id / title
```
Removed value: -"Space Id"
```

addedInput schema / properties / thread_key / description

Added value: +"Reply in a thread by app-defined key (creates thread if not found)."

removedInput schema / properties / thread_key / title
```
Removed value: -"Thread Key"
```

addedInput schema / properties / thread_name

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Reply in an existing thread by its resource name (e.g. spaces/X/threads/Y)."
+}

removedInput schema / properties / user_google_email / title
```
Removed value: -"User Google Email"
```

changedInput schema / required

Previous value: -[
-  "service",
-  "user_google_email",
-  "space_id",
-  "message_text"
-]New value: +[
+  "user_google_email",
+  "space_id",
+  "message_text"
+]

removedInput schema / title
```
Removed value: -"send_messageArguments"
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "type": "object",
+  "x-fastmcp-wrap-result": true
+}

First observedv1.0.0Jun 10, 2025

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation behavior is known. The description adds the dual send/edit behavior but does not disclose auth needs, rate limits, or consequences beyond the edit operation. It does not contradict the annotations.

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?

The description is a single 15-word sentence with the action verb front-loaded. It covers both send and edit modes with no filler or redundant detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/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 only 50% schema coverage, the description leaves important semantics to inference—especially user_google_email and how the edit mode is triggered via message_name. The output schema and annotations help, but the description alone is not fully self-sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 50%, with required parameters space_id, message_text, and user_google_email left undocumented. The description only loosely implies space_id and message_text via 'Sends a message to a Google Chat space' and says nothing about user_google_email or message_name, failing to compensate for the schema gap.

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 to a Google Chat space, or edits a message already sent there.' It clearly separates this tool from sibling readers like get_messages/search_messages and from Gmail's send_gmail_message, since it explicitly scopes to Google Chat.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when the tool should be used (sending or editing Chat messages) but does not explicitly name alternatives or state when not to use it. An agent must infer the contrast with sibling read/search tools from the wording rather than receiving direct guidance.

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

Deploy Server