ByteAsk Embedded MCP: recuperación de texto original con número de página para agentes de firmware

Para quién

Si escribes firmware, un controlador o código de protocolo y necesitas texto original con números de página, en vez de dejar que un modelo rellene registros o cláusulas de memoria, este servicio encaja. Lo oficial lo describe como un MCP de recuperación de evidencia con fuente y cita de página para agentes de código, y nombra Claude Code, Codex y Cursor.

Encaja con quien ya puede conectar un MCP remoto a esos clientes y está tratando literales hexadecimales, códigos Modbus, cláusulas IEEE, verbos SCPI o referencias de MCU. Lo oficial exige que el agente llame search_docs antes de responder de memoria.

Este repositorio no contiene el motor de búsqueda ni el corpus documental; el material con licencia está detrás del endpoint alojado. El primer intento debe usar el camino alojado. No trates un proceso stdio local como si ya tuviera todo el corpus.

Completar el primer intento en 3 minutos

La recuperación completa que lo oficial pone disponible está en el endpoint alojado. Requisitos: usas Claude Code, Codex o Cursor y puedes añadir un MCP remoto.

Apunta el cliente a esta línea:

https://mcp.byteask.ai/mcp

Guarda, recarga y confirma que el servicio está conectado. El nombre de registro oficial es ai.byteask/embedded-docs, pero el primer intento solo necesita conectar el endpoint alojado.

Luego una recuperación de solo lectura: llama search_docs. Lo oficial dice que el agente debe buscar primero cuando ve literales hexadecimales, códigos Modbus, cláusulas IEEE, verbos SCPI o referencias de MCU. Usa el número o la cláusula que ya estás escribiendo como término. No inventes un número de dispositivo ni un valor de registro que no aparecen en esta página.

Señal de éxito: devuelve fragmentos de texto original con citas de página; si no son suficientemente relevantes, devuelve no match en vez de redactar una respuesta. Lo oficial dice que nunca da un authored answer. No leas no match como permiso para inventar.

La alternativa local es Python 3.10+ y uv, con uv sync y luego uv run byteask-embedded-mcp (stdio). No tomes ese camino en el primer intento: lo oficial dice que el motor y el corpus no están en este repositorio.

Casos de uso

Caso 1: al escribir MCU o un controlador, primero comprobar literales hexadecimales y referencias de dispositivo. Llama search_docs y envía un literal hexadecimal o una referencia MCU que ya esté en tu código. Lo oficial trata estos disparadores como momento de búsqueda, pero no da una referencia de ejemplo ni campos de retorno. Si tiene éxito debes ver fragmentos originales con página; si es no match, para. No completes registros.

Caso 2: al escribir una pila de protocolo, comprobar códigos Modbus, cláusulas IEEE o verbos SCPI. Llama search_docs igual. Lo oficial nombra estas tres pistas de protocolo y no escribe sintaxis de búsqueda ni formato de número de cláusula. Usa solo los campos search_docs que muestre el cliente. El éxito sigue siendo texto original con página o un no match honesto. No lo trates como una herramienta de escritura que pueda reescribir el cuerpo de la norma.

Límites

Solo el endpoint alojado conecta el corpus con licencia del que habla lo oficial. Lo que este repositorio abre es la cáscara del servidor MCP; el motor, el troceado, los embeddings, la ordenación y el material con licencia no están en el repositorio. uv run byteask-embedded-mcp local solo se documenta como arranque stdio; no asumas que los mismos documentos ya existen en local.

Lo que vuelve son fragmentos originales más números de página, no una respuesta ya escrita. Sin un acierto suficientemente relevante dice no match. Las consultas salen a la red hacia el endpoint alojado y pueden exponer el dispositivo o la pista de protocolo que estás consultando. Lo oficial no escribe límite de velocidad ni deshacer.

No trates un sitio docs ni archivos de implementación de backend como otra entrada de instalación. El primer intento solo conecta el MCP alojado y solo llama search_docs.