Skip to main content
Glama
RPasquale

lightbulb-mcp

by RPasquale
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

gmail_send_email

DestructiveIdempotent

Send an email from a connected Gmail account, supporting plain text or HTML bodies and replies within existing threads for organized conversations.

Instructions

Send an email from the connected Gmail account.

Args: to (required): Exactly one recipient address. subject (required): body (required): Plain-text or HTML body. html: If true, body is treated as HTML. thread_id: Exact Gmail thread ID for an in-thread reply. parent_message_id: Exact RFC Message-ID parent; required with thread_id. project_id: Authenticated Project UUID. project_ref: Exact project correlation reference. connector_account_ref: Project-bound connector account alias. idempotency_key: Stable business-action identity. effect: Claimed read or write effect; Spring verifies it. approval_ref: Approved platform task UUID when resuming a write.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNo
bodyNo
htmlNo
effectNo
subjectNo
thread_idNo
project_idNo
project_refNo
approval_refNo
idempotency_keyNo
parent_message_idNo
connector_account_refNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changedv0.1.1
    • addedInput schema / properties / approval_ref
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Approval Ref"
+}
    • removedInput schema / properties / cc
      Removed value: -{
-  "anyOf": [
-    {
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "title": "Cc"
-}
    • addedInput schema / properties / connector_account_ref
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Connector Account Ref"
+}
    • addedInput schema / properties / effect
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Effect"
+}
    • addedInput schema / properties / idempotency_key
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Idempotency Key"
+}
    • addedInput schema / properties / parent_message_id
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Parent Message Id"
+}
    • addedInput schema / properties / project_id
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Project Id"
+}
    • addedInput schema / properties / project_ref
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Project Ref"
+}
    • addedInput schema / properties / thread_id
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Thread Id"
+}
  2. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already mark this as non-read-only, idempotent, and destructive; the description adds useful context by explaining that effect is verified by Spring, that approval_ref is needed when resuming a write, and how thread_id/parent_message_id work for replies. It does not contradict the annotations, though it doesn't discuss irreversibility or recipient-visible side effects.

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 compact: one clear purpose sentence followed by a flat parameter list. It front-loads the core function and avoids fluff, though the empty 'subject (required):' line adds no value and could be removed or completed.

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?

Given the tool's 12 parameters and platform-specific concepts, the description documents parameter semantics well but omits important usage context: when to supply effect, idempotency_key, project_ref, or approval_ref, and how this tool relates to sibling send tools. The output schema covers return values, so that absence is acceptable.

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?

With 0% schema description coverage, the description carries the full parameter-documentation burden and mostly succeeds: it explains that 'to' requires exactly one recipient, body can be plain-text or HTML, thread_id is for in-thread replies, and idempotency_key is a stable business-action identity. However, the subject entry has an empty description and the exact accepted values for effect and approval_ref remain vague.

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 opens with a specific verb and resource: 'Send an email from the connected Gmail account.' This clearly indicates the action and distinguishes it from read/modification Gmail siblings like gmail_get_email or gmail_modify, and from non-Gmail senders like microsoft_send_email.

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

Usage Guidelines2/5

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

There is no guidance about when to use this tool instead of alternatives such as gmail_modify, business_write_email, or microsoft_send_email. The description only documents parameter-level constraints (e.g., parent_message_id required with thread_id) rather than tool-selection conditions or exclusions.

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

Deploy Server

Other Tools