Skip to main content
Glama
ProjectMakersDE

horizOn MCP Server

Official
by ProjectMakersDE
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Cancel Email

horizon_cancel_email
DestructiveIdempotent

Cancel a queued email before delivery by supplying its email ID, stopping scheduled or pending messages so they are never sent.

Instructions

Cancels a queued email that is still pending (sent now or scheduled) so it is never delivered. Use when: a scheduled email is no longer wanted, for example the player already came back. Not for: emails that are already processing or sent (they cannot be recalled); check with horizon_get_email_status first when unsure. Requires: the emailId from horizon_send_email, sent with the same API key. Side effects: the email is never sent and cannot be restored; to send it later, call horizon_send_email again. Returns: {message: 'Email cancelled'}. Errors: An email that is not pending (already processing, sent, failed or cancelled) or belongs to another API key is rejected: read its state with horizon_get_email_status. Needs HORIZON_API_KEY. Every failure returns an error result (isError) with the HTTP status and body: a 401 that horizon_test_connection also returns means HORIZON_API_KEY is wrong, 429 means the account's per-minute rate limit was reached (wait a minute, then retry).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
emailIdYesEmail ID (UUID) returned by horizon_send_email

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.6.0
    • changedInput schema / properties / emailId / description
      Previous value: -"ID of the email to cancel (returned by send_email)"New value: +"Email ID (UUID) returned by horizon_send_email"
  2. First observedv1.5.4

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds substantial value beyond them: irreversibility ('cannot be restored'), the same-API-key constraint, required HORIZON_API_KEY, error semantics (isError with HTTP status/body), and specific 401/429 meanings including rate limiting. This is rich behavioral context layered on top of the structured hints.

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?

Well front-loaded with a labeled Use when / Not for / Requires / Side effects / Returns / Errors structure that scans cleanly. Slightly verbose: horizon_get_email_status and HORIZON_API_KEY are each referenced twice, and the error paragraph is dense, costing some tightness.

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 value ({message: 'Email cancelled'}), error behavior, prerequisites, and side effects. An agent has everything needed to call it correctly and interpret results.

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% and documents emailId, so the baseline is 3. The description adds useful provenance — the emailId comes from horizon_send_email and must be sent with the same API key — which meaningfully constrains correct invocation beyond the schema text.

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 precise verb and resource ('cancels a queued email') plus the crucial scope qualifier ('still pending... so it is never delivered'). This clearly distinguishes it from horizon_send_email and horizon_get_email_status among the large sibling set.

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?

Explicit 'Use when' (scheduled email no longer wanted), 'Not for' (already processing/sent, cannot be recalled), and a named alternative ('check with horizon_get_email_status first when unsure'). The when/when-not routing is fully spelled out.

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