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., "@lottery-mcp-server 给出最近5期的双色球开奖号码"
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.
这是一个基于 Model Context Protocol (MCP) 的双色球彩票历史数据查询服务器，提供从2013年至今的所有一等奖开奖数据。
提供7个MCP工具：
get_all_lottery_history - 获取所有历史一等奖数据
get_lottery_by_date_range - 按日期范围查询开奖数据
get_lottery_by_code - 按期号查询开奖数据
get_latest_lottery - 获取最新N期开奖数据
analyze_and_predict - 分析历史数据并基于高频号码生成参考号码（仅供参考）
calculate_sum_value - 计算最近N期开奖号码的和值（红球号码之和）
calculate_ac_value - 计算最近N期开奖号码的AC值（算术复杂性）
Related MCP server: MCP Blockchain Query Server
每条记录包含以下字段：
{
"date": "2025-11-16(日)",
"code": "2025132",
"red": "04,08,10,21,23,32",
"blue": "11"
}npm install本项目实现了自动化的Cookie管理系统：
✅ 自动获取：首次运行时自动获取有效的Cookie
✅ 自动缓存：Cookie保存到 cookie-cache.json
✅ 自动刷新：Cookie过期（2小时）后自动获取新的
✅ 无需手动配置：无需手动更新Cookie值
如果需要手动更新Cookie，运行：
node get-cookie.js该命令会：
获取最新的有效Cookie
验证Cookie是否可用（通过API测试）
自动保存到 cookie-cache.json
显示Cookie的有效期
本项目实现了智能的数据缓存系统，大幅减少API调用频率：
✅ 双层缓存：内存缓存（二级）+ 文件缓存（一级）
✅ 自然日缓存：同一自然日内的缓存有效
✅ 开奖日智能处理：
非开奖日（周一、周三、周五、周六）：全天使用缓存
开奖日（周二、周四、周日）：
21:15:00之前：使用缓存
21:15:00之后：获取新数据（因为有新的开奖结果）
位置：lottery-data-cache.json
内容：包含完整的开奖数据、缓存日期和时间戳
首先检查内存缓存（最快）
其次检查文件缓存（快速）
最后从API获取新数据（自动保存到文件缓存）
npm run devnpm run buildnpm start@lottery 给出最近5期的双色球开奖号码
@lottery 进行全历史统计分析并生成10组推荐号码
@lottery 计算最近10期的和值
@lottery 计算最近10期的AC值
获取所有历史开奖数据（2013年至今）
参数：无
返回：LotteryData数组
按日期范围查询开奖数据
参数：
startDate (string): 开始日期，格式 YYYY-MM-DD，例如 "2025-01-01"
endDate (string): 结束日期，格式 YYYY-MM-DD，例如 "2025-12-31"
返回：符合日期范围的LotteryData数组
按期号查询开奖数据
参数：
code (string): 期号，例如 "2025132"
返回：单条LotteryData或null（未找到）
获取最新N期开奖数据
参数：
count (number, 可选): 获取期数，默认10
返回：最新N期的LotteryData数组
分析历史数据并基于统计规律生成推荐号码
参数：无
返回：AnalysisResult对象，包含：
totalDraws: 总开奖期数
redBallStats: 红球频率统计（前20个高频号码）
blueBallStats: 蓝球频率统计（前10个高频号码）
recommendations: 10组推荐号码组合
disclaimer: 重要提醒声明
推荐号码生成规则：
号码池选择
红球：选择历史出现频率最高的前20个红球作为候选
蓝球：选择历史出现频率最高的前8个蓝球作为候选
排除历史开奖号码
确保推荐的号码组合不曾在历史开奖数据中出现过
和值控制
红球和值严格控制在60-140之间
这是基于100%的历史开奖号码都落在此区间的统计结果
AC值控制
AC值严格控制在7-9之间
这是基于超过85%的历史开奖号码AC值落在此区间的统计结果
AC值计算公式：不同差值的个数 - (6 - 1)
生成过程
从高频红球池中随机选择6个不重复的号码
从高频蓝球池中随机选择1个号码
检查组合是否满足所有条件
重复生成直到获得10组有效组合或达到最大尝试次数
返回示例：
{
"totalDraws": 1500,
"redBallStats": [
{ "number": "07", "count": 245, "percentage": 16.33 },
...
],
"blueBallStats": [
{ "number": "12", "count": 120, "percentage": 8.00 },
...
],
"recommendations": [
{ "red": "01,07,12,23,26,32", "blue": "12" },
...
],
"disclaimer": "⚠️ 重要提醒：彩票开奖是完全随机的..."
}统计参考：
和值范围：60-140（100%覆盖历史开奖）
AC值范围：7-9（覆盖85%以上历史开奖）
号码选择：基于历史频率，优先选择高频号码
重要说明：
此工具基于历史数据统计规律生成号码
所有推荐号码都经过严格的条件筛选
彩票开奖是完全随机的，历史数据不能预测未来
任何号码组合的中奖概率都是相同的（约1/17,721,088）
请理性购彩，切勿沉迷
计算最近N期开奖号码的和值（红球号码之和）
参数：
count (number, 可选): 期数，默认10
返回：SumValueResult对象，包含：
count: 计算的期数
data: 每期的开奖号码和对应的和值
statistics: 统计信息
averageSumValue: 平均和值
minSumValue: 最小和值
maxSumValue: 最大和值
standardDeviation: 标准差
返回示例：
{
"count": 10,
"data": [
{
"date": "2025-12-04(四)",
"code": "2025140",
"red": "01,03,04,12,18,24",
"sumValue": 62
},
...
],
"statistics": {
"averageSumValue": 115.5,
"minSumValue": 62,
"maxSumValue": 168,
"standardDeviation": 35.2
}
}和值分析意义：
理论最小和值：21（1+2+3+4+5+6）
理论最大和值：183（28+29+30+31+32+33）
实战常见范围：80-140（约90%的开奖号码落在此区间）
和值反映号码整体的"大小"倾向
计算最近N期开奖号码的AC值（算术复杂性）
参数：
count (number, 可选): 期数，默认10
返回：ACValueResult对象，包含：
count: 计算的期数
data: 每期的开奖号码和对应的AC值
statistics: 统计信息
averageACValue: 平均AC值
minACValue: 最小AC值
maxACValue: 最大AC值
distribution: AC值分布（各AC值出现的次数）
返回示例：
{
"count": 10,
"data": [
{
"date": "2025-12-04(四)",
"code": "2025140",
"red": "01,03,04,12,18,24",
"acValue": 8
},
...
],
"statistics": {
"averageACValue": 7.8,
"minACValue": 6,
"maxACValue": 9,
"distribution": {
"6": 1,
"7": 3,
"8": 4,
"9": 2
}
}
}AC值分析意义：
AC值 = 不同差值的个数 - (号码数量 - 1)
反映号码的离散程度和结构复杂性
理论最小值：0（号码极其规律，如01,02,03,04,05,06）
理论最大值：10（号码极度分散）
黄金实战区间：7, 8, 9（超过85%的开奖号码AC值落在此区间）
AC值过低（<5）或过高（10）的组合中奖概率极低
在你的MCP客户端配置文件中添加：
{
"mcpServers": {
"lottery": {
"command": "node",
"args": ["d:/Project/nodejs/lottery-mcp-server/dist/server.js"]
}
}
}或使用开发模式：
{
"mcpServers": {
"lottery": {
"command": "npm",
"args": ["run", "dev"],
"cwd": "d:/Project/nodejs/lottery-mcp-server"
}
}
}TypeScript
Node.js
@modelcontextprotocol/sdk
HTTPS (内置模块)
数据来自中国福利彩票官方网站
服务器首次请求时会从API获取数据并缓存
后续查询将使用缓存数据，提高响应速度
数据包含从2013-01-01到最新一期的所有开奖记录
分析双色球历史数据并基于高频号码生成10组参考号码（仅供参考，不代表预测）
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 mentions analyzing historical data and generating reference numbers, but does not indicate side effects or safety (e.g., read-only, destructive). The 'for reference only' note adds some transparency about reliability, but behavioral details are sparse.
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 in Chinese, concise and front-loaded with the action. No wasted words or redundant 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 no parameters, no output schema, and no annotations, the description is minimal. It explains what it does (generates 10 sets based on frequency), but does not describe output format, number range, or algorithm details. Sufficient for a simple tool, but could be more complete.
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 zero parameters, so schema_description_coverage is 100%. The description does not need to add parameter details. With 0 params, baseline is 4, and the description does not detract.
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 verb (analyze and generate) and the resources (historical data of Double Color Ball, 10 sets of reference numbers). It distinguishes from sibling tools like get_all_lottery_history (which retrieves raw data) and calculate_ac_value (which computes a specific metric).
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 mentions the output is for reference only, which is a caveat, but does not explicitly state when to use this tool versus alternatives like get_all_lottery_history or get_latest_lottery. No 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.
计算最近N期双色球开奖号码的AC值（算术复杂性），默认N=10。AC值反映号码的离散程度和结构复杂性，黄金区间为7-9
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | 期数，默认为10 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description explains the meaning of AC value and its golden interval, but does not detail return format or edge cases. The description effectively conveys the tool's behavior.
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?
Description is a single concise sentence that front-loads the core purpose and default, with an explanatory follow-up. No wasted words.
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 calculation tool with one optional parameter and no output schema, the description covers purpose, default, and meaning. It lacks return format details but is sufficient for the tool's simplicity.
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 covers 100% of parameters with descriptions, so baseline is 3. The tool description adds context about AC value but does not provide additional parameter-specific information beyond the 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?
Description clearly states it calculates AC value for recent N periods, with a specific verb and resource, and distinguishes from siblings like calculate_sum_value.
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?
Description implies usage through its name and purpose, but lacks explicit when-to-use or when-not-to-use guidance compared to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
计算最近N期双色球开奖号码的和值（红球号码之和），默认N=10
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | 期数，默认为10 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the calculation but does not mention side effects, permissions, or return format. However, the tool appears to be a pure read-only calculation, so minimal behavioral context is acceptable.
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 that efficiently conveys the core functionality without unnecessary words.
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 simplicity (one optional parameter, no output schema), the description adequately covers the needed context: it explains the calculation and default value. Missing return type is a minor gap, but not critical for this tool.
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%; the parameter 'count' is documented with description and default in both schema and description. The description adds minimal extra meaning beyond the 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 verb 'calculate', the resource 'sum of red ball numbers', and the scope 'last N draws', with a default N=10. It distinguishes this tool from siblings like 'calculate_ac_value' which likely computes a different metric.
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 calculating sum values over recent draws but does not provide explicit guidance on when to use this tool versus alternatives, nor does it include when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取双色球所有历史一等奖数据(从2013年至今)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It accurately states the tool retrieves all historical first prize data without parameters, but lacks details on potential rate limits, data volume, or whether results are paginated. Adequate for a simple query.
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 efficiently conveys the tool's purpose and scope (time range). No extraneous words. While very concise, it could optionally add a brief usage note, but it's already well-structured.
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 has no parameters, no output schema, and no annotations, the description is fairly complete. It specifies the resource, verb, and time range. However, for a tool that retrieves all history, a note about potential response size or structure would improve 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?
No parameters exist, so the input schema is effectively complete. The description adds no extra parameter meaning, but none is needed. Baseline score for 0-param tools is 4 per guidelines, and this is appropriately concise.
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 verb ('get'), the resource ('all historical first prize data of Double Color Ball'), and the scope ('from 2013 to present'). It distinguishes from sibling tools like 'get_lottery_by_code' or 'get_lottery_by_date_range' by being the comprehensive historical query.
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 minimal guidance. It implies use for fetching all historical first prize data but does not specify when to prefer this over siblings (e.g., 'get_lottery_by_date_range') or when not to use it (e.g., due to data size).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取最新N期双色球开奖数据
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | 获取期数，默认为10 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose any behavioral traits such as read-only nature, return format, pagination, or side effects. For a simple query tool, this is insufficient.
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?
Single sentence, front-loaded with action and resource, no redundant words. Efficient and to the point.
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 one parameter and no output schema or annotations, the description is minimal. It explains what the tool does but omits return details and usage boundaries (e.g., max N). Adequate but leaves gaps for an agent.
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% for the count parameter. The tool description integrates the parameter by explaining it controls the number of latest periods ('最新N期'), adding context beyond the schema description.
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?
Description clearly states verb '获取' (get) and specific resource '最新N期双色球开奖数据' (latest N periods of Double Color Ball data). Distinguished from siblings like get_lottery_by_code and get_lottery_by_date_range.
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 provided. Sibling tools exist but no comparison or alternative suggestions are given, leaving the agent to infer usage.
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 |
|---|---|---|---|
| code | Yes | 期号，例如: 2025132 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It only indicates a read operation, but fails to mention any side effects, authorization needs, rate limits, or error conditions. The description is minimal.
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, clear sentence that gets straight to the point. It is efficient, though it lacks additional context. It is appropriately sized for a simple tool, but could be improved with more 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 the lack of output schema and the presence of sibling tools, the description is too sparse. It does not explain return format, error handling, or how it differs from similar tools. A more complete description would include what data is returned and usage tips.
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% for the single parameter, which already includes an example ('2025132'). The tool description reiterates the parameter's purpose ('按期号') but adds no extra semantics beyond the schema. Baseline 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: querying double-color ball lottery data by period number. It uses a specific verb ('查询') and resource ('双色球开奖数据'), distinguishing it from siblings like 'get_lottery_by_date_range' and 'get_latest_lottery'.
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 guidance on when to use this tool versus alternatives. The description simply states the action, missing context about preferred use cases or conditions that would lead an agent to choose this over sibling tools.
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 |
|---|---|---|---|
| startDate | Yes | 开始日期，格式: YYYY-MM-DD，例如: 2025-01-01 | |
| endDate | Yes | 结束日期，格式: YYYY-MM-DD，例如: 2025-12-31 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It only states 'query data' without disclosing behavioral traits like read-only nature, rate limits, or output characteristics. For a data retrieval tool, more transparency is needed.
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?
Single concise sentence front-loads the tool's purpose without extraneous information. Every character is functional.
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?
No output schema, yet description omits return format, pagination, or any behavioral context. For a date-range query tool, crucial details about result set size or ordering are 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% with both parameters fully described (format and example). The description adds 'date range' context but does not enhance parameter semantics beyond the 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?
Description clearly states the tool queries double color ball lottery data by date range using a specific verb and resource. However, it does not differentiate from sibling tools like 'get_all_lottery_history' or 'get_lottery_by_code'.
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 guidance on when to use this tool versus alternatives. Lacks context on when not to use or mention of sibling tools, leaving the agent without decision support.
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.0analyze_and_predictcalculate_ac_valuecalculate_sum_valueget_all_lottery_historyget_latest_lotteryget_lottery_by_codeget_lottery_by_date_rangeScored across 7 tools
Each tool has a clear, distinct purpose: data retrieval (by criteria) vs. analysis (AC value, sum value, prediction). No overlapping functionality.
All tools use a consistent 'verb_noun' pattern with underscores (e.g., get_latest_lottery, calculate_ac_value). Names are descriptive and uniform.
7 tools appropriately cover the domain: 4 for data retrieval (various filters) and 3 for analysis. Neither too sparse nor excessive.
Covers core retrieval and analysis needs. Minor gaps like dedicated frequency/trend tools missing, but prediction tool partially addresses this.
Historical football results, teams, competitions and draw/streak statistics via 10 read-only tools.
Model Context Protocol server for Studex tools, notifications, and profile integrations
A Model Context Protocol server for Wix AI tools
Winning numbers for 30+ world lotteries, minutes after each draw. Free, no key, CC BY 4.0.