Skip to main content
Glama
anythink-cloud

Anythink-MCP

Official
by anythink-cloud
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Remote

Pay: offers update

pay_offers_update
Destructive

Update an existing offer's name, description, rewards, eligibility, caps, dates, or status; omitted fields remain unchanged, and paused or expired offers stop code redemption.

Instructions

Update an offer (patch — only supplied fields change; kind is immutable). Changes an offer's name, description, rewards, eligibility, caps, dates or status; omitted fields are kept. Setting status to paused or expired stops its codes being redeemed. Changing a discount reward does not update the Stripe coupon made at creation. For status alone, pay_offers_pause and pay_offers_activate are simpler. It changes or deletes existing data, so check with the user before running it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesOffer id to update. Find it with pay_offers_list.
nameNoOffer display name
statusNoSet status: active, paused, or expired
total_capNoTotal redemption cap (omit for unlimited)
valid_fromNoOffer valid-from (ISO date/time)
descriptionNoOffer description
eligibilityNoEligibility rules as JSON, e.g. {"match":"all","rules":[{"type":"subscribed_to_plan","plan_ids":[1]}]}
valid_untilNoOffer valid-until (ISO date/time)
per_user_capNoPer-user redemption cap (default 1)
redeemer_rewardNoRedeemer reward as JSON, e.g. {"type":"discount","percent_off":50,"duration":"once"}
referrer_rewardNoReferrer reward as JSON (referral offers only)
discount_percentNoShortcut: redeemer reward = N% discount (use --discount-duration for recurrence)
discount_durationNoDiscount duration for --discount-percent: once, forever, repeating (default once)
redeemer_trial_daysNoShortcut: redeemer reward = trial extension of N days
referrer_trial_daysNoShortcut: referrer reward = trial extension of N days
referrer_subscription_daysNoShortcut: referrer reward = subscription extension of N days

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.37

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only flag destructive/not-read-only; the description goes well beyond them by disclosing patch semantics (omitted fields kept), the immutability of kind, the side effect that pausing/expiring halts code redemption, and the non-obvious caveat that changing a discount reward does not update the Stripe coupon created at creation.

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?

Front-loaded with the core action and constraint, then side effects, alternatives, and caution in a logical order. The clause enumerating updatable fields ('name, description, rewards, eligibility, caps, dates or status') partially restates the schema, which is the one bit of low-yield text.

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 16-parameter mutation with no output schema, it covers mutation semantics, side effects, and safety guidance well. It says nothing about what the call returns or error conditions, though with no output schema the return-value burden is lower.

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 16 fields. The description reinforces the mutable field set and the immutability constraint on kind, but adds no syntax or format detail beyond the schema; baseline 3 applies.

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 ('Update an offer') and immediately scopes it with patch semantics ('only supplied fields change; kind is immutable'), which distinguishes it from pay_offers_create and from the narrower pay_offers_pause/activate siblings.

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?

Explicitly routes the status-only case to the simpler siblings ('For status alone, pay_offers_pause and pay_offers_activate are simpler') and adds a precondition ('check with the user before running it'). Both when-to-use and when-to-use-something-else are covered.

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