Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Lottery Demo roll a 20-sided die 3 times for our D&D game"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
这是一个完整的 MCP (Model Context Protocol) 插件示例，实现了抽签、投骰子、抛硬币等随机功能。
🎲 抽签工具：从选项列表中随机抽取结果
🎯 投骰子：支持自定义面数和数量
🪙 抛硬币：简单的正面/反面随机选择
Related MCP server: Dice Roller MCP Server
安装依赖：
npm install启动 MCP 服务器：
方式一：标准输入输出模式（推荐用于 AI 客户端集成）
npm start方式二：HTTP 服务器模式（支持 Web 界面和网络访问）
npm run start:http启动后访问：
🌐 Web 界面：http://localhost:3000
📡 MCP 端点：http://localhost:3000/mcp
❤️ 健康检查：http://localhost:3000/health
从给定的选项列表中随机抽取一个或多个结果。
参数：
options (必需): 抽签选项列表
count (可选): 抽取数量，默认为1
allow_duplicate (可选): 是否允许重复抽取，默认为false
示例：
{
"name": "draw_lottery",
"arguments": {
"options": ["苹果", "香蕉", "橙子", "葡萄"],
"count": 2,
"allow_duplicate": false
}
}投掷骰子，支持自定义面数和数量。
参数：
sides (可选): 骰子面数，默认为6
count (可选): 骰子数量，默认为1
示例：
{
"name": "roll_dice",
"arguments": {
"sides": 20,
"count": 3
}
}抛硬币，返回正面或反面。
参数：
count (可选): 抛硬币次数，默认为1
示例：
{
"name": "flip_coin",
"arguments": {
"count": 5
}
}以下是一些可以触发这些工具的示例 prompt：
帮我从这些水果中随机选一个：苹果、香蕉、橙子、葡萄、草莓我们5个人要分这些奖品：一等奖、二等奖、三等奖、四等奖、五等奖。请帮我们随机分配，每个人一个奖品。我想玩一个20面骰子的游戏，投3次，看看结果如何帮我抛5次硬币，看看正反面各出现多少次我们班有30个同学，要选出5个代表参加活动。请帮我随机选择，不能重复。mcp-lottery-demo/
├── package.json # 项目配置和依赖
├── README.md # 项目说明文档
├── demo-prompts.md # 演示 prompt 集合
├── test-client.js # 标准输入输出测试客户端
├── test-http-client.js # HTTP 测试客户端
├── demo.js # 演示脚本
└── src/
├── server.js # 标准输入输出 MCP 服务器
└── server-http.js # HTTP MCP 服务器使用 @modelcontextprotocol/sdk 构建 MCP 服务器
两种传输模式：
标准输入输出传输协议（用于 AI 客户端集成）
HTTP/SSE 传输协议（支持 Web 界面和网络访问）
实现了完整的工具注册和调用机制
包含错误处理和参数验证
提供 Web 界面和 RESTful API
你可以基于这个示例扩展更多功能：
添加更多随机工具：如随机数生成器、随机颜色选择等
持久化存储：保存抽签历史记录
用户偏好：记住用户的常用选项
统计分析：提供抽签结果的统计分析
可视化：生成图表展示结果分布
MIT License
从给定的选项列表中随机抽取一个或多个结果
| Name | Required | Description | Default |
|---|---|---|---|
| allow_duplicate | No | 是否允许重复抽取，默认为false | |
| count | No | 抽取数量，默认为1 | |
| options | Yes | 抽签选项列表 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions the random drawing behavior, it doesn't address important aspects like whether this is a read-only operation, if it has side effects, error conditions, or performance characteristics. For a tool with no annotations, this leaves significant behavioral gaps.
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 extremely concise - a single sentence that directly states the tool's core functionality. There's no wasted language, repetition, or unnecessary elaboration. It's front-loaded with the essential information.
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 the tool's moderate complexity (random selection with configurable parameters) and no output schema, the description is minimally adequate but incomplete. It covers the basic purpose but lacks information about return values, error conditions, and behavioral context. With no annotations and no output schema, the description should provide more complete guidance for effective tool use.
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?
With 100% schema description coverage, the schema already documents all three parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it mentions '选项列表' (option list) which corresponds to the 'options' parameter, but provides no additional context about parameter usage, constraints, or interactions.
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 tool's purpose: '从给定的选项列表中随机抽取一个或多个结果' (randomly draw one or more results from a given list of options). It specifies the verb ('抽取' - draw) and resource ('选项列表' - list of options), but doesn't explicitly distinguish it from sibling tools like flip_coin or roll_dice, which prevents a perfect score.
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 its siblings (flip_coin, roll_dice). It doesn't mention alternatives, prerequisites, or specific contexts where this tool is appropriate versus others. The description only states what the tool does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
抛硬币，返回正面或反面
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | 抛硬币次数，默认为1 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the basic behavior (flip coin, return heads/tails) but lacks details like whether it's deterministic, if there are rate limits, error conditions, or how multiple flips (with count parameter) are handled. For a tool with no annotations, this is minimal disclosure.
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 extremely concise and front-loaded: '抛硬币，返回正面或反面' (flip a coin, return heads or tails). It uses minimal words to convey the core purpose without any wasted sentences, making it efficient and easy to understand.
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 the tool's low complexity (simple random generation), no annotations, no output schema, and a single parameter with full schema coverage, the description is adequate but basic. It covers the main action and outcome, but lacks details on behavior for multiple flips or error handling, which could be useful for completeness in this context.
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 has 100% description coverage, with the 'count' parameter documented as '抛硬币次数，默认为1' (number of coin flips, default is 1). The description doesn't add any parameter semantics beyond this, as it doesn't mention parameters at all. With high schema coverage, the baseline score of 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?
The description clearly states the tool's purpose: '抛硬币，返回正面或反面' (flip a coin, return heads or tails). It specifies the action (flip coin) and the outcome (return heads/tails), which is straightforward. However, it doesn't explicitly differentiate from sibling tools like 'draw_lottery' or 'roll_dice', though the action is distinct enough to imply difference.
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 alternatives. It doesn't mention sibling tools or any context for choosing flip_coin over draw_lottery or roll_dice, such as for binary outcomes or simple random selection. This lack of comparative guidance limits its utility in a multi-tool environment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
投掷骰子，支持自定义面数和数量
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | 骰子数量，默认为1 | |
| sides | No | 骰子面数，默认为6 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool rolls dice with customizable parameters but doesn't describe output format, randomness characteristics, error conditions, or any side effects. For a tool with no annotation coverage, this leaves significant behavioral gaps.
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 extremely concise - a single sentence that efficiently communicates the core functionality. Every word earns its place with no redundant information or unnecessary elaboration.
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 annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (individual rolls, sum, distribution), error handling, or practical usage context. For a randomization tool with two parameters, more behavioral context would be helpful.
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 schema has 100% description coverage with clear parameter documentation, so the baseline is 3. The description adds minimal value beyond the schema by mentioning customizability of sides and count, but doesn't provide additional semantic context about parameter usage or constraints.
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 ('投掷骰子' - roll dice) and specifies key capabilities ('支持自定义面数和数量' - supports custom number of sides and quantity). It distinguishes from siblings by focusing on dice rather than lottery or coin operations, though it doesn't explicitly contrast with them.
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 sibling tools (draw_lottery, flip_coin). It mentions what the tool does but offers no context about appropriate use cases, alternatives, 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.0draw_lotteryflip_coinroll_diceScored across 3 tools
Each tool has a clearly distinct purpose: draw_lottery selects from a list of options, flip_coin returns heads or tails, and roll_dice handles dice with customizable faces and counts. There is no overlap or ambiguity between these random selection mechanisms.
All tools follow a consistent verb_noun pattern (draw_lottery, flip_coin, roll_dice) with clear, descriptive names that accurately reflect their functions. The naming is uniform and predictable throughout the set.
With 3 tools, the server is well-scoped for a lottery/gambling demo, covering common random selection scenarios (lottery draws, coin flips, dice rolls). Each tool earns its place without feeling excessive or insufficient for the domain.
The tool set provides complete coverage for basic random selection operations in a gambling context: drawing from options, binary coin flips, and customizable dice rolls. There are no obvious gaps for the stated demo purpose, and agents can handle typical use cases without dead ends.
500+ deterministic tools for AI agents: math, conversion, validation, hashing, encoding, date/time.
Verifiable random decisions, audit sampling, fair selection, and proof verification using QnEvt.
Utility tools for AI agents: hashing, text stats, validation, DNS, currency, GEO audits.
Exact hashing, base64/hex/URL encoding, JWT decoding and UUIDs for AI agents. No auth required.
