Zovo Fair Draw

Create prize draw

create_prize_draw

Use this when the user wants a fair random pick of winners from a group: a giveaway, door prize, raffle without tickets, classroom or team pick. Publishes a draw page with a public link where entrants add their names (or only the organizer adds them), and returns a private organizer link. Optionally adds a first list of names. Up to 500 entries, 1 to 20 winners, up to 10 backups. For free draws only: set free_entry to true to confirm nobody pays to enter; it does not handle money. Does not draw yet; use draw_winners for that.

Input Schema

Name	Required	Description
`note`	No	Optional short note shown on the page, up to 400 characters, e.g. Draw on Friday at the team call.
`names`	No	Entrant display names, up to 500, each up to 40 characters, one person per item, e.g. ["Ana", "Ben K.", "Chloe"]. First names or nicknames only.
`prize`	No	What the winners get, up to 200 characters, e.g. One 50-minute massage voucher.
`title`	Yes	Short title of the draw, up to 120 characters, e.g. Team lunch voucher draw.
`backups`	No	Number of backup winners drawn in order after the winners, 0 to 10 (default 0). Example: 2.
`winners`	No	Number of winners, 1 to 20 (default 1). Example: 2.
`free_entry`	Yes	Set true to confirm nobody pays to enter and no money is pooled; this tool does not handle money.
`public_entry`	No	true (default) = people add their own name on the public page; false = only the organizer adds names.

Output Schema

Name	Required	Description	Default
`note`	No
`seed`	Yes
`added`	No
`names`	Yes
`prize`	Yes
`title`	Yes
`action`	Yes
`status`	Yes
`backups`	Yes
`entries`	Yes
`skipped`	No
`winners`	Yes
`drawn_at`	Yes
`commitment`	Yes
`expires_at`	Yes
`manage_url`	Yes
`public_url`	Yes
`names_shown`	Yes
`public_entry`	Yes
`skipped_count`	No
`backups_wanted`	Yes
`winners_wanted`	Yes
`entry_list_hash`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the annotations, it explains that a public draw page and link are published, a private organizer link is returned, names may be added by the organizer or entrants, and there are entry and winner limits. It also discloses that the tool does not handle money and does not draw winners yet.

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

Conciseness5/5

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

The description is front-loaded with the primary use case and then layers constraints and alternatives efficiently. It is appropriately sized and every sentence contributes actionable context.

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?

Given the annotations, rich input schema, and presence of an output schema, the description supplies everything needed to select and invoke the tool correctly. It covers purpose, setup behavior, limits, free-entry constraint, and the handoff to draw_winners.

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?

The schema has full description coverage, so the baseline is 3. The description adds useful semantics around free_entry (confirming no payment is involved) and public_entry behavior (entrants add names versus organizer-only), though the size limits it mentions are already present in the schema.

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 states a specific verb and resource: creating a prize draw for a fair random pick of winners. It clearly distinguishes the tool from draw_winners by saying "Does not draw yet; use draw_winners for that."

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?

It gives explicit when-to-use guidance (giveaway, door prize, raffle without tickets, classroom or team pick) and a when-not-to-use condition (drawing is handled by draw_winners). It also states the free-draw constraint and that free_entry must be true to confirm nobody pays to enter.

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

All Zovo Fair Draw 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.

Resources

Need Help?