How do I use byteask-embedded-docs?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@byteask-embedded-docs what is the Modbus function code for writing multiple registers?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

byteask-embedded-docs

Q: What can you do with this server?

The ByteAsk Embedded MCP server provides source-grounded, page-cited evidence retrieval from embedded and firmware reference documentation — returning verbatim snippets with page citations rather than fabricated answers. It is designed for coding agents (e.g., Claude Code, Codex, Cursor) to retrieve accurate facts during development. Tools available: * search_docs: Query an indexed corpus of embedded/firmware/hardware documents using natural language or exact identifiers. The corpus covers grid-interconnection & DER standards (IEEE 1547, SunSpec Modbus, ENA G98/G99), industrial & fieldbus protocols (Modbus, CAN/ISO-TP, MQTT), SCPI instrument-programming manuals, Arm Cortex-M and other MCU/hardware datasheets (registers, bitfields, reset values), and embedded library/API references. Results include document title, section + page citation, verbatim snippet, and a result_id. Returns an honest "no confident match" instead of fabricating an answer. * get_context: Expand a previous search_docs hit using its result_id to retrieve the full verbatim source section in markdown — useful when a snippet alone isn't enough. * request_document: If a search yields no confident match, request that a missing document (standard, protocol spec, SCPI manual, MCU datasheet, etc.) be added to the corpus. Documents are typically added within 24 hours. The server can be run locally via stdio transport or accessed through a hosted Streamable HTTP endpoint, and supports plugging in a custom retrieval backend.

Official

by ByteAsk

Overview Schema Related Servers Score Discussions

Python

Hybrid

ByteAsk Embedded MCP

Page-cited answers from embedded & firmware reference docs — for coding agents that can't afford to guess a register value.

License: MIT Python 3.10+ Model Context Protocol Status: beta PRs welcome Hosted

Official MCP Registry Namespace: ai.byteask/embedded-docs · Remote MCP Endpoint: https://mcp.byteask.ai/mcp

Quickstart · Tools · Connect a client · Configuration · Hosted server · Contributing

ByteAsk Embedded MCP is the open-source server behind ByteAsk Embedded Docs: a source-grounded, page-cited evidence-retrieval MCP server for coding agents (Claude Code, Codex, Cursor) that write firmware / driver / protocol code and need exact facts — SunSpec points, register offsets, Modbus function codes, trip thresholds, SCPI commands, API symbols.

It returns verbatim snippets with page citations — never an authored answer — and when nothing is relevant enough it says no match rather than fabricate. Every document is treated equally: no authority layer, no filters.

NOTE

What's in this repo: the MCP server — tools, transports (stdio + Streamable HTTP), bearer auth, DNS-rebinding protection, result rendering — plus a small, pluggable retrieval interface.

What's not in this repo: the retrieval engine and the document corpus. How documents are parsed, chunked, embedded, and ranked, and the licensed source material itself, sit behind the SearchBackend seam and power the hosted endpoint at https://mcp.byteask.ai/mcp. This repo ships an in-memory SampleBackend (a few illustrative, public-knowledge records) so the server runs out of the box.

Why

Cited, or nothing. Every hit is verbatim source text with a section + page citation. On a miss it returns an honest "no confident match" — it never invents a register value.
Built for coding agents. The tool descriptions and triggers are tuned so agents call search_docs reflexively the moment they see a hex literal, a Modbus code, an IEEE clause, a SCPI verb, or an MCU part number — before answering from memory.
Two transports, one server. stdio for local agents, Streamable HTTP for hosted.
Bring your own retrieval. The search engine is a two-method interface — swap in anything behind BYTEASK_BACKEND without touching the server.
Zero-setup demo. The bundled SampleBackend runs immediately. No API keys.

Related MCP server: Grounded Code MCP

Quickstart

Requires Python ≥ 3.10 and uv.

uv sync
uv run byteask-embedded-mcp        # run as an MCP server (stdio)

That's it — the bundled SampleBackend serves a couple of illustrative records, so search_docs works immediately. Run the offline tests with uv run pytest.

Connect a client

Hosted (no install)

The hosted server speaks Streamable HTTP at https://mcp.byteask.ai/mcp and is backed by the full licensed corpus.

Add to Cursor

