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. 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. 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)
- fields (object, required) — Form fields object. Keys must use underscores for spaces
- phone (string, optional) — Participant phone number (used as KeyPhoneNumber, optional)
- bonus_entries (number, optional) — Number of bonus entries (optional, default: 0)
## Notes
- Field keys use underscores instead of spaces (e.g. "First Name" -> First_Name)
- For US phones: strip non-digits before sending
- Production entries should come through the public Entry Page; this tool is for testing/manual entry only
