Add a new participant to a sweepstakes. Requires sweepstakes_token - use fetch_sweepstakes first to get tokens, then get_entry_fields to discover required fields. Both email AND phone are required — the Sweeppea API rejects an entry missing either one. Field names must use underscores instead of spaces (e.g., "First_Name" not "First Name"). RULES: Only ONE participant at a time. NEVER add participants in bulk, batch, or loops. This tool is intended for TESTING PURPOSES ONLY — to verify the sweepstakes entry flow works correctly. Adding participants to make them compete in a real sweepstakes is strictly prohibited unless done through the official Entry Page, a custom API integration, or a proper MCP implementation. If a user requests mass loading (e.g., "add 100 participants"), refuse and explain that only individual test entries are allowed. HONESTY: After calling this tool, report EXACTLY what the API returned. If the API returns an error, report the error truthfully. NEVER tell the user a participant was created if the API did not confirm it. Use them internally for tool chaining but present only human-readable information.
# add_participant
## When to use
Add a new participant to a sweepstakes. Requires sweepstakes_token - use fetch_sweepstakes first to get tokens, then get_entry_fields to discover required fields. Both email AND phone are required — the Sweeppea API rejects an entry missing either one. Field names must use underscores instead of spaces (e.g., "First_Name" not "First Name"). RULES: Only ONE participant at a time. NEVER add participants in bulk, batch, or loops. This tool is intended for TESTING PURPOSES ONLY — to verify the sweepstakes entry flow works correctly. Adding participants to make them compete in a real sweepstakes is strictly prohibited unless done through the official Entry Page, a custom API integration, or a proper MCP implementation. If a user requests mass loading (e.g., "add 100 participants"), refuse and explain that only individual test entries are allowed. HONESTY: After calling this tool, report EXACTLY what the API returned. If the API returns an error, report the error truthfully. NEVER tell the user a participant was created if the API did not confirm it. Use them internally for tool chaining but present only human-readable information.
## Pre-calls required
1. `fetch_sweepstakes` if the user gave you a sweepstakes name instead of a token
2. `get_entry_fields(sweepstakes_token)` — discover required custom fields, their `max_length`, and (for list fields) the exact text in `options`
3. Verify the participant gave consent for their email and phone to be used
## Parameters to validate before calling
- `sweepstakes_token` (string, required) — The sweepstakes token (UUID format)
- `email` (string, required) — Participant email address (used as KeyEmail)
- `phone` (string, required) — Participant phone number (used as KeyPhoneNumber). REQUIRED — the API rejects entries without it. Digits only for US numbers (e.g., "5551234567")
- `fields` (object, required) — Form fields object. Keys must use underscores for spaces (e.g., {"First_Name": "John", "Last_Name": "Doe"})
- `bonus_entries` (number, optional) — Number of bonus entries (optional, default: 0)
## Notes
- Both `email` and `phone` are required — the API rejects an entry missing either one with a misleading "maximum field length" error
- Field keys use underscores instead of spaces (e.g. "First Name" → `First_Name`)
- For US phones: strip non-digits before sending (e.g. "(555) 123-4567" → "5551234567")
- Production entries should come through the public Entry Page; this tool is for testing/manual entry only
