Skip to main content
Glama
Sealjay

mcp-hey

by Sealjay
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

hey_reply

Reply to an existing email thread while preserving threading, excluding your address by default and allowing recipient overrides for targeted replies.

Instructions

Reply to an email thread, preserving threading on both ends. Returns {success, error?}. By default the reply goes to the other thread participants (your own address is automatically excluded); pass to to redirect to specific recipients — e.g. chasing your own thread without looping back to yourself, or redirecting off a mailing-list address. Prefer this over hey_send_email when responding to an existing thread; use hey_send_email only for new conversations.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ccNoOptional CC override. Only honoured when `to` is also provided.
toNoOptional override of the To: line. Replaces the auto-detected participants. Use to: (a) chase your own thread without looping back to yourself, (b) redirect a mailing-list reply to a specific person, or (c) generally target the reply at recipients other than the thread defaults.
bodyYesReply body content (HTML supported)
thread_idYesThe thread/topic ID to reply to

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.4.1
    • changedInput schema / properties / to / description
      Previous value: -"Optional override of the To: line. Use this when chasing a thread where you sent the most recent message, so the chase lands on the original recipient instead of looping back to your own address."New value: +"Optional override of the To: line. Replaces the auto-detected participants. Use to: (a) chase your own thread without looping back to yourself, (b) redirect a mailing-list reply to a specific person, or (c) generally target the reply at recipients other than the thread defaults."
  2. First observedv0.1.0

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare non-readOnly, non-idempotent, non-destructive, open-world. The description adds real value beyond them: the return shape ({success, error?}), the default recipient behavior (own address auto-excluded), and threading preservation. It doesn't mention auth needs or rate limits, but for this tool those are minor.

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?

Front-loaded with purpose and return shape, then recipient defaults, then override cases, then sibling routing. Every sentence earns its place and nothing is repeated verbatim from the schema without purpose.

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?

No output schema exists, and the description compensates by stating the return shape. Combined with the recipient-default and threading notes, an agent has everything needed to invoke this correctly.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema lacks: the default recipient set and the automatic exclusion of your own address, which explains why `to` exists at all. The detailed `to`/`cc` mechanics are largely mirrored from the schema, capping it below 5.

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?

Specific verb+resource ('Reply to an email thread') with a stated distinguishing trait ('preserving threading on both ends'). It explicitly names the sibling it is not (hey_send_email) and the condition that differentiates them, so an agent can disambiguate without opening any schema.

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?

Gives explicit routing guidance: 'Prefer this over hey_send_email when responding to an existing thread; use hey_send_email only for new conversations.' It also explains when to reach for the `to` override (chasing your own thread, redirecting off a mailing list).

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