GrowSurf

Bulk Delete Participants

growsurf_bulk_delete_participants

DestructiveIdempotent

Bulk delete participants from your GrowSurf program in one request. DESTRUCTIVE: deletion is permanent and cannot be undone. Successful rows lose participant access immediately; related record cleanup completes automatically, subject to required financial record retention. Each entry in participants is a GrowSurf participant ID or an email address (mixed lists are allowed), up to 200 entries per request — chunk larger lists across multiple calls. Returns a summary (total, deletedCount, notFoundCount, duplicateCount, errorCount) plus per-row results in request order, each with status DELETED, NOT_FOUND, DUPLICATE (resolves to the same participant as an earlier entry), or ERROR — both 200 and 202 responses can include NOT_FOUND or ERROR rows, and the summary reports these outcomes. A 202 response includes analyticsErasure when analytics erasure is pending. DELETED means participant access was removed; reports can retain the participant until cleanup completes. Do not repeat successful rows to finish cleanup. Targets campaignId if you pass it, otherwise GROWSURF_CAMPAIGN_ID.

Input Schema

Name	Required	Description	Default
`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.
`participants`	Yes	GrowSurf participant IDs and/or email addresses to delete (1-200 entries; mixed lists allowed).

Output Schema

Name	Required	Description
`results`	No	One entry per submitted identifier, in request order.
`summary`	No	Counts across all submitted entries.
`analyticsErasure`	No	Analytics erasure is pending. Reports can retain removed participants until erasure completes. Do not repeat successful deletions.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 8, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well past the annotations: permanent and irreversible deletion, immediate loss of participant access, automatic related-record cleanup subject to financial retention, 200-entry rate/limit constraint, and the fact that both 200 and 202 responses may carry NOT_FOUND or ERROR rows. It also warns against re-submitting successful rows to force cleanup, which is genuinely non-obvious behavior.

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 purpose and the DESTRUCTIVE warning, then organized around limits, response semantics, and campaign targeting. Dense but every sentence carries operational information; only the return-value enumeration feels slightly redundant given an output schema exists.

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

Completeness5/5

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

For a destructive bulk mutation with two parameters, the description covers reversibility, side effects, dry-run-free chunking, partial-success semantics, status codes, and target resolution. Nothing an agent needs to call it safely and interpret results is missing.

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 100%, so baseline is 3, but the description adds real meaning: entries may mix participant IDs and email addresses, the 200 cap and chunking strategy, and the campaignId fallback to GROWSURF_CAMPAIGN_ID. These details refine how the parameters should be populated beyond the schema text.

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 ('Bulk delete participants from your GrowSurf program in one request') and immediately scopes it as a bulk operation, distinguishing it from the single-record sibling tools like growsurf_delete_campaign_reward and growsurf_update_participant. An agent can identify the correct tool without opening the schema.

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 concrete operating context: up to 200 entries per request, chunk larger lists across multiple calls, mixed ID/email lists allowed, and the campaign target resolution rule. It does not name an alternative tool or an explicit 'do not use this for X' condition, but no sibling covers the same ground, so the guidance is essentially complete.

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.