Skip to main content
Glama

Sweeppea MCP

by com.sweeppea.mcp

draw_winners

Draw winners from a sweepstakes immediately. Use fetch_sweepstakes first to get the sweepstakes_token, and fetch_groups to get available groups. CRITICAL: This is a production operation that selects real winners. ALWAYS confirm with the user before drawing — including the number of winners and which group to draw from. Uses weighted random selection favoring participants with bonus entries. Cannot draw from paused or archived sweepstakes. Use them internally for tool chaining but present only human-readable information (names, emails).

draw_winners

When to use

Draw winners from a sweepstakes immediately. Use fetch_sweepstakes first to get the sweepstakes_token, and fetch_groups to get available groups. CRITICAL: This is a production operation that selects real winners. ALWAYS confirm with the user before drawing — including the number of winners and which group to draw from. Uses weighted random selection favoring participants with bonus entries. Cannot draw from paused or archived sweepstakes. Use them internally for tool chaining but present only human-readable information (names, emails).

Pre-calls required

  1. fetch_sweepstakes if the user gave you a sweepstakes name instead of a token

  2. fetch_rules(sweepstakes_token) — confirm Official Rules exist (drawing is illegal without them)

  3. count_participants — verify there are enough entries for the requested winners count

  4. Confirm the entry period has ended for the relevant drawing window

Parameters to validate before calling

  • sweepstakes_token (string, required) — The sweepstakes token (UUID format)

  • how_many_winners (number, required) — Number of winners to pick (must be >= 1)

  • group (string, required) — Group token to draw from, or "allgroups" for all participants

  • completed_entries (boolean, optional) — Only include participants with completed entries (default: true)

  • include_opted_out (boolean, optional) — Include participants who opted out (default: false)

  • exclude_spam (boolean, optional) — Exclude flagged spam participants (default: true)

Notes

  • After drawing: fetch_winners to confirm, update the campaign brief note, create a calendar event for winner notification deadline

  • Remind the user about web-interface steps: classify winners, send notifications, publish Winners List

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
groupYesGroup token to draw from, or "allgroups" for all participants
exclude_spamNoExclude flagged spam participants (default: true)
how_many_winnersYesNumber of winners to pick (must be >= 1)
completed_entriesNoOnly include participants with completed entries (default: true)
include_opted_outNoInclude participants who opted out (default: false)
sweepstakes_tokenYesThe sweepstakes token (UUID format)

TDQS

A4.3/5.0
Behavior5/5

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

The description adds critical behavioral context beyond annotations: 'CRITICAL: This is a production operation that selects real winners. ALWAYS confirm with the user before drawing.' It also discloses weighted random selection, the constraint on paused/archived sweepstakes, and follow-up actions. These details go well beyond the readOnlyHint and destructiveHint flags, and there is no contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is overly long and redundant. The opening paragraph is almost verbatim repeated in the 'When to use' section. The 'Parameters to validate before calling' section largely duplicates schema descriptions. While section headers help structure, the duplication wastes space and could confuse the agent by presenting the same information twice.

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?

The description covers pre-calls (fetch_sweepstakes, fetch_rules, count_participants), validation constraints, critical warnings, and post-drawing steps (fetch_winners, calendar event). However, it does not describe the return value or output format, which is notable since there is no output schema. Otherwise, it is highly complete for a complex mutation tool.

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 100%, so the baseline is 3. The description repeats parameter validation details already present in the schema (e.g., 'must be >= 1', 'default: true'). It adds minor context like 'group token to draw from, or "allgroups"', but this is also in the schema. No significant added meaning beyond what the schema provides.

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?

The description clearly states the tool's function: 'Draw winners from a sweepstakes immediately.' It uses a specific verb ('draw'), names the resource ('winners from a sweepstakes'), and distinguishes from siblings like schedule_drawing and fetch_winners by emphasizing immediate execution. The purpose is explicit and unambiguous.

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?

The description provides explicit pre-call instructions ('Use fetch_sweepstakes first', 'Use fetch_groups'), a detailed 'Pre-calls required' section, and a clear exclusion: 'Cannot draw from paused or archived sweepstakes.' It also includes confirmation steps and warns against drawing without rules. This fully guides when and how to use the tool versus alternatives.

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

All Sweeppea MCP toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.6/5.0
Disambiguation4/5

Most tools follow a clear resource+action pattern (fetch_* for lists, get_* for single items, create/update/delete for writes), making them distinguishable. A few near-overlaps exist (fetch_billing_transactions vs fetch_wallet_transactions, draw_winners vs schedule_drawing) but the descriptions clarify the boundaries.

Naming Consistency4/5

Tool names consistently use snake_case verb_noun, with fetch_ for list operations and get_ for single-item retrieval. Some verb variation (add_participant, count_participants, draw_winners, schedule_drawing) deviates from the dominant create/fetch/update/delete pattern but remains predictable and readable.

Tool Count1/5

With 83 tools, this is far beyond a well-scoped server (typically 3-15, with 25+ considered too many). Even though the platform has broad functionality, the sheer number of tools creates significant agent confusion and selection overhead.

Completeness4/5

The sweepstakes domain is thoroughly covered: lifecycle management, participants, groups, rules, drawings, winners, calendar, notes, todos, tickets, surveys, invoices, billing, files, and entry settings. A few minor gaps exist (e.g., no general participant field update, no archive action) but the surface is remarkably complete for its scope.

Resources