Install
https://mcp.byteask.ai/mcpWho it is for
If you are writing firmware, driver, or protocol code and need original-text evidence with page numbers, rather than letting a model fill registers or clauses from memory, this service matches. Official docs describe it as a sourced, page-cited evidence-retrieval MCP for coding agents, and they name Claude Code, Codex, and Cursor.
It fits people who can already attach a remote MCP to those clients and who are handling hexadecimal literals, Modbus codes, IEEE clauses, SCPI verbs, or MCU part numbers. Official docs require the agent to call search_docs before answering from memory.
This repository does not contain the search engine or the document corpus; licensed material sits behind the hosted endpoint. The first try should use the hosted path. Do not treat a local stdio process as already holding the full corpus.
First try in 3 minutes
The complete retrieval that official docs make available is on the hosted endpoint. Prerequisites: you use Claude Code, Codex, or Cursor, and you can add a remote MCP.
Point the client at this line:
https://mcp.byteask.ai/mcp
Save, reload, and confirm the service is connected. The official registration name is ai.byteask/embedded-docs, but the first try only needs the hosted endpoint connected.
Then do one read-only retrieval: call search_docs. Official docs say the agent should search first when it sees hexadecimal literals, Modbus codes, IEEE clauses, SCPI verbs, or MCU part numbers. Use the number or clause you are already writing as the query. Do not invent a device number or register value that never appears on this page.
Success signal: it returns original-text excerpts with page citations; if they are not relevant enough, it returns no match instead of writing an answer. Official docs say it never gives an authored answer. Do not treat no match as permission to invent.
The local alternative is Python 3.10+ and uv, with uv sync then uv run byteask-embedded-mcp (stdio). Do not take that path on the first try: official docs say the search engine and corpus are not in this repository.
Usage examples
Example 1: when writing MCU or driver code, first check hexadecimal literals and device part numbers. Call search_docs and send a hexadecimal literal or MCU part number that already appears in your code. Official docs treat these as search triggers, but give no sample part number or return fields. On success you should see original-text excerpts with page numbers; on no match, stop. Do not fill in registers.
Example 2: when writing a protocol stack, check Modbus codes, IEEE clauses, or SCPI verbs. Call search_docs the same way. Official docs name these three protocol cues and do not write search syntax or clause-number format. Use only the search_docs fields the client shows. Success is still paged original text or an honest no match. Do not treat it as a writing tool that may rewrite the specification body.
Limits
Only the hosted endpoint connects to the licensed corpus official docs describe. What this repository opens is the MCP server shell; the search engine, chunking, embeddings, ranking, and licensed material are not in the repository. Local uv run byteask-embedded-mcp is only documented as a stdio launch method; do not infer that the same documents already exist locally.
What comes back is original-text excerpts plus page numbers, not a ready-written answer. When there is no sufficiently relevant hit, it says no match. Queries go online to the hosted endpoint and may expose the device or protocol cue you are looking up. Official docs give no rate limit and no undo.
Do not treat a docs site or backend implementation files as another install entry. The first try only connects the hosted MCP and only calls search_docs.