gumroad_update_offer_codeUpdate an existing offer code on a product (its code text and/or its max purchase count). Gumroad REST: PUT /v2/products/{product_id}/offer_codes/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The offer code id to update. | |
| offer_code | No | New discount code text. | |
| product_id | Yes | The product id the offer code belongs to. | |
| max_purchase_count | No | New cap on how many times the offer code can be used. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal destructive behavior via destructiveHint=true. The description adds that only code text and max purchase count can be changed, which is helpful but does not disclose further side effects or permissions. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, and efficiently includes the REST endpoint for implementation. No redundant wording or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential purpose and parameters, with schema filling in details. It lacks return value or error info, but with no output schema and moderate complexity, this is acceptable. The destructiveHint annotation provides safety context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters with descriptions, so baseline is 3. The description adds minimal value by clarifying which fields are updatable, but this overlaps with parameter descriptions for offer_code and max_purchase_count.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates an existing offer code on a product, specifying the updatable attributes (code text and max purchase count). It distinguishes from sibling tools like create, get, and list by using the verb 'update' and referencing the existing resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates this is for updating existing offer codes, implying it should not be used for creation or retrieval. However, it does not explicitly mention alternatives or when-not scenarios, just the REST endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct resource (product, offer code, license, sale, subscriber, user, variant category, custom field, resource subscription) with a specific action (get, list, create, update, enable, disable, verify). Even the license tools (enable, disable, verify) are clearly differentiated by their descriptions, and no two tools overlap in purpose.
All tools follow the consistent pattern of 'gumroad_' + verb (create, get, list, update, enable, disable, verify) + noun in snake_case. The verbs and nouns are uniformly chosen, making the API predictable and easy to navigate.
20 tools is in the 16-25 range that feels heavy, but the breadth is justified by Gumroad's multiple resource types. However, the number leans toward the upper bound, and some resources have only partial CRUD coverage, so the count is borderline.
The tool set is read-heavy: products lack create/update/delete, offer codes lack delete, resource subscriptions lack create/delete, and custom fields only have list. These significant gaps prevent agents from performing full lifecycle management, which will cause failures for common workflows like publishing a new product.