Skip to main content
Glama
Alpha4-Labs

Loyalteez MCP Server

by Alpha4-Labs

loyalteez_admin_reward

Manually reward users for special contributions by triggering a reward event with admin audit context, optional amount override, and reason.

Instructions

Manually reward users (mod/admin triggered). Wrapper around track_event with admin context. Use this when admins want to manually reward users for special contributions.

See also: loyalteez://docs/api/rest-api

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
amountNoOverride configured reward amount (optional)
reasonNoReason for manual reward (for logging)
adminIdNoAdmin's platform ID (for audit trail)
brandIdNoYour brand wallet address. If not provided, uses LOYALTEEZ_BRAND_ID environment variable.
platformYesPlatform: "discord" | "telegram" | "web" | etc.
eventTypeYesEvent type to trigger (e.g., "helpful_answer", "special_contribution")
targetUserIdYesTarget user identifier (platform_userId or email)
publicMessageNoWhether to send public notification (default: false)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A3.6/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It does disclose that this is a wrapper around track_event with admin context and that an audit trail exists, but it omits whether the reward is irreversible, what permissions are required, and any rate/duplication constraints — meaningful gaps for a mutation tool.

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?

Three short sentences, front-loaded with the core action and the wrapper detail, with a docs reference at the end. Every sentence earns its place, though the 'See also' pointer is of marginal value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-parameter mutation tool with no annotations and no output schema, the description covers purpose and admin context but leaves the return behavior, side effects, and the relationship to the sibling track_event largely unexplained. Adequate but with clear gaps.

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 the schema already documents all 8 parameters (amount override, reason, adminId, brandId fallback, etc.). The description adds no syntax, format, or fallback detail beyond that, so the baseline of 3 applies.

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+resource ('Manually reward users') and immediately distinguishes itself from siblings by describing itself as an admin-context 'Wrapper around track_event'. An agent can tell it apart from loyalteez_track_event and loyalteez_log_activity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit context: 'Use this when admins want to manually reward users for special contributions.' The wrapper framing implies the alternative (tracking an event directly) but never states when NOT to use this versus loyalteez_track_event, so it stops short of the 5-level routing clarity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.