Claude Code:

claude mcp add --transport http byteask-embedded-docs https://mcp.byteask.ai/mcp

{
  "mcpServers": {
    "byteask-embedded-docs": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://mcp.byteask.ai/mcp"]
    }
  }
}

Local (this repo)

The project-scoped .mcp.json registers the stdio server for clients that read it. Manually, for Claude Code:

claude mcp add byteask-embedded-docs -- uv run byteask-embedded-mcp

Tools

Input is natural language (or an exact identifier). Output is compact markdown.

Tool	What it does
`search_docs(query, limit=8)`	Search the corpus; return ranked, page-cited evidence. Each hit has a document title, a section + page citation, the verbatim snippet, and a `result_id`. A "no confident match" response means not found — do not fabricate.
`get_context(result_id)`	Expand a hit to its full source section.
`request_document(request)`	Ask for a missing document to be added (logged server-side).

Example output:

## Results for "what Modbus function code writes multiple registers"

### Sample — Modbus Application Protocol (illustrative) — §6.12, p.30
> Function code 16 (0x10), Write Multiple Registers, writes a block of contiguous
> holding registers (1 to 123 registers) in a remote device. ...
_ref: sample:modbus-fc16_

Plug in your own retrieval

The server depends only on a two-method interface (backend.py):

class SearchBackend(Protocol):
    def search(self, query, limit=8, effort=None) -> dict: ...
    def get_context(self, result_id, effort=None) -> dict: ...

Implement it, expose a factory make_backend(config) -> SearchBackend, and point the server at it:

BYTEASK_BACKEND="my_pkg.my_module:make_backend"

The exact return-value contracts are documented at the top of backend.py.

Configuration

All settings are environment variables (loaded from .env; see .env.example).

Variable	Default	Notes
`BYTEASK_BACKEND`	—	`module:callable` returning a `SearchBackend`; empty → `SampleBackend`
`BYTEASK_LOGS`	`logs`	where query / request JSONL logs are written
`MCP_TRANSPORT`	`stdio`	`stdio` (local agents) or `http`
`MCP_HTTP_HOST` / `MCP_HTTP_PORT`	`127.0.0.1` / `8000`	HTTP bind address
`MCP_HTTP_AUTH_TOKEN`	—	bearer token for HTTP (empty = unauthenticated, dev only)
`MCP_ALLOWED_HOSTS`	—	comma-separated hosts allowed in the `Host` header (`*` disables)
`LOG_LEVEL`	`INFO`	stderr log verbosity

MCP_TRANSPORT=http MCP_HTTP_AUTH_TOKEN=$(openssl rand -hex 32) \
  uv run byteask-embedded-mcp --host 0.0.0.0 --port 8000

Clients then send Authorization: Bearer <token>. The bundled bearer check is a shared-secret stub — replace it with real auth (OAuth 2.1 resource server, mTLS, or a trusted reverse proxy) before exposing publicly. DNS-rebinding protection stays on independently via MCP_ALLOWED_HOSTS.

Hosted server

You don't need to run anything to use ByteAsk Embedded Docs. The hosted server gives Claude Code, Codex, Cursor, and any MCP client exact, page-cited facts from embedded and firmware reference docs — register maps, protocol function codes, SCPI commands, standard thresholds, datasheet specs. The guarantee: verbatim source, or "no match" — never an invented value.


Name	`byteask-embedded-docs`
Endpoint	`https://mcp.byteask.ai/mcp` (Streamable HTTP)
Docs & per-client setup	https://docs.byteask.ai/embedded

This repository is the open-source server that powers that endpoint.

Project layout

src/byteask_embedded_mcp/
  server.py     # FastMCP app + 3 tools (search_docs, get_context, request_document)
  backend.py    # SearchBackend protocol + in-memory SampleBackend (swap for real retrieval)
  render.py     # structured result -> compact markdown
  http_auth.py  # Streamable HTTP entrypoint + stub bearer-token guard
  config.py     # server config (transport, logging, backend selection)
  schemas.py    # Hit / Section result types
  obs.py        # per-call JSONL logging
tests/          # offline unit tests (renderer, backend, server tools)
assets/         # README demo GIF + its deterministic generator

Security

