Skip to main content
Glama
Sign In
mcp-hey

mcp-hey

by Sealjay
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

hey_list_collection_emails

Read-only

List emails in a specified Hey.com collection with pagination; cached results return by default, or set force_refresh to fetch fresh data.

Instructions

List emails in a specific collection. Returns cached results unless force_refresh=true.

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": {
      "collection_id": "<collection_id>"
    },
    "name": "hey_list_collection_emails"
  }
}

Input Schema

NameRequiredDescriptionDefault
pageNoPage number for pagination, 1-1000 (default: 1)
limitNoMaximum number of emails to return, 1-100 (default: 25)
collection_idYesThe collection ID to list emails from (use id from hey_list_collections)
force_refreshNoBypass cache and fetch fresh data (default: false)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.5.0
    • changedInput schema / properties / collection_id / description
      Previous value: -"The collection ID to list emails from"New value: +"The collection ID to list emails from (use id from hey_list_collections)"
    • changedInput schema / properties / limit / description
      Previous value: -"Maximum number of emails to return (default: 25)"New value: +"Maximum number of emails to return, 1-100 (default: 25)"
    • changedInput schema / properties / page / description
      Previous value: -"Page number for pagination (default: 1)"New value: +"Page number for pagination, 1-1000 (default: 1)"
  2. First observedv0.1.0

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds real behavioral value by disclosing the caching behavior ('Returns cached results unless force_refresh=true'), which the annotations do not convey. It stops short of stating auth needs, rate limits, or return shape, but this is useful added context.

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?

Two tight sentences with zero filler; the primary purpose is front-loaded and the caching caveat follows. Every clause earns its place.

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?

For a simple read-only, collection-scoped list tool with full schema coverage and safety annotations, the description covers purpose and the one non-obvious behavior (caching). Pagination and return format are handled by the schema, so little is missing, though it could note the collection_id dependency more explicitly.

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 all four parameters (page, limit, collection_id, force_refresh) are already documented in the schema, including defaults and ranges. The description only restates the force_refresh semantics already present in the schema, adding no new parameter meaning beyond the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List emails in a specific collection'), which clearly identifies the operation. It separates itself from plain list_email indirectly via the 'collection' scope, but never names a sibling collection-vs-label distinction, so it falls short of full sibling differentiation.

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 explicit when-to-use guidance, no prerequisites, and no mention of alternatives such as hey_list_emails or hey_list_label_emails. The scoping is inferable from the tool name but the description offers no routing help.

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