Skip to main content
Glama
ProjectMakersDE

horizOn MCP Server

Official
by ProjectMakersDE
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Remove Inbox Entry

horizon_remove_inbox
DestructiveIdempotent

Removes an eligible inbox entry for the authenticated player after an explicit action and returns the updated inbox snapshot; unclaimed rewards must be claimed before removal.

Instructions

Removes an eligible inbox entry for the authenticated player. Use when: an explicit player action on an entry returned by horizon_get_inbox. Not for: changing the recipient or inventing attachment amounts. Requires: userId and the player's session: sign in with horizon_signin_email or horizon_signin_anonymous and pass its accessToken as sessionToken. Side effects: Removes ordinary or already-claimed entries. Unclaimed valuable attachments are protected. Removal does not create a new claim opportunity. Returns: Updated complete inbox snapshot. Errors: 409 STATE_CONFLICT: retry the same entry ID. UNCLAIMED_REWARD: claim before removal. MAX_BALANCE_REACHED/DAILY_LIMIT_REACHED/INVENTORY_FULL leaves the reward or original item unclaimed. ENTRY_NOT_FOUND after removal/cleanup never grants again. 401 means the session is missing or expired: sign in again and retry with the new accessToken. 403 for a session means the token belongs to another user: pass the userId that signed in. 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

NameRequiredDescriptionDefault
userIdYesPlayer UUID belonging to the selected project and player session
entryIdYesExact stable entry ID from the inbox snapshot, including message: or broadcast: prefix
sessionTokenYesPlayer accessToken, sent only as Authorization Bearer

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.9.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover destructive/idempotent/openWorld, but the description adds real context: protected unclaimed valuable attachments, no new claim opportunity, 409 retry semantics, and per-error recovery paths (401 re-sign-in, 403 userId mismatch, HORIZON_API_KEY dependency, 429 rate limit).

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?

Labeled sections (Use when / Not for / Requires / Side effects / Returns / Errors) keep it front-loaded and scannable, but the error paragraph is dense and the 401 explanation is stated twice, which is redundant.

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?

For a destructive mutation with no output schema, the description supplies the return value ('updated complete inbox snapshot'), auth prerequisites, failure taxonomy, and side-effect boundaries — nothing essential is missing.

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 derivation rules beyond the schema: sessionToken must come from horizon_signin_email/horizon_signin_anonymous, and userId must be the one that signed in (403 otherwise); entryId retry only with the same ID.

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 and resource ('Removes an eligible inbox entry') scoped to the authenticated player, and the 'eligible' qualifier plus the 'Not for' clause separate it from horizon_claim_inbox, horizon_mark_inbox_read and horizon_get_inbox.

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' (an explicit player action on an entry returned by horizon_get_inbox) and 'Not for' exclusions (changing recipient, inventing attachment amounts), and the UNCLAIMED_REWARD error routes the agent to horizon_claim_inbox first.

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