stdout stays clean in stdio mode (it is the JSON-RPC channel); all logs go to stderr / logs/*.jsonl.
The HTTP bearer check is a stub — unauthenticated if no token is set, a shared secret at best. Harden it before exposing widely.
DNS-rebinding protection is on by default for the HTTP transport.

Contributing

PRs and issues are welcome.

uv sync            # install (incl. dev tools)
uv run pytest      # run the offline test suite

A few conventions to keep the server clean:

The backend seam is the extension point. Retrieval internals (parsing, chunking, embeddings, ranking) are intentionally out of scope here — build them behind SearchBackend in your own package, not in this repo.
Keep the dependency surface small and the stdio path free of the HTTP stack.
Add a test for new behavior; the suite is fully offline (no network, no keys).

License

MIT © ByteAsk

Available Tools

3 tools

get_contextAInspect

Expand a previous search hit to its full verbatim section (markdown).

Args:
    result_id: The result_id from a search_docs hit.
    effort: Internal diagnostics tag; clients should leave this unset.

ParametersJSON Schema

Name	Required	Description	Default
`result_id`	Yes
`effort`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided. The description does not disclose behavioral traits such as whether the operation is read-only, if it requires specific permissions, or any rate limits. The verb 'expand' implies retrieval but is not explicit about side effects or safety.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two clear sentences plus param explanations. It is front-loaded with the main purpose, and every sentence adds value. No waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given only two simple parameters and the presence of an output schema, the description is complete. It explains the tool's purpose, how to use it, and the role of each parameter. The output schema covers return values.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description fully compensates. It explains that result_id is from a search_docs hit, and that effort is an internal diagnostic tag clients should leave unset. This adds critical meaning beyond the schema's type/title.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it expands a previous search hit to its full verbatim section in markdown. It distinguishes from siblings by specifying it operates on a search hit's result_id, not on documents or raw search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains that result_id comes from search_docs, and warns clients not to set effort. This gives clear context on when to use it after search_docs, but does not explicitly compare to sibling tools or state when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

request_documentAInspect

Request that a document be ADDED to the corpus - use this when search_docs returns 'no confident match' for material it should cover (a standard, protocol spec, SCPI or instrument manual, MCU / hardware datasheet, or library reference). This does NOT search; use search_docs for that. Pass ONE string with as much as you know: the document title or standard number, a URL if you have one, the edition / version, and what you were looking for. Requests are reviewed and the document is typically added within 24 hours.

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes
`effort`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It discloses that the tool is a request (not immediate), that it's reviewed, and typical turnaround time (24 hours). It does not mention authentication or rate limits but covers the core behavior well.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with purpose. Every sentence adds value: what it does, when to use, what to pass, and outcome. No redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists (not shown), explanation of return values is unnecessary. The description covers the action, context, and outcome. However, it omits mention of the effort parameter and could clarify that the request is for documents not already in the corpus.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description must compensate. It specifies that the 'request' parameter should be a single string containing document details. However, it does not describe the 'effort' parameter, which may lead to confusion. The instruction 'Pass ONE string' could be misinterpreted as ignoring the second parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: requesting a document to be added to the corpus. It distinguishes from sibling search_docs by explicitly stating this tool does not search. The verb 'request' and resource 'document to be added' are specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells when to use (when search_docs returns no confident match for specific materials) and when not to (use search_docs for searching). Also provides guidance on what to include in the request string and mentions SLA (24 hours).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_docsAInspect

Search the indexed embedded / firmware / hardware reference corpus; return verbatim, page-cited evidence. The indexed corpus covers: grid-interconnection & DER standards (IEEE 1547 / 1547.1 / 2030.5, SunSpec Modbus profiles, ENA G98/G99 and other grid codes); industrial & fieldbus protocols (Modbus, CAN / ISO-TP, MQTT); SCPI instrument-programming manuals (power analysers, grid simulators, programmable AC sources); Arm Cortex-M and other MCU / hardware datasheets (registers, bitfields, reset values); and embedded library / API references. Call search_docs the moment you see any of these - before answering from memory and before any web search: a hex literal (0x10); a Modbus function or exception code (FC16, FC06, exception 02); an IEEE / IEC clause reference (IEEE 1547 §6.4.1); a SCPI command verb (*IDN?, :MEAS:VOLT?); an MCU part number (STM32F4, ATmega328); a register or bitfield name (SYST_CSR, CONTROL.SPSEL); a trip / ride-through threshold or timing limit; or any datasheet spec or API signature. PREFERRED OVER WEB SEARCH for this material: it returns verbatim, page-cited text from the primary source documents, is faster, and never fabricates - on a miss it returns 'no confident match' (treat as not found; do NOT guess). Cheap and safe to call several times per task.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`limit`	No
`effort`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite no annotations, the description fully discloses behavior: returns verbatim evidence, never fabricates, returns 'no confident match' on miss, and notes it is faster than web search. This provides complete transparency for an AI agent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is lengthy but well-structured and front-loaded with key purpose and usage guidelines. Each sentence adds value, though some redundancy could be trimmed. Still effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, the description does not need to detail return values. It covers use cases, triggers, and behavioral guarantees. Sibling tools are not discussed, but the description is self-contained for this tool's purpose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

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 should compensate by explaining the parameters. However, it only mentions the query implicitly; there is no explanation of 'limit' or 'effort'. This leaves ambiguity for the agent.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool searches an indexed corpus for embedded/firmware/hardware references and returns verbatim, page-cited evidence. It lists specific topics covered, making the purpose highly specific and distinguishable from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells when to call this tool, listing specific triggers (hex literals, Modbus codes, etc.) and states it is preferred over web search. It also warns against guessing and indicates it is cheap and safe to call multiple times.

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. Dates show when Glama detected each change.

3 tool updatesv0.1.0Jun 20, 2026
- First observedget_context
- First observedrequest_document
- First observedsearch_docs

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.5/5.0

Disambiguation5/5

Each tool has a distinct, non-overlapping purpose: search_docs for searching, get_context for expanding search results, and request_document for adding new documents. No two tools could be confused.

Naming Consistency5/5

All tool names follow a clear verb_noun pattern with underscores (search_docs, get_context, request_document), consistently using imperative verbs and descriptive nouns.

Tool Count5/5

With only 3 tools, the server is well-scoped for its domain. Each tool is essential and justified, covering the primary operations without unnecessary bloat or gaps.

Completeness5/5

The tool set covers the full workflow: searching for information, retrieving full context from search results, and requesting new documents when missing. No obvious gaps for the stated purpose of an embedded docs corpus.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp A
ai.llmse
Public MCP server for the LLM Search Engine
Search RAG Systems Developer Tools
102
saagarpatel.dev Portfolio A
io.github.saagpatel
Agent-native MCP server over the public saagarpatel.dev corpus. Read-only, stateless.
Search Documentation Access
82
forkast-mcp-docs A
io.github.ForkastPredict
MCP server for querying Forkast documentation
Documentation Access Search Developer Tools
42
mcp
dev.augments
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Developer Tools Documentation Access
2128

Related MCP Servers

can-see
Command Line Shell Access Testing & QA Tools
HurleySk
A
license
Not graded
quality
C
maintenance
MCP server that lets AI agents see and interact with terminal/CLI applications through virtual terminals and PNG screenshots.
Updated 3 months ago (2026-05-22 17:42 UTC)
153
MIT
Grounded Code MCP
RAG Systems Knowledge & Memory
michaelalber
A
license
Not graded
quality
B
maintenance
A local MCP server that gives AI coding assistants retrieval access to your personal knowledge base of books, standards, and docs, grounding their answers in sources you trust.
Updated 2 months ago (2026-07-14 03:40 UTC)
MIT
Harpyja
Code Analysis Search Developer Tools
DCSTOLF
A
license
B
quality
B
maintenance
A precision code-retrieval MCP server for coding agents working in large, legacy, and air-gapped codebases. It returns exact file and line range citations from natural-language queries without requiring the agent to perform blind searches.
Updated a month ago (2026-08-03 21:15 UTC)
3
MIT
Muninn
rdnpradipta
F
license
A
quality
C
maintenance
MCP server for querying a page-citable research knowledge base built from PDFs, with exact filename and page citations.
Updated a month ago (2026-07-28 00:29 UTC)
6
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ByteAsk/ByteAsk-Embedded-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server