Search free US sweepstakes by prize, end date and state, or send us new ones to list.
Scored across 4 tools
Each tool has a clearly distinct purpose: retrieve one sweepstake by slug, browse categories/lists, search the catalog, and submit a new listing. No two tools overlap in resource or action, so misselection is unlikely.
All four tools follow a consistent snake_case verb_noun pattern (get_, list_, search_, submit_). The only nit is singular 'sweepstake' vs plural 'sweepstakes' noun forms, but the structural convention is uniform.
Four tools is reasonable for a read-oriented sweepstakes directory plus a contribution channel, with each tool earning its place. It is on the lean side—no dedicated tools for pagination or user-side listing management—but not problematically thin.
Discovery (search, list categories, get details) and contribution (submit) are covered, matching the apparent domain of a public sweepstakes directory. Minor gaps exist, such as checking submission status or retrieving a submission history, which agents can work around via the website.
Details for one sweepstake by its UltimateSweepers slug (the last part of an ultimatesweepers.com/s/ link).
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Listing slug, e.g. 'pch-chevrolet-corvette-sweepstakes'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the resource-namespace context (UltimateSweepers slugs from ultimatesweepers.com/s/<slug> URLs) but says nothing about not-found behavior or response shape. With annotations carrying the burden, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence that front-loads the verb+resource and then qualifies the identifier format. No filler, nothing redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with no output schema, the description supplies the key detail an agent needs — the meaning and origin of the slug. It is nearly complete, missing only edge-case behavior such as an invalid/unknown slug.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already gives the type and an example, so the baseline is 3. The description adds genuine value by explaining what the slug actually is and where the caller obtains it (the trailing segment of a site URL), which the schema does not state.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Details for one sweepstake') and scopes it to a single item, which cleanly separates it from list_sweepstakes_categories and search_sweepstakes. It does not name those siblings explicitly, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the phrase 'by its ... slug' signals that the agent must already have an identifier in hand before calling, which contrasts with search/list. No explicit when-to-use vs. when-not statement or prerequisite guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prize categories, entry frequencies and the curated UltimateSweepers lists (ending today, daily entry, big prizes, …) with links.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral detail by disclosing that URLs/links are included in the response, but says nothing about whether the result set is static, cached, or how many entries are returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence with no filler, and the primary content (categories) is front-loaded before the curated-list examples. The trailing ellipsis is slightly loose but cheap.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of describing the return payload. It names the three content groups and that links are included, which is helpful, but does not indicate the shape of the response or how categories, frequencies, and lists relate to one another.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters and schema coverage is 100%, so there is no parameter semantics for the description to clarify. Baseline 4 for a zero-parameter tool is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the concrete resources returned — prize categories, entry frequencies, and curated lists like 'ending today' and 'daily entry' — so an agent can tell what the tool surfaces. It never states a verb or differentiates itself from get_sweepstake or search_sweepstakes, but the purpose is clear enough from the enumerated content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to call this versus search_sweepstakes or get_sweepstake, nor any stated prerequisite or trigger condition. The ellipsis-form list of example lists hints at content but not at when to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search free-to-enter US sweepstakes listed on UltimateSweepers.com, sorted by end date by default. Every result links to its UltimateSweepers listing with official rules, eligibility and the entry link.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort order. Default: ending soonest first. | |
| limit | No | Number of results (default and max 10). Narrow the search to see others. | |
| query | No | Words to match in the title, sponsor or prize, e.g. 'disney trip' or 'pepsi'. | |
| state | No | Two-letter US state code; hides sweepstakes that exclude that state. | |
| ending | No | Only sweepstakes ending within this window. | |
| category | No | Prize category. | |
| frequency | No | How often you can enter. | |
| instant_win | No | Only instant-win games. | |
| min_prize_usd | No | Minimum total prize value in US dollars. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds meaningful behavioral context beyond that: the default sort is end-date ascending and every result links out to an UltimateSweepers listing containing official rules, eligibility and the entry link. It omits rate limits or result-count behavior, but the added result-shape context is real value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose and scope, followed by result-content context. No filler, no repetition of the title, and the default-sort fact is placed early where it matters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a nine-parameter, zero-required search tool with no output schema, the description supplies the scope, default ordering, and a sense of what a result contains. It could say more about result limits (the schema caps at 10) or lack of pagination, but nothing essential to calling it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all nine parameters including the default sort order. The description's mention of the default end-date sort merely restates what the schema specifies, adding no syntax or semantics beyond it. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (search) and resource (US sweepstakes) with tight scope qualifiers: free-to-enter, listed on UltimateSweepers.com. This clearly separates it from the singular retrieval (get_sweepstake), the category listing (list_sweepstakes_categories), and the write tool (submit_sweepstake).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance is offered, and no alternative tool is named. It doesn't tell the agent when to prefer get_sweepstake (e.g., when an id is already known) or how this relates to the sibling tools, leaving usage to inference from the verb alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Know a free-to-enter sweepstake that isn't on UltimateSweepers yet? Send the link to the official entry or rules page. Our team checks the sponsor and official rules before anything is published. Free entry only: no paid raffles or purchase-required contests.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Link to the sweepstake's official entry page or official rules (https://…). | |
| No | Optional email for credit. Never shown publicly. | ||
| notes | No | Anything else: eligibility, entry frequency, where you found it. | |
| prize | No | Prize and value if known, e.g. '4-night Orlando trip ($4,796)'. | |
| title | No | Sweepstake name, e.g. 'Visit Orlando Family Vacation Sweepstakes'. | |
| ends_on | No | End date as YYYY-MM-DD, if known. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the mutation profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true), and the description adds meaningful context beyond them: submissions go through human review of the sponsor and official rules before publication, so the agent knows this is not an instant-publish action. Missing auth/permission notes and any rate-limit or duplicate-submission behavior keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, front-loaded with the call to action and the target resource, then the review process, then the eligibility restriction. Every sentence carries a distinct piece of information with no padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a six-parameter, single-required submission tool with no output schema, the description supplies the purpose, eligibility limits, and the moderation outcome, which is nearly everything needed to call it correctly. It stays silent on what the submitter sees back (e.g., an acknowledgement or tracking of the pending submission), a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all six parameters are already documented, giving a baseline of 3. The description reinforces the intent of 'url' (official entry or rules page) and the free-entry eligibility constraint, but adds no format or validation detail beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete action and resource: send the link to a sweepstake's official entry or rules page so it can be considered for listing. It also names the destination platform (UltimateSweepers) and scopes the content type (free-to-enter sweepstakes only), making it clearly distinct from the read-only siblings get/list/search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear triggering condition ('Know a free-to-enter sweepstake that isn't on UltimateSweepers yet?') and an explicit exclusion ('no paid raffles or purchase-required contests'), which tells the agent when not to call it. It does not name a sibling tool as the alternative for lookup, but the exclusions cover the main mis-invocation risk.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_sweepstakelist_sweepstakes_categoriessearch_sweepstakessubmit_sweepstakeSearch open US class-action settlements to claim + official free state unclaimed-money portals.
Find US food pantries near a ZIP or City, ST, and look up a State's TEFAP rules with sources. Free.
Search 31,000+ open US grants, federal contracts, and foundations. Checked daily, free tier.
Find unclaimed money in the US and UK: the official free searches and how to claim.
Add one secure layer between your agents and this server.
