Skip to main content
Glama
Sign In
mcp-hey

mcp-hey

by Sealjay
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

hey_screen_by_id

DestructiveIdempotent

Approve or reject first-time senders from Hey.com's Screener using a clearance ID, directing approved emails to inbox, feed, or paper trail.

Instructions

Approve or reject a first-time sender from the Screener by clearance ID. Approve: allows future emails from this sender into the chosen destination (defaults to imbox). Reject: blocks future emails from this sender via the screener. Reversible from the Hey UI's contact page (not yet via MCP). Returns {success, error?}. Use hey_list_screener to get clearance IDs; for senders that have already left the screener, use hey_screen by email instead.

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": {
      "clearance_id": "<clearance_id>",
      "action": "<action>"
    },
    "name": "hey_screen_by_id"
  }
}

Input Schema

NameRequiredDescriptionDefault
actionYesapprove routes to `destination`; reject blocks future emails and does not flag as spam.
destinationNoWhere future emails from this sender land when approved: imbox (default, important mail), feed (newsletters/updates), paper_trail (receipts/automated). Ignored when action is reject.
clearance_idYesThe clearance ID from hey_list_screener

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.5.0
    • changedInput schema / properties / action / description
      Previous value: -"approve: allow this sender's emails through (routed to `destination`). reject: block future emails from this sender. Does not flag as spam."New value: +"approve routes to `destination`; reject blocks future emails and does not flag as spam."
  2. Addedv0.4.1

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the annotations (destructiveHint, idempotentHint) by spelling out the downstream effect of each action on future mail flow, the default destination, and the reversibility constraint ('reversible from the Hey UI's contact page, not yet via MCP'). It even discloses the return shape '{success, error?}' in the absence of an output schema.

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-loads the action and resource, then branches cleanly into Approve/Reject effects, a reversibility note, the return contract, and sibling routing. Every sentence carries information; none is filler.

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?

With no output schema, the description supplies the return contract, both action semantics, the destination default, reversibility limits, and sibling navigation. An agent has everything needed to invoke this destructive, idempotent tool correctly.

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 coverage is 100% and the schema already documents the destination default (imbox) and enum meanings, so the description largely restates what is structured. It adds only light value by tying destination to the approve branch and clarifying it is ignored on reject.

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?

States a specific compound action (approve/reject) on a precise resource (first-time sender in the Screener) keyed by clearance ID. It is immediately distinguishable from hey_list_screener and hey_screen by the ID-vs-email keying, which the description itself calls out.

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?

Explicitly routes the agent: 'Use hey_list_screener to get clearance IDs' and 'for senders that have already left the screener, use hey_screen by email instead.' Both the prerequisite and the exclusion condition that selects a sibling are named.

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