Skip to main content
Glama
Sign In

Moatless

by store.moatless
OverviewDiscussionsAdmin

Add a coupon code

create_coupon

Makes a coupon code for one of the user's listings, for buyers buying it for the first time. It takes purchase_percent_off off the purchase (100 makes it free) and subscription_percent_off off each period of a subscription to its updates, for its first subscription_periods (the listing's months or years), or without them, for as long as the subscription runs. It's for the listing's base plan unless base_plan_eligible is false, and for the plans whose ids are in plan_ids. Limit it with max_redemptions (how many buyers can use it) and expires_at. Ask the user for all of these; never pick discounts yourself. Buyers enter the code on the listing's page, or open its page with ?code=<code>. What it takes off can't change later.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "input": "<input>",
      "context": "<context>"
    },
    "name": "create_coupon"
  }
}

Input Schema

NameRequiredDescriptionDefault
inputYes
contextYesExplain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. Never include personal data, such as names, email addresses or message text; refer to people by role, such as "the user" or "a buyer".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / context
      Added value: +{
+  "description": "Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. Never include personal data, such as names, email addresses or message text; refer to people by role, such as \"the user\" or \"a buyer\".",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "input"
-]New value: +[
+  "input",
+  "context"
+]
  2. Added

TDQS

A4.2/5.0
Behavior4/5

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

Annotations only declare openWorldHint=false and destructiveHint=false, so the description carries most of the burden and does add real value: "What it takes off can't change later" discloses immutability, and it explains the buyer-side redemption path and the ?code= URL. It omits permission/ownership requirements and never says what is returned on success.

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 purpose is front-loaded, but the discount sentence is a long clause chain ("for its first subscription_periods ... or without them, for as long as the subscription runs") that is harder to parse than necessary. Little is wasted, but the structure could be broken into shorter, single-idea sentences.

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?

For a nested-object create tool with no output schema, the definition covers the discount semantics, immutability, and agent behavior well. It stops short of stating what the call returns (e.g., a coupon id) or any ownership/permission prerequisite, which an agent would want before invoking it.

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 50%, but the description explains business meaning the schema only hints at: 100 = free, the default of unlimited subscription periods, the interaction between base_plan_eligible and plan_ids, and that max_redemptions counts buyers rather than uses. expires_at and the analytics-only context field get no added explanation beyond 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 and resource ("Makes a coupon code") scoped to "one of the user's listings" and to first-time buyers, plus the discount model. An agent can tell this creates a coupon rather than updating or discontinuing one from the verb alone, even without a named alternative.

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 a strong operating rule — "Ask the user for all of these; never pick discounts yourself" — which is exactly the guidance an agent needs for a money-affecting tool. It does not explicitly say when to prefer update_coupon or list_coupons over this, so a minor gap remains.

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

All Moatless toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources