pegcheck
pegcheck-mcp
Un servidor MCP de solo lectura que comprueba si un Robinhood Chain Stock Token se está negociando actualmente a un precio justo en relación con la acción del mundo real que representa, diseñado para ser llamado por un agente de IA, justo antes de que opere, no para ser leído desde un panel por un humano.
✅ Verdict: FAIR (deviation: 0.11%)El problema
Los Stock Tokens de Robinhood Chain son ERC-20 autocustodiables que siguen acciones reales y se negocian 24/7 en DEX onchain. Los mercados de valores reales solo están abiertos ~6,5 horas al día, 5 días a la semana. Fuera de esas horas no hay un mercado activo para arbitrar el precio del token de vuelta a su valor justo, por lo que puede desviarse.
Un agente de IA que negocia estos tokens directamente onchain (con una clave de cartera y haciendo swaps contra un pool de DEX) no tiene una forma integrada de saber si el precio que está a punto de pagar es fiable. Todas las herramientas existentes que muestran esta brecha (paneles, bots de alerta de Telegram, terminales de trading) están diseñadas para que las mire un humano. Ninguna de ellas está diseñada para ser llamada por un agente en medio de una decisión.
Related MCP server: rhc-mcp
La solución
Una herramienta MCP enfocada: check_stock_token_price.
Dale un ticker. Devuelve un veredicto estructurado y consciente de la sesión sobre el que un agente puede actuar, antes de firmar una operación, ya sea a través del propio Trading MCP de Robinhood o directamente contra un DEX onchain.
{
"symbol": "AAPL",
"onchain": { "priceUsd": 310.32, "method": "liquidity-weighted-average", "poolsUsed": 10 },
"reference": { "tokenEquivalentPriceUsd": 309.99, "isTradingHalt": false },
"deviation": { "pct": 0.11, "direction": "premium" },
"marketSession": { "state": "weekend" },
"verdict": "fair",
"warnings": []
}Este servidor es de solo lectura. Nunca tiene una clave privada, nunca firma una transacción y nunca realiza una operación.
Cómo funciona
Dos fuentes de datos independientes, comparadas:
Precio onchain — cada pool indexado de Robinhood Chain para el token, desde la API pública de DexScreener, filtrado a pools cotizados en un activo de referencia estable (USDG/USDC) con al menos $500 de liquidez, combinados en un promedio ponderado por liquidez (para que un pool profundo domine sobre varios poco profundos y ruidosos). Si nada pasa el filtro, se recurre al pool más profundo, marcado como de baja confianza.
Precio de referencia — la propia API de Stock Token pública de Robinhood (
/rhj/prices/{symbol}), que informa el bid/ask bruto del subyacente. Esto se escala por elmultiplieractual del token ERC-8056 (de/rhj/assets) para obtener el precio justo equivalente al token, ya que los dividendos se reinvierten en el multiplicador en lugar de pagarse en efectivo.
La desviación entre ambos se compara con una tabla de umbrales que depende de la sesión actual del mercado estadounidense (regular, pre-market, after-hours, weekend, holiday, closed), calculada localmente sin dependencia externa: una brecha del 2% un sábado por la noche es esperada; la misma brecha a las 11 a.m. de un martes no lo es. La detección de sesión incluye un calendario completo de festivos de NYSE, calculado algorítmicamente (reglas de enésimo día de la semana del mes, un cálculo de Pascua para el Viernes Santo y el cambio estándar de observancia de fin de semana) en lugar de obtenerse de cualquier API externa, por lo que funciona para cualquier año sin dependencia de red, sin clave API y sin archivo estático que quede obsoleto. Verificado contra el calendario oficial publicado por NYSE para 2026-2028 en test/nyseHolidays.test.ts. Consulta src/config.ts para los umbrales exactos y src/nyseHolidays.ts para las reglas de festivos.
Instalación y ejecución
git clone https://github.com/kushal613/pegcheck-mcp.git
cd pegcheck-mcp
npm install
npm run buildSin claves API, sin archivo .env, sin cartera: cada fuente de datos utilizada es una API gratuita, pública y sin clave.
Pruébalo desde la terminal
npm run check -- AAPL
npm run check -- TSLAConéctalo a un cliente MCP
Claude Desktop / Claude Code (claude_desktop_config.json o .mcp.json):
{
"mcpServers": {
"pegcheck": {
"command": "node",
"args": ["/absolute/path/to/pegcheck-mcp/dist/index.js"]
}
}
}Cursor (.cursor/mcp.json): misma forma que arriba.
Una vez conectado, pídele a tu agente: "Antes de comprar cualquier token de acción TSLA, consulta pegcheck para ver si el precio es justo en este momento."
Referencia de la herramienta
check_stock_token_price
Campo | Tipo | Descripción |
|
| Ticker, p. ej. |
|
| Precio onchain ponderado por liquidez. |
|
|
|
|
| Precio medio de la acción real, escalado por el multiplicador de acciones corporativas. |
|
| Desviación % con signo, onchain vs. referencia. |
|
|
|
|
| p. ej. |
|
|
|
|
| Advertencias legibles por humanos (cotización obsoleta, suspensión de negociación, pool de baja confianza, etc.). |
Arquitectura
src/
config.ts Every tunable threshold, in one place
types.ts Shared types for the whole pipeline
http.ts Fetch wrapper with timeout + consistent errors
robinhoodApi.ts Reference leg: /rhj/assets + /rhj/prices (Robinhood's own APIs)
dexscreener.ts Onchain leg: liquidity-weighted price across Robinhood Chain pools
marketSession.ts Local US-market-session calculation (no external dependency)
nyseHolidays.ts Algorithmic NYSE holiday calendar (no external dependency)
pegCheck.ts Combines both legs into one PegCheckResult
server.ts MCP tool registration
index.ts stdio entrypoint
cli.ts Standalone terminal usage (no MCP client needed)
scripts/
smoke-test.mjs End-to-end MCP protocol handshake test (initialize -> tools/list -> tools/call)Limitaciones conocidas (v0.1)
Sin manejo de cierre anticipado. Los cierres de la NYSE a la 1:00 PM (el día después de Acción de Gracias, una víspera de Navidad entre semana) no se modelan como una sesión distinta: esas tardes seguirán informando
after-hours/closedunas horas más tarde que el cierre anticipado real. Los cierres de día completo por festivos están totalmente cubiertos.Sin estimación de deslizamiento específica del lugar. Esto informa el precio agregado ponderado por liquidez, no "cuánto costaría mi operación de $500 contra este pool específico". Ese es un límite deliberado del alcance de v0.1 (un v0.2 natural: un modo
advancedque tome un tamaño de operación y un pool/lugar específico y estime el impacto en el precio).Dependencia de la cobertura de DexScreener. Si DexScreener aún no ha indexado un pool muy nuevo,
onchain.methodserá"none"y el veredicto seráno_liquidity. Esto es un "fallo ruidoso", no una respuesta incorrecta silenciosa.No sustituye la diligencia debida. Consulta el descargo de responsabilidad a continuación.
Descargo de responsabilidad
Este proyecto no está afiliado ni respaldado por Robinhood. Es una herramienta independiente e informativa. Los datos provienen de las API públicas de Robinhood y de la API pública de DexScreener y pueden estar retrasados, incompletos o ser inexactos. Nada de esto es asesoramiento financiero. Este servidor no puede realizar operaciones y no tiene fondos ni claves.
Licencia
MIT — consulta LICENSE.
Available Tools
1 toolcheck_stock_token_priceA
Checks whether a Robinhood Chain Stock Token's current onchain trading price is consistent with its real-world reference stock price. Combines a liquidity-weighted average of the token's onchain DEX pools with Robinhood's own live reference quote (adjusted for the token's corporate-action multiplier), and returns a session-aware fairness verdict ('fair' | 'caution' | 'unreliable' | 'no_liquidity' | 'unknown_symbol') plus the deviation percentage and supporting data. Call this BEFORE executing a trade of a Stock Token, whether through Robinhood's own Trading MCP or directly against an onchain DEX, to avoid trading at a price that has drifted from fair value -- which is most likely to happen outside regular US market hours. Read-only: this tool never places, modifies, or signs any trade.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | The Stock Token ticker symbol, e.g. "AAPL", "TSLA", "NVDA". |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states 'Read-only: this tool never places, modifies, or signs any trade,' which is a critical safety trait. It also discloses the algorithm (combining onchain DEX pools with a live reference quote) and the return format (session-aware verdict plus deviation percentage and supporting data), going beyond minimal requirements.
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 yet comprehensive, front-loading the core purpose before moving to method, usage guidance, and safety note. Every sentence serves a purpose: the first defines the check, the second explains the mechanism and output, the third gives explicit usage context, and the fourth declares read-only behavior. No filler or redundant text.
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 has a single parameter and no output schema, so the description must explain both input context and expected output. It does so by describing the verdict options ('fair' | 'caution' | 'unreliable' | 'no_liquidity' | 'unknown_symbol'), the deviation percentage, and the session-aware nature. It also covers when to use it, fulfilling the informational needs for correct invocation.
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 already has 100% description coverage for the single parameter 'symbol' with examples. The tool description does not add new semantic meaning to the parameter itself; it explains the tool's purpose but not additional nuances like format constraints or edge cases. The baseline of 3 is appropriate since the parameter is fully documented in the 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 states a very specific verb+resource: it checks whether a Robinhood Chain Stock Token's onchain trading price is consistent with its real-world reference stock price. It also details the method (liquidity-weighted average of DEX pools combined with Robinhood's live quote) and the output (a fairness verdict and deviation percentage), leaving no ambiguity about what the tool does.
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 explicitly says to call this BEFORE executing a trade of a Stock Token, whether via Robinhood's Trading MCP or directly against a DEX, to avoid trading at a price that has drifted from fair value. It also notes this is most likely outside regular US market hours. It does not provide explicit when-not-to-use or alternatives, but since there are no sibling tools, this is acceptable; a 4 reflects clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v0.1.0- First observed
check_stock_token_price
TDQS
Scored across 1 tool
With only a single tool, there is no possibility of confusion or overlap. The tool's purpose is clearly distinct from anything else, meeting the 'clearly distinct purpose' criterion perfectly.
The tool name 'check_stock_token_price' follows a clean verb_noun pattern, and with only one tool there is no inconsistency. The name accurately describes the action and object.
A single tool feels thin for most servers, but here the scope is narrowly defined around one specific check. It is borderline acceptable but on the low end of the typical range, making it a 3 per calibration guidelines.
The tool fully addresses its stated purpose—checking price fairness before trading. It provides a verdict, deviation percentage, and supporting data, with no obvious missing operations for that specific task. It is not a CRUD domain, so the completeness is judged against the narrow mission.
Maintenance
Related MCP Connectors
13-model stock valuation engine for AI agents - fair values for 5,900+ US stocks, updated daily.
Non-custodial limit, stop-loss and DCA trading on Epsilon (Robinhood Chain) for AI agents
Token intelligence for Robinhood Chain: onchain and social data on any token, timestamped.
Deterministic decision guardrail for AI agents and bots. Verifies pre-trade economics (long-only).
Related MCP Servers
- AlicenseAqualityFmaintenanceEnables AI agents to interact with Robinhood Chain via USDG payments, offering tools for balance, pricing, trading, and more.1858MIT
- AlicenseAqualityDmaintenanceEnables AI agents to read Robinhood Chain stock-token positions, quote swaps, and execute swaps through the Model Context Protocol, bridging on-chain assets that Robinhood's own off-chain MCP cannot reach.4MIT

hoodr MCP Serverofficial
AlicenseNot gradedqualityAmaintenanceEnables AI agents to trade tokenized stocks (e.g., NVDA, TSLA) on Robinhood Chain via MCP, with non-custodial keys and spending caps.7 npmMIT
fingersofficial
AlicenseNot gradedqualityCmaintenanceRead-only checks on tokens, NFTs, wallets, contracts and tokenized stocks before an agent acts. Honeypot, peg, copycat, wallet risk. Deep Robinhood Chain coverage. Never your keys.MIT