El registro MCP proporciona a los clientes MCP una lista de servidores MCP, como una tienda de aplicaciones para servidores MCP.
📤 Publicar mi servidor MCP | ⚡️ Documentación de la API en vivo | 👀 Visión del ecosistema | 📖 Documentación completa
Actualización del 24-10-2025: La API del Registro ha entrado en congelación de API (v0.1) 🎉. Durante el próximo mes o más, la API permanecerá estable sin cambios disruptivos, lo que permitirá a los integradores implementar el soporte con confianza. Esta congelación se aplica a la v0.1 mientras continúa el desarrollo de la v0. Usaremos este período para validar la API en integraciones del mundo real y recopilar comentarios para dar forma a la v1 para su disponibilidad general. ¡Gracias a todos por sus contribuciones y paciencia; su participación ha sido clave para llegar hasta aquí!
Actualización del 08-09-2025: El registro se ha lanzado en vista previa 🎉 (publicación del blog de anuncio). Aunque el sistema es ahora más estable, sigue siendo una versión preliminar y pueden producirse cambios disruptivos o restablecimientos de datos. Una versión de disponibilidad general (GA) seguirá más adelante. Nos encantaría recibir sus comentarios en las discusiones de GitHub o en el Discord #registry-dev (detalles para unirse aquí).
Mantenedores clave actuales:
Adam Jones (Anthropic) @domdomegg
Tadas Antanavicius (PulseMCP) @tadasant
Toby Padilla (GitHub) @toby
Radoslav (Rado) Dimitrov (Stacklok) @rdimitrov
Related MCP server: telekash-mcp-server
Utilizamos múltiples canales para la colaboración: consulte modelcontextprotocol.io/community/communication.
A menudo (pero no siempre) las ideas fluyen a través de este proceso:
Discord - Discusiones comunitarias en tiempo real
Discusiones - Proponer y discutir requisitos técnicos/de producto
Problemas - Seguimiento de trabajo técnico bien definido
Solicitudes de extracción (Pull Requests) - Contribuir con trabajo para los problemas
Docker
Go 1.24.x
ko - Constructor de imágenes de contenedor para Go (instrucciones de instalación)
golangci-lint v2.4.0
# Start full development environment
make dev-composeEsto inicia el registro en localhost:8080 con PostgreSQL. La base de datos utiliza almacenamiento efímero y se restablece cada vez que reinicias los contenedores, lo que garantiza un estado limpio para el desarrollo y las pruebas.
Nota: El registro utiliza ko para crear imágenes de contenedor. El comando make dev-compose crea automáticamente la imagen del registro con ko y la carga en tu demonio Docker local antes de iniciar los servicios.
De forma predeterminada, el registro se alimenta de la API de producción con un subconjunto filtrado de servidores (para mantener el inicio rápido). Esto garantiza que tu entorno local refleje el comportamiento de producción y que todos los datos de inicio pasen la validación. Para el desarrollo sin conexión, puedes alimentar desde un archivo sin validación con MCP_REGISTRY_SEED_FROM=data/seed.json MCP_REGISTRY_ENABLE_REGISTRY_VALIDATION=false make dev-compose.
La configuración se puede ajustar con variables de entorno en docker-compose.yml - consulta .env.example para obtener una referencia.
Las imágenes de Docker preconstruidas se publican automáticamente en el Registro de contenedores de 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-abc123dEtiquetas disponibles:
Versiones: latest, v1.0.0, v1.1.0, etc.
Continuas: main (compilación más reciente de la rama principal)
Desarrollo: main-<fecha>-<sha> (compilaciones de confirmación específicas)
Para publicar un servidor, hemos creado una CLI sencilla. Puedes usarla con:
# Build the latest CLI
make publisher
# Use it!
./bin/mcp-publisher --helpConsulta la guía del editor para obtener más detalles.
# Run lint, unit tests and integration tests
make checkTambién hay algunos comandos más útiles para el desarrollo. Ejecuta make help para obtener más información, o mira en 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 toolsLa publicación admite múltiples métodos de autenticación:
GitHub OAuth - Para publicar iniciando sesión en GitHub
GitHub OIDC - Para publicar desde GitHub Actions
Verificación DNS - Para demostrar la propiedad de un dominio y sus subdominios
Verificación HTTP - Para demostrar la propiedad de un dominio
El registro valida la propiedad del espacio de nombres al publicar. Por ejemplo, para publicar...:
io.github.domdomegg/my-cool-mcp debes iniciar sesión en GitHub como domdomegg, o estar en una GitHub Action en los repositorios de domdomegg
me.adamjones/my-cool-mcp debes demostrar la propiedad de adamjones.me mediante un desafío DNS o HTTP
Consulta los proyectos comunitarios para explorar trabajos notables relacionados con el registro creados por la comunidad.
¡Consulta la documentación para obtener más detalles si tu pregunta no ha sido respondida aquí!
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.
