MCP Server Kalshi vs Rfdez Pvpc MCP Server | AllMCPs
Side-by-Side Model Context Protocol Comparison
MCP Server Kalshi vs Rfdez Pvpc MCP Server
In-depth architectural comparison of the MCP Server Kalshi and Rfdez Pvpc MCP Server MCP servers. Compare execution transports, security boundaries, tool capabilities, quality scores, and ready-to-paste client installation snippets for Claude, Cursor, Windsurf, and VS Code.
At a Glance & Executive Verdict
MCP Server Kalshi
Finance & Fintech · Local stdio
Quality: 48/100 (Fair) | Auth: API Key required
Rfdez Pvpc MCP Server
Finance & Fintech · Local stdio
Quality: 55/100 (Good) | Auth: No auth required
Verdict Summary: Choose MCP Server Kalshi if you need specialized Finance & Fintech tools running via a local process. Choose Rfdez Pvpc MCP Server if your workspace requires Finance & Fintech integration with local subprocess execution. Both servers can be configured concurrently in your client's mcpServers manifest.
Which MCP Server Should You Choose?
Choose MCP Server Kalshi when:
You need dedicated capabilities in the Finance & Fintech domain.
You prefer local stdio subprocess transport architecture.
Your security boundary fits: API Key required (Free / Open Source).
You have access to required keys: KALSHI_ENV, KALSHI_API_KEY, KALSHI_PRIVATE_KEY_PATH, BASE_URL.
Primary tools included: Market, event, and series discovery, Order book, candlestick, and trade research, Settlement rule and contract PDF extraction.
MCP Server Kalshi is categorized under Finance & Fintech and uses a local stdio subprocess. In contrast, Rfdez Pvpc MCP Server belongs to Finance & Fintech using local stdio subprocess. Select MCP Server Kalshi when you need capabilities focused on finance & fintech and Rfdez Pvpc MCP Server when you require tools for finance & fintech.
Fetches the Voluntary Price for the Small Consumer (PVPC) prices for a given date range and geographical area.
locale
Get translations for sources. Accepted values: `es`, `en`. Defaults to `es`.
startDate
Beginning of the date range to filter indicator values in iso8601 format. E.g. 2025-06-29T00:00:00.000+02:00. Defaults to the start of today.
endDate
End of the date range to filter indicator values in iso8601 format. E.g. 2025-06-29T23:59:59.999+02:00. Defaults to the end of today.
timeAggregation
How to aggregate indicator values when grouping them by time. Accepted values: `sum`, `average`. Defaults to `sum`.
timeTruncation
Tells how to truncate data time series. Accepted values: `hour`, `day`, `month`, `year`. Optional parameter.
geographicalAggregation
How to aggregate indicator values when grouping them by geographical ID. Accepted values: `sum`, `average`. Defaults to `sum`.
geographicalIds
Tells the geographical IDs to filter indicator values. Accepted values: `3` (España), `8741` (Península), `8742` (Canarias), `8743` (Baleares), `8744` (Ceuta), `8745` (Melilla). Defaults to `8741`, `8742`, `8743`, `8744`, `8745`.
geographicalTruncation
Tells how to group data at geographical level when the geographical aggregation is informed. Accepted values: `country`, `electric_system`. Optional parameter.