MCP 레지스트리는 MCP 클라이언트에게 MCP 서버 목록을 제공하며, MCP 서버를 위한 앱 스토어와 같은 역할을 합니다.
📤 내 MCP 서버 게시하기 | ⚡️ 라이브 API 문서 | 👀 생태계 비전 | 📖 전체 문서
2025-10-24 업데이트: 레지스트리 API가 API 동결(v0.1) 상태에 진입했습니다 🎉. 향후 한 달 이상 API는 변경 사항 없이 안정적으로 유지되어 통합 담당자가 안심하고 지원을 구현할 수 있게 됩니다. 이 동결은 v0 개발이 계속되는 동안 v0.1에 적용됩니다. 이 기간을 활용하여 실제 통합 환경에서 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을 참조하세요.
아이디어는 종종(항상 그렇지는 않지만) 다음 파이프라인을 통해 흐릅니다:
Discord - 실시간 커뮤니티 토론
Discussions - 제품/기술 요구 사항 제안 및 토론
Issues - 범위가 명확한 기술 작업 추적
Pull Requests - 이슈 해결을 위한 작업 기여
Docker
Go 1.24.x
ko - Go용 컨테이너 이미지 빌더 (설치 지침)
golangci-lint v2.4.0
# Start full development environment
make dev-compose이 명령은 PostgreSQL과 함께 localhost:8080에서 레지스트리를 시작합니다. 데이터베이스는 임시 스토리지를 사용하며 컨테이너를 다시 시작할 때마다 초기화되므로 개발 및 테스트를 위한 깨끗한 상태가 보장됩니다.
참고: 레지스트리는 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 Container Registry에 자동으로 게시됩니다:
# 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-<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를 게시하려면 GitHub에 domdomegg로 로그인하거나 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.
