Skip to main content
Glama
ProjectMakersDE

horizOn MCP Server

Official
by ProjectMakersDE
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Get Marketplace Price Rules

horizon_get_marketplace_rules
Read-onlyIdempotent

Reads a revision-consistent, bounded page of marketplace rules for explicit marketplace actions, preserving catalogRevision and cursor for subsequent pages.

Instructions

Reads one revision-consistent bounded rule page. Use when: explicit marketplace actions after reading horizon://docs/marketplace. Not for: automatic trading, price polling or generated replacement operations. Use horizon_get_marketplace_operation to reconcile the original intent. 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: Read only. Preserve catalogRevision and after for explicit subsequent pages. Returns: {revision,rules,nextCursor,serverTime} Errors: 409 conflicts require explicit reconciliation, never fresh revisions or operation IDs on an unknown outcome. Missing OPERATION_NOT_FOUND does not prove nonexecution. 422 capacity/balance/daily-limit errors preserve atomicity. 429 schedules no retry. Full Inbox returns pending without losing the original item. 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
afterNoOriginal last item key from the preceding rule page
limitNoOne explicit bounded page, never automatic traversal
userIdYesActive player matching the current session and project
sessionTokenYesCurrent accessToken sent only as Bearer
catalogRevisionNoOriginal rule catalog revision across pages

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.9.1

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations, it discloses prerequisites (sign-in and accessToken), pagination invariants (`catalogRevision` and `after`), return shape, and detailed error semantics including 401/403 authentication cases, 409 reconciliation behavior, 429 rate limiting, and API-key requirements. These are substantial behavioral details not covered by the read-only/idempotent annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded and uses clear labeled sections, but it is noticeably overlong and includes at least one unrelated error case: 'Full Inbox returns pending without losing the original item' has no apparent relevance to marketplace rule pagination. The useful content is present, but it is diluted by boilerplate and extraneous error details.

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?

Given the read-only annotations, 100% schema coverage, and lack of an output schema, the description supplies the missing operational context: auth flow, pagination rules, return shape, rate-limit behavior, and error conditions. An agent has enough information to call the tool and interpret failures correctly.

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 schema already documents all five parameters. The description adds useful context about how `catalogRevision` and `after` preserve revision-consistent pagination and how `userId`/`sessionToken` tie to the player session, though it does not need to restate every parameter's format.

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?

The description states a specific verb and resource: 'Reads one revision-consistent bounded rule page.' It also scopes the operation as explicit, bounded pagination and distinguishes it from `horizon_get_marketplace_operation` for reconciliation, so an agent can identify when this tool is the right choice.

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?

It gives explicit usage guidance: use after reading `horizon://docs/marketplace` for explicit marketplace actions; not for automatic trading, price polling, or generated replacement operations. It names the alternative `horizon_get_marketplace_operation` and the condition under which that alternative should be used.

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