The nrf-mcp server provides tools to browse, search, and analyze the Nordic nRF Connect SDK repository, enabling AI-assisted embedded/IoT development for Nordic hardware.
nrf_list — List files and directories at any path in the SDK repo, with recursive tree view support (up to depth 3)
nrf_read — Read contents of any text file (.rst docs, .c/.h source, CMakeLists.txt, prj.conf, Kconfig, YAML, etc.), with line range support and auto-truncation for large files
nrf_search — Search across the SDK using GitHub code search with qualifiers (e.g., path:, extension:) to find code snippets or documentation, with pagination support
nrf_diff — Compare a file between two SDK versions (tags, branches, or SHAs) and view a unified diff
nrf_kconfig — Look up a CONFIG_* symbol to retrieve its Kconfig definition, type, default values, and dependencies
The server supports targeting specific SDK versions (defaults to main) and caches responses for performance. It covers documentation, samples (Bluetooth, cellular, Matter, NFC, cryptography, TF-M), libraries, and applications.
Provides tools to browse documentation, list files, and search code within the nRF Connect SDK (sdk-nrf) repository on GitHub.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@nrf-mcp find the peripheral_hr sample and show me its main.c"
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.
MCP server for Nordic nRF Connect SDK development. Provides Claude with tools to browse documentation and sample code from the nrfconnect/sdk-nrf repository.
Tool | Description |
| List files and directories at a given path (includes file sizes). Supports recursive tree view with |
| Read a file's contents ( |
| Search across the repo using GitHub code search with qualifier support. Returns context snippets and supports pagination |
| Compare a file between two SDK versions (tags, branches, or SHAs). Returns a unified diff |
| Look up a |
# Find all uses of a symbol
DFU_TARGET_IMAGE_TYPE_ANY
# Search docs only
FOTA path:doc/nrf
# Search samples only
peripheral_hr path:samples
# Filter by file type
CONFIG_BT_PERIPHERAL extension:conf
bt_le_adv_start extension:cUse depth to get a full project overview in one call:
{ "path": "samples/bluetooth/central_bas", "depth": 2 }When working with large files, use startLine and endLine to read just the relevant section:
{ "path": "samples/bluetooth/central_bas/src/main.c", "startLine": 1, "endLine": 50 }Search returns up to 20 results per page. Use the page parameter to fetch more:
{ "query": "bt_le_adv_start extension:c", "page": 2 }See what changed in a file between releases:
{ "path": "samples/bluetooth/central_bas/src/main.c", "fromRef": "v3.0.0", "toRef": "v3.2.4" }Look up what a prj.conf option does:
{ "symbol": "CONFIG_BT_PERIPHERAL" }Related MCP server: GitHub MCP Server
Node.js 18+
GitHub CLI (gh) authenticated — used to supply a GitHub token at runtime
npm install
npm run buildclaude mcp add -s user nrf-mcp -- /path/to/nrf-mcp/run.shAdd to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"nrf-mcp": {
"command": "/path/to/nrf-mcp/run.sh",
"args": []
}
}
}Then restart Claude Desktop.
The run.sh wrapper fetches a fresh token from gh auth token each time the server starts, so no token is ever hardcoded.
Variable | Default | Description |
|
| SDK version to target — any git ref (tag, branch, commit SHA) |
| (from | GitHub API token; set explicitly to bypass the |
To target a different SDK version, set the env var in the MCP registration:
claude mcp remove nrf-mcp
claude mcp add -s user -e NRF_SDK_REF=v3.2.4 nrf-mcp -- /path/to/nrf-mcp/run.shnpm run buildDuring development, use npm run watch to recompile automatically on save.
Run the end-to-end test suite (requires gh to be authenticated):
npm testThe tests spawn the server via run.sh, exercise all five tools (including recursive listing, line ranges, pagination, snippets, diff, Kconfig lookup, and error handling), and validate input error handling.
gh: command not found or empty token
The run.sh script fetches a token via gh auth token. Make sure the GitHub CLI is installed and you are logged in:
gh auth login
gh auth token # should print a tokenGitHub API 401 errors
nrf_search requires authentication. If the token is missing or expired, re-authenticate with gh auth login. For Claude Desktop, ensure run.sh is executable (chmod +x run.sh) — it prepends the Homebrew bin path to find gh.
GitHub rate limit exceeded
Unauthenticated requests are limited to 60/hour. With a valid GITHUB_TOKEN the limit is 5 000/hour. The server automatically retries on rate-limit errors with backoff (up to 30s). Ensure gh auth token returns a token and that run.sh is being used (not node dist/index.js directly).
Tools not appearing in Claude
Claude Code: run claude mcp list to confirm nrf-mcp is registered, then restart the session.
Claude Desktop: restart the app after editing claude_desktop_config.json. Check the Desktop developer console for MCP startup errors.
Stale results Directory listings and file contents are cached in memory for 5 minutes to reduce API calls. Restart the server to clear the cache.
Wrong SDK version
Confirm the active ref with echo $NRF_SDK_REF in the same shell, or check what's registered:
claude mcp list # shows the -e env vars set at registration timeTo change it, remove and re-add the registration with the new -e NRF_SDK_REF= value.
List the contents of a directory in the nRF Connect SDK repo (nrfconnect/sdk-nrf @ main).
Useful starting paths:
"doc/nrf" → Documentation root (RST files)
"doc/nrf/protocols" → Bluetooth, LTE, Thread, Zigbee docs
"doc/nrf/libraries" → Library reference docs
"doc/nrf/applications" → Application-level docs
"samples" → All sample projects
"samples/bluetooth" → Bluetooth LE samples
"samples/cellular" → LTE/cellular modem samples
"samples/matter" → Matter protocol samples
"samples/nfc" → NFC samples
"samples/tfm" → Trusted Firmware-M samples
"samples/crypto" → Cryptography samples
Returns dirs first, then files, with full paths you can pass to nrf_read.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Directory path within the repo (e.g. 'samples/bluetooth') |
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 effectively describes key behaviors: the tool lists directory contents, returns directories first then files, provides full paths, and those paths can be used with nrf_read. It doesn't mention error conditions, rate limits, or authentication needs, but covers the core operational 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized. The first sentence states the core purpose, followed by a practical 'Useful starting paths' section that provides immediate utility, and ends with important behavioral details about the return format. Every sentence earns its place with no wasted words.
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?
For a single-parameter tool with no output schema, the description provides good completeness. It explains what the tool does, how to use it with examples, and describes the return format. The main gap is the lack of error handling information, but given the tool's simplicity and the provided context, it's reasonably complete.
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?
Schema description coverage is 100%, so the schema already documents the single 'path' parameter. The description adds some value by providing concrete examples of paths (e.g., 'samples/bluetooth') in the 'Useful starting paths' section, but doesn't add significant semantic meaning beyond what the schema provides.
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 clearly states the specific action ('List the contents of a directory') and resource ('nRF Connect SDK repo'), distinguishing it from sibling tools nrf_read (likely reads file contents) and nrf_search (likely searches within files). The phrase 'Returns dirs first, then files, with full paths you can pass to nrf_read' further clarifies its role in the toolchain.
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 provides clear context for when to use this tool (listing directory contents in a specific repo) and includes a helpful list of 'Useful starting paths' to guide initial usage. However, it does not explicitly state when NOT to use it or mention alternatives like nrf_search for different operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the contents of a file from the nRF Connect SDK repo (nrfconnect/sdk-nrf @ main).
Works for any text file: .rst documentation, .c/.h source, CMakeLists.txt, Kconfig, prj.conf, .yaml, README.rst, etc.
Use nrf_list to discover paths first. Examples:
"samples/bluetooth/central_bas/README.rst"
"samples/bluetooth/central_bas/src/main.c"
"samples/bluetooth/central_bas/CMakeLists.txt"
"samples/bluetooth/central_bas/prj.conf"
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | File path within the repo (e.g. 'samples/bluetooth/peripheral_hr/src/main.c') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool reads text files from a specific repo, but lacks details on permissions, rate limits, error handling, or output format. While it adds context about supported file types, it doesn't fully cover behavioral traits needed for a read operation without annotations.
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 front-loaded with the core purpose, followed by supported file types and usage guidelines with examples. Every sentence adds value without redundancy, making it efficient and well-structured for quick understanding.
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?
Given 1 parameter with full schema coverage and no output schema, the description is adequate but has gaps. It explains what the tool does and when to use it, but lacks details on return values, error cases, or behavioral constraints, which are important for a read tool without annotations or output schema.
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?
Schema description coverage is 100%, with the parameter 'path' well-documented in the schema. The description adds minimal value beyond the schema by providing examples of paths, but doesn't explain semantics like path format constraints or edge cases. Baseline 3 is appropriate as the schema does the heavy lifting.
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 clearly states the verb ('Read') and resource ('contents of a file from the nRF Connect SDK repo'), specifying it works for various text file types. It explicitly distinguishes from sibling nrf_list by stating 'Use nrf_list to discover paths first,' making the purpose specific and differentiated.
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 provides explicit guidance on when to use this tool ('Use nrf_list to discover paths first') and implies alternatives by mentioning sibling tools (nrf_list for discovery, nrf_search likely for searching). It sets clear context for file reading versus path discovery.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for code or documentation across the nRF Connect SDK repo using GitHub code search.
Supports GitHub search qualifiers to narrow results:
Plain keyword: "DFU_TARGET_IMAGE_TYPE_ANY"
Docs only: "FOTA path:doc/nrf"
Samples only: "peripheral_hr path:samples"
Specific extension: "CONFIG_BT_PERIPHERAL extension:conf"
Source files only: "bt_le_adv_start extension:c"
Headers only: "struct bt_conn extension:h"
Returns matching file paths (up to 20). Use nrf_read to fetch the content. Note: Requires GITHUB_TOKEN for reliable results (unauthenticated search is heavily rate-limited).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search terms with optional GitHub qualifiers (path:, extension:, filename:) |
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 effectively describes key traits: it's a read-only search operation (implied by 'search'), returns up to 20 file paths, requires authentication for reliability, and is rate-limited without it. However, it lacks details on error handling or exact response format, which could be beneficial for completeness.
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 well-structured and front-loaded, starting with the core purpose. Each sentence adds essential information: search capabilities, qualifier examples, return details, and authentication requirements. There is no wasted text, and the bulleted examples are concise and illustrative, making it easy to scan and understand.
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?
Given the tool's complexity (search with qualifiers, authentication needs) and lack of annotations and output schema, the description is largely complete. It covers purpose, usage, parameters, and behavioral traits. However, it doesn't specify the exact output format (e.g., JSON structure) or error scenarios, which could aid the agent in handling responses, preventing a perfect score.
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 description coverage is 100%, so the baseline is 3. The description adds significant value beyond the schema by providing examples of GitHub search qualifiers (e.g., 'path:doc/nrf', 'extension:c'), which clarify how to construct the query parameter effectively. This enhances understanding but doesn't fully cover all possible qualifiers, keeping it from a perfect score.
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 clearly states the tool's purpose: 'Search for code or documentation across the nRF Connect SDK repo using GitHub code search.' It specifies the verb ('search'), resource ('code or documentation'), and scope ('nRF Connect SDK repo'), and distinguishes it from sibling tools by mentioning 'Use nrf_read to fetch the content,' indicating it returns file paths rather than content.
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 provides explicit guidance on when to use this tool versus alternatives. It states 'Returns matching file paths (up to 20). Use nrf_read to fetch the content,' clearly differentiating from nrf_read for content retrieval. It also specifies 'Requires GITHUB_TOKEN for reliable results (unauthenticated search is heavily rate-limited),' indicating prerequisites and performance considerations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0nrf_listnrf_readnrf_searchEach tool has a clearly distinct purpose: nrf_list for directory listing, nrf_read for file reading, and nrf_search for content searching. There is no overlap in functionality, making tool selection straightforward for an agent.
All tool names follow a consistent 'nrf_' prefix with descriptive verbs (list, read, search), using snake_case uniformly. This predictable pattern enhances readability and reduces confusion.
Three tools are appropriate for the server's purpose of exploring the nRF Connect SDK repo, covering listing, reading, and searching. It's slightly minimal but reasonable for this focused domain, with no unnecessary tools.
The tool set provides complete coverage for exploring the SDK repo: listing directories, reading files, and searching content. There are no obvious gaps, as these tools enable agents to navigate and retrieve information effectively without dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
An MCP server that gives your AI access to the source code and docs of all public github repos
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP server for accessing curated awesome list documentation
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/pshanesmith/nrf-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
