Provides real-time prediction market consensus probabilities, market signals, and directional moves for MLB games and events.
Provides real-time prediction market consensus probabilities, market signals, and directional moves for NBA games and events.
Provides real-time prediction market consensus probabilities, market signals, and directional moves for NHL games and events.
The MCP registry provides MCP clients with a list of MCP servers, like an app store for MCP servers.
📤 Publish my MCP server | ⚡️ Live API docs | 👀 Ecosystem vision | 📖 Full documentation
2025-10-24 update: The Registry API has entered an API freeze (v0.1) 🎉. For the next month or more, the API will remain stable with no breaking changes, allowing integrators to confidently implement support. This freeze applies to v0.1 while development continues on v0. We'll use this period to validate the API in real-world integrations and gather feedback to shape v1 for general availability. Thank you to everyone for your contributions and patience—your involvement has been key to getting us here!
2025-09-08 update: The registry has launched in preview 🎉 (announcement blog post). While the system is now more stable, this is still a preview release and breaking changes or data resets may occur. A general availability (GA) release will follow later. We'd love your feedback in GitHub discussions or in the #registry-dev Discord (joining details here).
Current key maintainers:
Adam Jones (Anthropic) @domdomegg
Tadas Antanavicius (PulseMCP) @tadasant
Toby Padilla (GitHub) @toby
Radoslav (Rado) Dimitrov (Stacklok) @rdimitrov
Related MCP server: telekash-mcp-server
We use multiple channels for collaboration - see modelcontextprotocol.io/community/communication.
Often (but not always) ideas flow through this pipeline:
Discord - Real-time community discussions
Discussions - Propose and discuss product/technical requirements
Issues - Track well-scoped technical work
Pull Requests - Contribute work towards issues
Docker
Go 1.24.x
ko - Container image builder for Go (installation instructions)
golangci-lint v2.4.0
# Start full development environment
make dev-composeThis starts the registry at localhost:8080 with PostgreSQL. The database uses ephemeral storage and is reset each time you restart the containers, ensuring a clean state for development and testing.
Note: The registry uses ko to build container images. The make dev-compose command automatically builds the registry image with ko and loads it into your local Docker daemon before starting the services.
By default, the registry seeds from the production API with a filtered subset of servers (to keep startup fast). This ensures your local environment mirrors production behavior and all seed data passes validation. For offline development you can seed from a file without validation with MCP_REGISTRY_SEED_FROM=data/seed.json MCP_REGISTRY_ENABLE_REGISTRY_VALIDATION=false make dev-compose.
The setup can be configured with environment variables in docker-compose.yml - see .env.example for a reference.
Pre-built Docker images are automatically published to 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-abc123dAvailable tags:
Releases: latest, v1.0.0, v1.1.0, etc.
Continuous: main (latest main branch build)
Development: main-<date>-<sha> (specific commit builds)
To publish a server, we've built a simple CLI. You can use it with:
# Build the latest CLI
make publisher
# Use it!
./bin/mcp-publisher --helpSee the publisher guide for more details.
# Run lint, unit tests and integration tests
make checkThere are also a few more helpful commands for development. Run make help to learn more, or look in 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 toolsPublishing supports multiple authentication methods:
GitHub OAuth - For publishing by logging into GitHub
GitHub OIDC - For publishing from GitHub Actions
DNS verification - For proving ownership of a domain and its subdomains
HTTP verification - For proving ownership of a domain
The registry validates namespace ownership when publishing. E.g. to publish...:
io.github.domdomegg/my-cool-mcp you must login to GitHub as domdomegg, or be in a GitHub Action on domdomegg's repos
me.adamjones/my-cool-mcp you must prove ownership of adamjones.me via DNS or HTTP challenge
Check out community projects to explore notable registry-related work created by the community.
See the documentation for more details if your question has not been answered here!
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.
