Sliq

Draft reply

draft_reply

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": {
      "email_id": "<email_id>",
      "body": "<body>"
    },
    "name": "draft_reply"
  }
}

Input Schema

Name	Required	Description
`cc`	No	Optional list of additional CC recipients. Each is an object with required "email" and optional "name". Example: [{"email": "bob@acme.com"}]
`bcc`	No	Optional list of BCC recipients, same format as "cc".
`body`	Yes	Reply body in Markdown, rendered to HTML at send time — same rules as draft_email: hyperlinks as [text](url), single newlines preserved as line breaks.
`email_id`	Yes	The database id of the email to reply to (from search_emails results)
`reply_all`	No	If true, reply to all original recipients (Reply All). Default: false (reply to sender only).
`on_behalf_of`	No	A teammate's email, or an agency client's from list_agency_clients, to run this call in that account: their agents, settings, connected accounts, and credits. Omit it to act on your own account.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 6, 2026

changedInput schema / properties / on_behalf_of / description

Previous value: -"A teammate's email (one with team actions turned on), or an agency client's from list_agency_clients, to run this call in that account: their agents, settings, connected accounts, and credits. Omit it to act on your own account."New value: +"A teammate's email, or an agency client's from list_agency_clients, to run this call in that account: their agents, settings, connected accounts, and credits. Omit it to act on your own account."

Changed2 schema fields changedOct 21, 2026

changedInput schema / properties / bcc / anyOf

Previous value: -[
-  {
-    "items": {
-      "description": "An email/calendar recipient. `name` is optional — both Gmail and Outlook\nbackends fall back to empty string when omitted, so the model can pass just\n`{\"email\": \"alice@acme.com\"}` if it doesn't have a display name handy.\nKeeping `name` required at the schema layer caused agents to burn tool\nretries guessing the right shape (SLI-12622).",
-      "properties": {
-        "email": {
-          "type": "string"
-        },
-        "name": {
-          "type": "string"
-        }
-      },
-      "required": [
-        "email"
-      ],
-      "title": "Recipient",
-      "type": "object"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "items": {
+      "description": "An email/calendar recipient. `name` is optional — both Gmail and Outlook\nbackends fall back to empty string when omitted, so the model can pass just\n`{\"email\": \"alice@acme.com\"}` if it doesn't have a display name handy.\nKeeping `name` required at the schema layer caused agents to burn tool\nretries guessing the right shape (SLI-12622).",
+      "properties": {
+        "email": {
+          "type": "string"
+        },
+        "name": {
+          "default": "",
+          "type": "string"
+        }
+      },
+      "required": [
+        "email"
+      ],
+      "title": "Recipient",
+      "type": "object"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / cc / anyOf

Previous value: -[
-  {
-    "items": {
-      "description": "An email/calendar recipient. `name` is optional — both Gmail and Outlook\nbackends fall back to empty string when omitted, so the model can pass just\n`{\"email\": \"alice@acme.com\"}` if it doesn't have a display name handy.\nKeeping `name` required at the schema layer caused agents to burn tool\nretries guessing the right shape (SLI-12622).",
-      "properties": {
-        "email": {
-          "type": "string"
-        },
-        "name": {
-          "type": "string"
-        }
-      },
-      "required": [
-        "email"
-      ],
-      "title": "Recipient",
-      "type": "object"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "items": {
+      "description": "An email/calendar recipient. `name` is optional — both Gmail and Outlook\nbackends fall back to empty string when omitted, so the model can pass just\n`{\"email\": \"alice@acme.com\"}` if it doesn't have a display name handy.\nKeeping `name` required at the schema layer caused agents to burn tool\nretries guessing the right shape (SLI-12622).",
+      "properties": {
+        "email": {
+          "type": "string"
+        },
+        "name": {
+          "default": "",
+          "type": "string"
+        }
+      },
+      "required": [
+        "email"
+      ],
+      "title": "Recipient",
+      "type": "object"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

Changed1 schema field changedOct 20, 2026

changedInput schema / properties / on_behalf_of / description

Previous value: -"Draft the reply on a consented teammate's behalf — pass their\nemail. The draft is created in their mailbox; pass the same teammate to\nsend_email to send it. Gated on that teammate's act-on-behalf setting\n(stricter than conversation sharing); a teammate who hasn't granted it is\nrejected. Omit to draft from your own account.\nOr pass an agency client's email, from list_agency_clients, to run the call in that client's account, where none of the teammate limits above apply."New value: +"A teammate's email (one with team actions turned on), or an agency client's from list_agency_clients, to run this call in that account: their agents, settings, connected accounts, and credits. Omit it to act on your own account."

Changed2 schema fields changedOct 19, 2026

removedInput schema / properties / as_teammate

Removed value: -{
-  "anyOf": [
-    {
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "description": "Draft the reply on a consented teammate's behalf — pass their\nemail. The draft is created in their mailbox; pass the same teammate to\nsend_email to send it. Gated on that teammate's act-on-behalf setting\n(stricter than conversation sharing); a teammate who hasn't granted it is\nrejected. Omit to draft from your own account."
-}

addedInput schema / properties / on_behalf_of

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Draft the reply on a consented teammate's behalf — pass their\nemail. The draft is created in their mailbox; pass the same teammate to\nsend_email to send it. Gated on that teammate's act-on-behalf setting\n(stricter than conversation sharing); a teammate who hasn't granted it is\nrejected. Omit to draft from your own account.\nOr pass an agency client's email, from list_agency_clients, to run the call in that client's account, where none of the teammate limits above apply."
+}

First observedSep 15, 2026

TDQS

A4.3/5.0

Behavior4/5

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

The annotations only declare readOnlyHint=false and destructiveHint=false, so the description has to explain the effect, and it does: a draft is created rather than a message sent, and the user must confirm before send_email runs. It also documents the response shape. What it doesn't cover is permission/account requirements or whether an existing draft on the thread gets overwritten, which keeps it 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The summary is front-loaded with the core action, then workflow, then a returns block, and every line carries information. The XML-style summary/returns wrapping is slightly heavier than plain prose but not wasteful.

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?

With no output schema, the explicit returns block (success, draft_id, provider, original email context) fills a real gap. Combined with the search-then-draft-then-confirm workflow, an agent has what it needs; only account/permission behavior for on_behalf_of goes unaddressed.

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 cc, bcc, body, reply_all and on_behalf_of are already documented in the schema and the description adds little there. The one added piece of meaning is the provenance of email_id ("from search_emails results"), which is useful but modest against a fully documented schema.

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 gives a specific verb and resource ("Create a reply draft to an existing email thread") and names the supported providers (Outlook or Gmail). Saying "reply ... to an existing email thread" cleanly separates it from the sibling draft_email, which creates a fresh draft rather than a threaded reply.

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 spells out the prerequisite step ("Use search_emails first to find the email to reply to, then pass its id here") and the downstream guardrail ("ALWAYS present the draft to the user and ask for confirmation before calling send_email"). The when-to-use path and the boundary against send_email are both explicit, leaving nothing to infer.

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

All Sliq tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?