MCP 注册中心为 MCP 客户端提供 MCP 服务器列表，就像是 MCP 服务器的应用商店一样。
📤 发布我的 MCP 服务器 | ⚡️ 实时 API 文档 | 👀 生态愿景 | 📖 完整文档
2025-10-24 更新：注册中心 API 已进入 API 冻结期 (v0.1) 🎉。在接下来的一个月或更长时间内，API 将保持稳定，不会有破坏性变更，以便集成方能够放心地实现支持。此冻结适用于 v0.1 版本，同时 v0 的开发仍在继续。我们将利用这段时间在实际集成中验证 API，并收集反馈以塑造 v1 版本，从而实现全面可用。感谢大家的贡献和耐心——你们的参与是促成这一成果的关键！
2025-09-08 更新：注册中心已发布预览版 🎉 (公告博客文章)。虽然系统现在更加稳定，但这仍然是一个预览版本，可能会出现破坏性变更或数据重置。全面可用 (GA) 版本将在稍后发布。我们期待您在 GitHub 讨论区 或 #registry-dev Discord (加入详情请见此处) 中提供反馈。
当前主要维护者：
Adam Jones (Anthropic) @domdomegg
Tadas Antanavicius (PulseMCP) @tadasant
Toby Padilla (GitHub) @toby
Radoslav (Rado) Dimitrov (Stacklok) @rdimitrov
Related MCP server: telekash-mcp-server
我们使用多种渠道进行协作 - 请参阅 modelcontextprotocol.io/community/communication。
通常（但不总是）想法会通过以下流程：
Docker
Go 1.24.x
ko - Go 容器镜像构建器 (安装说明)
golangci-lint v2.4.0
# Start full development environment
make dev-compose这将启动注册中心于 localhost:8080 并使用 PostgreSQL。数据库使用临时存储，每次重启容器时都会重置，确保开发和测试环境处于干净状态。
注意： 注册中心使用 ko 构建容器镜像。make dev-compose 命令会自动使用 ko 构建注册中心镜像，并在启动服务前将其加载到您的本地 Docker 守护进程中。
默认情况下，注册中心会从生产 API 播种（seed）一个经过过滤的服务器子集（以保持启动速度）。这确保了您的本地环境反映了生产行为，并且所有种子数据都通过了验证。对于离线开发，您可以使用 MCP_REGISTRY_SEED_FROM=data/seed.json MCP_REGISTRY_ENABLE_REGISTRY_VALIDATION=false make dev-compose 从文件播种而不进行验证。
该设置可以通过 docker-compose.yml 中的环境变量进行配置 - 请参阅 .env.example 获取参考。
预构建的 Docker 镜像会自动发布到 GitHub 容器注册中心：
# Run latest stable release
docker run -p 8080:8080 ghcr.io/modelcontextprotocol/registry:latest
# Run latest from main branch (continuous deployment)
docker run -p 8080:8080 ghcr.io/modelcontextprotocol/registry:main
# Run specific release version
docker run -p 8080:8080 ghcr.io/modelcontextprotocol/registry:v1.0.0
# Run development build from main branch
docker run -p 8080:8080 ghcr.io/modelcontextprotocol/registry:main-20250906-abc123d可用标签：
发布版：latest, v1.0.0, v1.1.0 等。
持续集成：main（最新的 main 分支构建）
开发版：main-<date>-<sha>（特定提交构建）
为了发布服务器，我们构建了一个简单的 CLI。您可以使用它：
# Build the latest CLI
make publisher
# Use it!
./bin/mcp-publisher --help有关更多详细信息，请参阅 发布者指南。
# Run lint, unit tests and integration tests
make check还有一些其他有用的开发命令。运行 make help 以了解更多信息，或查看 Makefile。
├── cmd/ # Application entry points
│ └── publisher/ # Server publishing tool
├── data/ # Seed data
├── deploy/ # Deployment configuration (Pulumi)
├── docs/ # Documentation
├── internal/ # Private application code
│ ├── api/ # HTTP handlers and routing
│ ├── auth/ # Authentication (GitHub OAuth, JWT, namespace blocking)
│ ├── config/ # Configuration management
│ ├── database/ # Data persistence (PostgreSQL)
│ ├── service/ # Business logic
│ ├── telemetry/ # Metrics and monitoring
│ └── validators/ # Input validation
├── pkg/ # Public packages
│ ├── api/ # API types and structures
│ │ └── v0/ # Version 0 API types
│ └── model/ # Data models for server.json
├── scripts/ # Development and testing scripts
├── tests/ # Integration tests
└── tools/ # CLI tools and utilities
└── validate-*.sh # Schema validation tools发布支持多种身份验证方法：
GitHub OAuth - 通过登录 GitHub 进行发布
GitHub OIDC - 通过 GitHub Actions 进行发布
DNS 验证 - 用于证明域名及其子域名的所有权
HTTP 验证 - 用于证明域名的所有权
注册中心在发布时会验证命名空间所有权。例如，要发布...：
io.github.domdomegg/my-cool-mcp，您必须以 domdomegg 身份登录 GitHub，或者在 domdomegg 的仓库中运行 GitHub Action
me.adamjones/my-cool-mcp，您必须通过 DNS 或 HTTP 挑战证明 adamjones.me 的所有权
查看 社区项目 以探索社区创建的值得关注的注册中心相关工作。
如果这里没有回答您的问题，请参阅 文档 以获取更多详细信息！
Get real-time prediction market consensus probabilities.
Returns aggregated consensus from multiple regulated prediction markets. Each event shows the collective probability, trend direction, and how much markets agree (spread).
Args: sport: Filter by sport — NBA, NFL, MLB, NHL, MLS, POLITICS, or omit for all active events. limit: Number of events to return (1–20, default 10).
Returns: Formatted consensus data with probabilities, trends, and confidence.
| Name | Required | Description | Default |
|---|---|---|---|
| sport | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It mentions 'real-time' data and describes output fields (probability, trend direction, spread). It does not discuss rate limits, authentication, or error handling, but for a simple read-only tool, the coverage is adequate.
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 concise (~100 words) with a clear structure: a one-line purpose, a paragraph on what is returned, and labeled sections for args and returns. Every sentence adds value without redundancy.
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 only 2 optional parameters, no nested objects, and an output schema exists, the description covers all essential aspects: purpose, parameter details, and return fields. No gaps are apparent.
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 0% description coverage, so the description adds crucial meaning: it lists explicit enum values for 'sport' (NBA, NFL, etc.) and explains the 'limit' parameter range (1–20, default 10). This goes well beyond the bare 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 'Get real-time prediction market consensus probabilities', specifying both the action (get) and the resource (consensus probabilities). It distinguishes this tool from siblings like get_markets and get_opportunities by emphasizing that it returns aggregated consensus from multiple markets.
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 explains what the tool returns but does not explicitly state when to use this tool versus alternatives (e.g., get_markets). It provides no 'when not to use' guidance or explicit comparison to siblings, sticking only to a general purpose statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get active prediction markets currently being tracked.
Shows markets that are open and being monitored for consensus. Use this to see what events are currently available before querying consensus.
Args: sport: Filter by sport — NBA, NFL, MLB, NHL, MLS, POLITICS, or omit. limit: Number of markets to return (1–20, default 10).
Returns: Formatted list of active markets with status and sport.
| Name | Required | Description | Default |
|---|---|---|---|
| sport | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It states markets are 'open and being monitored' and returns a 'formatted list.' However, it does not mention any potential side effects, rate limits, or auth needs—acceptable for a read operation but not exhaustive.
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 concise, front-loaded with core purpose, and structured with sections for Args and Returns. No redundant sentences, though slightly more verbose than minimal.
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 output schema exists (context signal), description provides adequate context for a simple two-parameter tool. Explains parameters and return format, sufficient for the tool's complexity.
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 0%, so description must explain parameters. It describes 'sport' with explicit values (NBA, NFL, etc.) and 'limit' with range (1–20, default 10), adding significant value beyond 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 tool retrieves 'active prediction markets currently being tracked,' with a specific verb and resource. It distinguishes from siblings like 'get_consensus' by focusing on market listing.
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?
Explicitly advises using this tool before querying consensus ('Use this to see what events are currently available before querying consensus'). Provides clear usage context, though lacks explicit when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get events where prediction markets show notable divergence.
Divergence opportunities are events where regulated prediction markets disagree significantly. Higher scores indicate greater disagreement. This may surface events where information is still being incorporated.
Args: min_score: Minimum opportunity score to include (default 5.0). sport: Filter by sport — NBA, NFL, MLB, NHL, MLS, POLITICS, or omit. limit: Number of opportunities to return (1–20, default 10).
Returns: Formatted list of divergence opportunities ranked by score.
| Name | Required | Description | Default |
|---|---|---|---|
| min_score | No | ||
| sport | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It explains that the tool returns divergence opportunities ranked by score and that higher scores indicate greater disagreement. It does not discuss authorization, rate limits, or destructive effects (not applicable). The description is transparent enough for a read operation, though it could mention if results are cached or if there are any known limitations.
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 concise and well-structured. The purpose is stated in the first sentence, followed by a one-sentence explanation of divergence. The Args section clearly lists each parameter with its description, and the Returns section specifies the output format. Every sentence contributes meaning without redundancy.
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 that the tool has an output schema (assumed structured), the description still explains the return format ('Formatted list of divergence opportunities ranked by score'). All three parameters are documented with defaults and valid values. Similarly, the sibling tools are listed for context (though not compared). The description is complete for a list-returning tool with no required parameters.
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 0% description coverage, meaning the schema provides no documentation for parameters. However, the tool description fully compensates by listing each argument with its meaning, default values, and valid options (e.g., sport: 'NBA, NFL, MLB, NHL, MLS, POLITICS, or omit'; limit: '1–20, default 10'). This adds significant value beyond the bare 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 opens with a specific verb and resource: 'Get events where prediction markets show notable divergence.' It defines divergence opportunities concisely and distinguishes this from sibling tools by focusing on divergence and disagreement, which is unique among get_consensus, get_markets, get_settlements, and get_signals.
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 clear context: it surfaces events with notable disagreements, possibly where information is still being incorporated. This implies when to use it (when seeking mispricings or inefficient markets), but it does not explicitly state alternatives or when not to use it. The sibling tool names are listed, but no direct comparison is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recently settled prediction market events with verified outcomes.
Shows events that have concluded, with verified outcome data. Useful for checking how recent consensus predictions compared to actual results.
Args: limit: Number of settled events to return (1–10, default 5).
Returns: Formatted settlement history with outcomes and verification status.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does not fully disclose behavioral traits like rate limits, pagination, or how 'recently' is defined. It mentions 'verified outcome data' but lacks depth on what that entails—adequate but not thorough.
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 concise, starting with a clear purpose, followed by a use-case sentence, and then structured Args/Returns sections. Every sentence serves a purpose with no redundancy.
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?
The tool is simple with one optional parameter and an output schema (handling return values). The description covers purpose, parameter details, and a use case. Minor gap: no definition of 'recently', but overall 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 description adds significant value beyond the input schema, which has 0% description coverage. It specifies the range '1–10' and default value for 'limit', along with its meaning. The schema only shows default and type.
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 'Get recently settled prediction market events with verified outcomes,' using a specific verb and resource. It distinguishes from siblings like get_markets and get_consensus by focusing on settled events with outcomes.
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 a clear use case: 'checking how recent consensus predictions compared to actual results.' However, it lacks explicit exclusions or alternatives, such as noting when to use get_markets instead for active events.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent market signals showing direction of price moves.
Signals indicate notable directional moves in prediction market consensus. Each signal shows whether the market shifted toward YES or NO, and the current status of the market.
Args: limit: Number of signals to return (1–10, default 5).
Returns: Formatted recent signals with direction and event details.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 states that the tool retrieves signals with a limit parameter and returns formatted data. It does not mention whether the operation is read-only, any required authentication, rate limits, or side effects. The description lacks transparency about how 'recent' is defined or if the tool triggers state changes.
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 remarkably concise: a single-sentence summary followed by a short explanation and clear Args/Returns sections. Every sentence provides meaningful information without redundancy or fluff.
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 parameter, no required inputs, an output schema exists), the description covers the essentials: what signals are, the direction indicator, and the limit parameter. It does not define 'recent' or explain any pagination, but for a straightforward read tool this is mostly adequate. An output schema is present, so return details are not required.
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 zero description coverage for the 'limit' parameter, but the description adds crucial semantics: it specifies the allowed range (1–10) and the default value (5). This goes beyond the schema's minimal definition, though it could elaborate further on how the limit affects results or edge cases.
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 gets recent market signals showing direction of price moves. It specifies the verb 'Get' and the resource 'market signals'. The explanation that signals indicate shifts toward YES or NO distinguishes it from sibling tools like get_consensus or get_markets, providing good differentiation.
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 does not provide any guidance on when to use this tool versus siblings like get_consensus, get_markets, get_opportunities, or get_settlements. There is no mention of prerequisites, contexts, or explicit recommendations, leaving the agent to infer usage from the tool name alone.
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.
v0.1.0get_consensusget_marketsget_opportunitiesget_settlementsget_signalsScored across 5 tools
Each tool has a clearly distinct purpose: get_consensus retrieves aggregated probabilities, get_markets lists available markets, get_opportunities finds divergence events, get_settlements shows concluded outcomes, and get_signals tracks directional moves. There is no overlap in functionality, and the descriptions make each tool's unique role immediately apparent.
All tool names follow a consistent verb_noun pattern with 'get_' as the prefix (e.g., get_consensus, get_markets, get_opportunities). This uniformity makes the tool set predictable and easy for an agent to navigate without confusion.
With 5 tools, this server is well-scoped for its domain of prediction market data. Each tool serves a specific, non-redundant function, covering real-time consensus, active markets, divergence opportunities, settlements, and signals, which aligns with typical data retrieval needs in this context.
The tool set provides comprehensive coverage for querying prediction market data, including active, settled, and divergent events, as well as signals. A minor gap is the lack of tools for creating or interacting with markets (e.g., placing bets or managing accounts), but this is reasonable for a read-only data server focused on consensus and analysis.
Calibrated world model for AI agents. 40 tools: world state, markets, trading. Kalshi + Polymarket.
Live prediction-market odds, volume and movers across 8 platforms. Read-only, no auth.
Prediction market data and crowd-sourced probability forecasts
Live prediction markets: Polymarket + Kalshi prices, odds, order books. Pay-per-call USDC, no key.
