GrowSurf

Record Affiliate Refund or Chargeback

growsurf_refund_transaction

DestructiveIdempotent

Record a refund, partial refund, or chargeback for a previously recorded affiliate transaction in GrowSurf and reverse or adjust the referrer's commission. This records the amendment without sending a refund through the payment provider. Requires the same transaction identifier as the original sale. Omitted amountRefunded means a full refund. Already-paid commissions are not clawed back and are recorded for tax only. Targets campaignId if supplied, otherwise GROWSURF_CAMPAIGN_ID.

Input Schema

Name	Required	Description
`amount`	No
`orderId`	No
`chargeId`	No
`currency`	No
`refundId`	No	Stable per-refund identifier. Required when canceling a refund or changing the refunded total after a cancellation. Reuse the original refund's identifier for its cancellation. An amendment without enough refund identity returns `409` without applying the cancellation. Newly observed higher cumulative refunds and incomplete coverage are retained for reconciliation.
`testMode`	No	Original payment mode: `true` for test or `false` for live. Requires `paymentProvider`.
`invoiceId`	No
`paymentId`	No
`campaignId`	Yes	Target program (campaign) id for this call. Defaults to GROWSURF_CAMPAIGN_ID when omitted. Program IDs also identify newly created programs without restarting the server.
`externalId`	No
`description`	No
`refundAmount`	No	Positive amount for this individual refund, no greater than the sale amount, in the sale currency's minor unit. Send it with `refundId` on each original refund to support cancellations and out-of-order amendments. The amount for a given `refundId` cannot change. A cancellation can omit it when the original amount is already recorded. Incomplete refund history returns `409` without applying the cancellation. Newly observed higher cumulative refunds and incomplete coverage are retained for reconciliation.
`refundStatus`	No
`amendmentType`	No
`participantId`	No
`transactionId`	No
`amountRefunded`	No
`paymentIntentId`	No
`paymentProvider`	No	Connected provider for the original payment. Requires its `transactionId` and `testMode`. This amends GrowSurf records without sending a refund through the provider.
`participantEmail`	No
`refundHistoryComplete`	No	Set true only after reconciling and recording every original refundId and refundAmount, including refunds later canceled. This confirmation resolves previously incomplete history. Omit during ordinary delivery. Replaying an old confirmation cannot resolve a later gap; confirm a newly reconciled refund or complete provider list.

Output Schema

Name	Required	Description
`deleted`	No	Pending commissions deleted by the amendment.
`matched`	No	Commissions found for the provided identifiers.
`message`	No	Human-readable result message.
`success`	No	`true` when the amendment was processed; `false` when no matching transaction was found.
`adjusted`	No	Commissions partially adjusted.
`notFound`	No	Present and `true` when no commission matched the provided identifiers.
`reversed`	No	Commissions reversed (set to zero amount).
`amendmentType`	No	Amendment type that was processed.
`matchingCommissionIds`	No	Commission ids that matched the submitted identifiers.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 8, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations declare write/destructive/idempotent/openWorld, and the description adds real behavioral context beyond them: the amendment is recorded locally without touching the provider, already-paid commissions are not clawed back and are logged for tax only, and an omitted amountRefunded means a full refund. It stops short of surfacing the 409/incomplete-refund-history behavior, which lives only in the schema.

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?

The main action is front-loaded and each of the six sentences contributes a distinct fact (effect, no-provider-refund, identifier requirement, full-refund default, paid-commission handling, campaign targeting). It is dense but not padded, though it could be tightened marginally.

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 complex 21-parameter mutation with conditional requirements, the description covers the key decision points while annotations carry the safety profile and the output schema carries return values. The main omission is the paymentProvider-implies-testMode/transactionId rule and refund-identity rules, which the schema documents instead.

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 coverage is only 29% across 21 parameters, so the description must compensate, and it does cover the highest-value semantics: transactionId reuse, amountRefunded defaulting to full refund, and campaignId falling back to GROWSURF_CAMPAIGN_ID. It adds nothing for amendmentType, currency, amount, refundId/refundAmount, or the paymentProvider/testMode conditional, leaving meaningful gaps.

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 ('Record a refund, partial refund, or chargeback for a previously recorded affiliate transaction') and names the downstream effect on the commission. No sibling tool covers refunds, so the operation is unambiguously distinguishable from record_sale and the campaign/program management tools.

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 clear precondition ('for a previously recorded affiliate transaction') and the matching requirement ('Requires the same transaction identifier as the original sale'), plus a scope clarification that no refund is sent through the payment provider. It does not explicitly name an alternative tool or state when not to use this, but the context is strong.

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

All GrowSurf tools Inspect

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.