MCP server for wheelfor.com — create, spin, and manage shareable decision wheels from any MCP-compatible AI client.
Works with Claude Desktop, Cursor, Windsurf, VS Code, and any other MCP host. No account required.
Tool | Description |
| Create a new spinning wheel from a list of options |
| Spin an existing wheel and get a random result with a shareable URL |
| Update a wheel's choices, name, or theme using its edit key |
| Pick randomly from a list and create a permanent wheel in one step |
Related MCP server: Jmpy mcp server
Add to claude_desktop_config.json:
{
"mcpServers": {
"wheelfor": {
"command": "npx",
"args": ["-y", "@wheelfor/mcp"]
}
}
}Mac: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Add to .cursor/mcp.json in your project or ~/.cursor/mcp.json globally:
{
"mcpServers": {
"wheelfor": {
"command": "npx",
"args": ["-y", "@wheelfor/mcp"]
}
}
}Add to ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"wheelfor": {
"command": "npx",
"args": ["-y", "@wheelfor/mcp"]
}
}
}Once connected, ask your AI assistant:
"I can't decide between React, Vue, or Svelte — pick one"
"Create a wheel for our team retro: Start, Stop, Continue, More Of, Less Of"
"Spin wheelfor.com/wheel/lunch-spots"
"Add burgers to my lunch-spots wheel" (requires edit key from creation)
create_wheelCreates a new wheel on wheelfor.com.
Parameter | Type | Required | Description |
| string | ✓ | Short title |
| string[] | ✓ | Items on the wheel |
| string | ✓ | One sentence describing the wheel |
| string | ✓ | Visual theme (see below) |
| string | 2–3 paragraphs on use cases | |
| string | Brief instruction for visitors | |
| string | Word for one choice (e.g. | |
| string | Plural form (e.g. |
Themes: Fresh Air · Popcorn · Playground · Sprinkles · Chalkboard · Buddy System · Garden Party · Marshmallow
Returns the wheel URL and an edit key for future updates.
spin_wheelParameter | Type | Required | Description |
| string | ✓ | Wheel slug or full URL |
Returns the winning choice and a shareable result URL.
update_wheelParameter | Type | Required | Description |
| string | ✓ | Wheel slug |
| string | ✓ | Edit key from creation |
| string | New title | |
| string[] | New choices list | |
| string | New theme | |
| string | New description |
decideParameter | Type | Required | Description |
| string[] | ✓ | Options to choose from |
| string | What the decision is about |
Picks a random option immediately, then creates a permanent wheel for future spins.
MIT
Create a shareable spinning decision wheel on wheelfor.com from a list of options
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Short title (e.g. 'Team Lunch Spots') | |
| choices | Yes | Items on the wheel | |
| description | Yes | One sentence describing the wheel | |
| theme | Yes | Visual theme — Fresh Air (nature), Popcorn (fun), Playground (bold), Sprinkles (celebration), Chalkboard (education), Buddy System (teams), Garden Party (elegant), Marshmallow (cozy) | |
| longDescription | No | 2–3 paragraphs on use cases (used for SEO) | |
| usageHint | No | Brief instruction for visitors (e.g. 'Spin to pick a random lunch spot') | |
| choiceNounSingular | No | Word for one choice (e.g. 'restaurant') | |
| choiceNounPlural | No | Plural form (e.g. 'restaurants') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only states the basic action. It does not disclose any behavioral traits such as side effects, required permissions, or what happens upon success (e.g., a URL or redirect).
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?
The description is a single, front-loaded sentence with no superfluous words. It efficiently communicates the core purpose.
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?
Despite having 8 parameters and no annotations or output schema, the description is too brief. It omits information about return values, creation process details, or any constraints, leaving the agent without a complete picture.
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% with each parameter having a description. The tool description adds no extra parameter context, but the baseline of 3 is appropriate as the schema adequately covers semantics.
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 clearly states the action (create), the object (a shareable spinning decision wheel), and the platform (wheelfor.com). It distinguishes itself from siblings like update_wheel and spin_wheel by focusing on initial creation.
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?
The description provides no guidance on when to use this tool versus the siblings (decide, spin_wheel, update_wheel). It does not mention alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pick randomly from a list of options and create a shareable wheel on wheelfor.com in one step
| Name | Required | Description | Default |
|---|---|---|---|
| options | Yes | Options to choose from | |
| topic | No | What the decision is about (e.g. 'Lunch', 'Sprint activity') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behavioral traits. It mentions randomness and wheel creation but lacks details on side effects (e.g., resource creation, permissions, rate limits, or whether the pick is truly random).
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?
The description is a single, focused sentence with no wasted words. It efficiently conveys the core functionality without unnecessary details.
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?
Given no output schema and no annotations, the description should provide more context about return values, the shareable wheel generation process, and when to use this combined tool vs separate siblings. It leaves important gaps for an agent to decide correctly.
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% with clear parameter descriptions. The tool description adds no extra semantic meaning beyond 'pick randomly and create wheel', which is already implied by the name and schema.
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 clearly states the action ('pick randomly'), resource ('list of options' and 'shareable wheel'), and the combined nature ('in one step'), distinguishing it from siblings like create_wheel and spin_wheel.
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?
The description implies usage for random selection with wheel creation but provides no explicit when-to-use, when-not-to-use, or alternatives. Context signals show siblings, but the description fails to guide selection between them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Spin an existing wheelfor.com wheel and get a random result with a shareable URL
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Wheel slug or full URL (e.g. 'lunch-spots' or 'https://wheelfor.com/wheel/lunch-spots') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It mentions that the tool returns a random result with a shareable URL, indicating a read operation, but does not explicitly state whether spinning modifies the wheel (e.g., incrementing spin count) or if it is idempotent. The description is adequate but lacks full transparency.
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?
The description is a single sentence, front-loaded with the action, and contains no extraneous information. Every word contributes to the purpose.
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 simple tool with one parameter and no output schema, the description adequately explains what the tool does and what it returns. However, without annotations, it could mention whether the operation is safe (e.g., does not modify the wheel) for completeness.
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 input schema provides a description for the slug parameter, and the tool description does not add any additional meaning beyond that. With 100% schema description coverage, the baseline is 3, and no extra value is provided.
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 clearly states that this tool spins an existing wheelfor.com wheel and returns a random result with a shareable URL. It distinguishes itself from sibling tools like create_wheel, update_wheel, and decide by focusing on the specific action of spinning an existing wheel.
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?
The description implies that the tool should be used when the user wants to spin an already-existing wheel, which is a clear context. However, it does not explicitly mention when not to use it or provide alternatives, but given the sibling tool names, the purpose is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing wheelfor.com wheel using its edit key
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Wheel slug | |
| editKey | Yes | Edit key from wheel creation | |
| name | No | ||
| choices | No | ||
| theme | No | ||
| description | No | ||
| longDescription | No | ||
| usageHint | No | ||
| choiceNounSingular | No | ||
| choiceNounPlural | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only mentions 'update' without stating side effects, authorization needs, or safety guarantees. The tool is a mutation, but no cautionary notes are given.
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?
The description is a single sentence that is efficient and to the point. However, it could be slightly more structured by explicitly listing key parameters or conditions.
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?
Given 10 parameters, low schema coverage, and no output schema, the description is inadequate. It does not explain the return value, optional parameters, or required format for arrays. More detail is needed for a complete understanding.
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?
Only 20% of parameters have schema descriptions (slug and editKey). The description adds no additional meaning to parameters beyond what is in the schema. With 10 parameters, the description should clarify the role of optional fields like name, choices, theme, etc.
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 clearly states the action (update) and the resource (existing wheelfor.com wheel) with a necessary condition (using edit key). It effectively distinguishes from siblings like create_wheel and spin_wheel.
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?
The description implies that the tool is for modifying an existing wheel and requires the edit key. However, it does not explicitly state when to use it versus alternatives like create_wheel, nor does it provide guidance on prerequisites or exclusions.
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.
v1.0.1create_wheeldecidespin_wheelupdate_wheelScored across 4 tools
Tools are mostly distinct: create_wheel solely creates, spin_wheel spins existing, update_wheel edits, and decide combines creation and spin. However, decide could confuse agents aiming for sequential create then spin, creating minor overlap.
Three tools follow verb_noun pattern (create_wheel, spin_wheel, update_wheel), but 'decide' lacks a noun and uses a different verb style, breaking the otherwise consistent naming convention.
With 4 tools, the server is reasonably scoped for a simple wheel service. It covers creation, spinning, and updating, but could be slightly more efficient if decide were omitted. Still appropriate for its domain.
Core operations are present: create, spin, and update. However, there is no way to delete a wheel, and the decide tool bundles create+spin, bypassing the need for a separate spinning step. A delete tool is notably missing.
Spin a random picker wheel, pick a random number, and search shared wheels from spinwheelnames.com.
Real local places, events, and movie/TV picks, plus decision-maker games (wheel, dice, bracket).
Turn photos or product links into a poll your friends vote on. One link, free, no account needed.
Publish, fork, improve browser games. No-auth reads; OAuth to post. Wheel: verified ops knowledge.
