Skip to main content
Glama
ProjectMakersDE

horizOn MCP Server

Official
by ProjectMakersDE
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Send Email

horizon_send_email

Queues a transactional email from a dashboard template to one registered player, sent now or scheduled through your own SMTP server for game-triggered messages.

Instructions

Queues a transactional email from a dashboard template to one registered player, sent now or at a scheduled time through the developer's own SMTP server. Use when: the game triggers a message to a player, such as a welcome mail or a reminder. Not for: checking delivery (use horizon_get_email_status) or stopping a queued email (use horizon_cancel_email). Requires: an SMTP configuration and the template in the horizOn dashboard, and a recipient with a verified email address. Side effects: queues one new email per call; repeating the call sends the email again, so never repeat it to retry a status check. Returns: {id, status: 'pending', scheduledAt}; pass id to horizon_get_email_status to follow delivery or to horizon_cancel_email to stop it. Errors: 400 for an unknown templateSlug or a recipient without a verified email address: check the slug in the dashboard or pick another user. 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
userIdYesPlayer user ID (UUID) of the recipient; the player needs a verified email address
languageYesISO 639-1 code (2 lowercase letters) of the template translation to render, for example 'en' or 'de'
variablesYesValues for the template's variables as a string map, for example {"username": "John"}; pass {} when the template has none
scheduledAtNoISO 8601 timestamp for delayed delivery, at most 30 days ahead, for example 2026-10-01T09:00:00Z. Omit to send immediately
templateSlugYesSlug of an email template defined in the dashboard, for example 'welcome' or 'reminder'

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.6.0
    • changedInput schema / properties / language / description
      Previous value: -"ISO 639-1 language code for template rendering (e.g. 'en', 'de')"New value: +"ISO 639-1 code (2 lowercase letters) of the template translation to render, for example 'en' or 'de'"
    • changedInput schema / properties / scheduledAt / description
      Previous value: -"ISO 8601 timestamp for scheduled delivery. Omit to send immediately."New value: +"ISO 8601 timestamp for delayed delivery, at most 30 days ahead, for example 2026-10-01T09:00:00Z. Omit to send immediately"
    • changedInput schema / properties / templateSlug / description
      Previous value: -"Slug of the email template (e.g. 'welcome', 'reminder')"New value: +"Slug of an email template defined in the dashboard, for example 'welcome' or 'reminder'"
    • changedInput schema / properties / userId / description
      Previous value: -"horizOn user ID of the recipient"New value: +"Player user ID (UUID) of the recipient; the player needs a verified email address"
    • changedInput schema / properties / variables / description
      Previous value: -"Template variable values as key-value pairs (e.g. {\"username\": \"John\"})"New value: +"Values for the template's variables as a string map, for example {\"username\": \"John\"}; pass {} when the template has none"
  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 cover the safety profile (readOnlyHint=false, idempotentHint=false, openWorldHint=true), and the description adds substantial context beyond them: it queues one email per call, repeating sends again (so never retry a status check), requires an SMTP config + dashboard template + verified recipient, and documents the return shape and the 400/401/429 error semantics including rate limiting.

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?

Purpose is front-loaded, followed by labeled Use when / Not for / Requires / Side effects / Returns / Errors blocks, so an agent can scan to the relevant section. It is long, but the length is justified by the non-idempotent send and multiple error modes; little of it 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?

No output schema exists, and the description compensates fully by describing the return object ({id, status, scheduledAt}), how to use the id downstream, the required credentials (HORIZON_API_KEY), and the error envelope behavior. Everything needed to call the tool correctly and interpret failures is present.

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 failure semantics tied to specific parameters: a 400 for an unknown templateSlug or a recipient without a verified email address, plus the instruction to check the slug in the dashboard or pick another user. That is genuine meaning beyond the schema field docs, though most syntax still lives in the schema.

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 verb+resource+scope: 'Queues a transactional email from a dashboard template to one registered player, sent now or at a scheduled time through the developer's own SMTP server.' It also distinguishes itself from siblings by name (horizon_get_email_status, horizon_cancel_email), so an agent can route correctly 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?

Explicit 'Use when' (game triggers a message to a player) and 'Not for' clauses that name the two alternative tools for delivery checking and cancellation. When-to-use, when-not-to-use, and alternatives are all stated rather than inferred.

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