Skip to main content
Glama
adamVass

pylos-mcp

by adamVass
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

create_draft

Save an email draft to the Drafts folder without sending it, so recipients can be reviewed and corrected before manual sending. Supports replies via in_reply_to.

Instructions

Save a draft to the Drafts folder. The result echoes the full recipient list so it can be checked. The draft is saved, never sent: it waits in the Drafts folder for the account owner to read it, correct the recipients and send it themselves. To reply, pass in_reply_to with the original's folder and uid. A subject starting with "Re:" does not thread on its own. Set quote_original to add the original below the reply as a quote, allowed only when every recipient was on the original.

Input Schema

NameRequiredDescriptionDefault
ccNo
toNo
bodyYes
subjectYes
attachmentsNoAttachments are taken from messages already in the mailbox, by folder, uid and part id.
in_reply_toNo
quote_originalNoAdd the original below the body as a quote. Needs in_reply_to.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.2.0
    • addedInput schema / properties / in_reply_to
      Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "folder": {
+      "description": "Folder of the message being answered.",
+      "minLength": 1,
+      "type": "string"
+    },
+    "uid": {
+      "description": "Uid of the message being answered.",
+      "exclusiveMinimum": 0,
+      "type": "integer"
+    }
+  },
+  "required": [
+    "folder",
+    "uid"
+  ],
+  "type": "object"
+}
    • addedInput schema / properties / quote_original
      Added value: +{
+  "description": "Add the original below the body as a quote. Needs in_reply_to.",
+  "type": "boolean"
+}
  2. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly=false, destructive=false, idempotent=false, openWorld=false), yet the description adds real behavioral context beyond them: the result echoes the full recipient list for verification, the message is guaranteed not to be sent, and threading is not triggered by a 'Re:' subject alone. It does not discuss rate limits, auth requirements, or recipient/attachment caps.

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 core guarantee ('saved, never sent') is front-loaded before the threading details, and each sentence adds distinct information. It is somewhat long at five sentences, and the reply-threading material could be tightened, but nothing is wasted.

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, describing the echoed recipient list is valuable, and the subtle reply/quote rules are covered. The description omits the recipient and attachment limits (max 50, max 10) that exist in the schema and says nothing about where the created draft is identified on return, so it is not fully complete for a 7-parameter mutation.

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 only 29%, so the description must carry weight, and it does add meaning for in_reply_to (threading semantics), quote_original ('allowed only when every recipient was on the original'), and the recipient list. However, to, cc, body, and subject carry no added semantics beyond their names, leaving the low-coverage gap only partially compensated.

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 first sentence states a specific verb and destination ('Save a draft to the Drafts folder'), and the description immediately distinguishes the operation from sending, making it unmistakable relative to read-only siblings like get_email or list_folders. An agent can identify the action without opening the schema.

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

Usage Guidelines4/5

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

It clearly frames when this is the right tool: the message is never sent and waits for the account owner to correct and send it. It also gives conditional guidance for the reply path ('To reply, pass in_reply_to...') and the quote_original precondition. It does not name a sibling or an alternative action (e.g., a send tool), so it stops short of explicit when-not guidance.

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