Skip to main content
Glama

Loyal Spark

by io.github.aspekt19
OverviewDiscussionsAdmin

create_loyalty_program

Get factory calldata to deploy a new loyalty token on Base. Defaults to B20 (Base-native B20 asset standard, ERC-20 compatible, single tx, active immediately). Pass token_standard='erc20' for the legacy factory. For B20, MINT_ROLE is granted atomically to the merchant admin AND to the agent's CDP wallet (or explicit extra_minters) so autonomous agents can mint with no follow-up transaction.

Input Schema

NameRequiredDescriptionDefault
nameYesProgram name (required for external agents)
localeNo
symbolYesToken symbol, 2-5 chars (required for external agents)
auto_generateNoInternal automation only — fills missing name/symbol from examples. External agents should pass explicit name and symbol.
extra_mintersNo(B20 only) Extra addresses to grant MINT_ROLE atomically in the same deploy tx.
token_standardNo'b20' (default, single-tx deploy on Base precompile factory) or 'erc20' (legacy factory, requires activate_loyalty_program follow-up)
expiration_daysNoProgram duration in days (default: 365)
preferred_styleNo
target_audienceNo
business_contextNoOptional context for examples only
agent_wallet_addressNo(B20 only) Additional wallet to grant MINT_ROLE atomically. Defaults to the agent's active CDP MPC wallet if not provided.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / required
      Added value: +[
+  "name",
+  "symbol"
+]
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

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

While annotations provide basic status, the description adds critical behavioral context regarding the atomic granting of MINT_ROLE to the CDP wallet and explicit extra_minters. This is vital knowledge for an agent performing autonomous deployment.

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

Conciseness5/5

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

The description is extremely dense with relevant information, front-loading the core purpose and immediately detailing the critical behavioral defaults.

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

Completeness4/5

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

Given the complexity of deploying standards (B20 vs ERC20) and managing multi-party permissions, the description is very comprehensive in detailing the core technical constraints of the operation.

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?

Although schema coverage is 73%, the description clarifies the operational meaning of key fields like token_standard and the role of extra_minters (atomic minting), providing semantic value beyond what the structure alone offers.

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 is highly specific, clearly stating the tool deploys a new loyalty token on Base via factory calldata. It differentiates its behavior from standard protocols by highlighting the B20 asset standard and atomic role granting.

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?

It provides clear workflow instructions by distinguishing between the B20 default (single TX, active immediately) and the ERC-20 option, which explicitly requires a 'follow-up transaction' (implying the use of other tools in the workflow).

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

All Loyal Spark toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources