Which integrations are available for this server?

Allows querying official ARM CMSIS SVD hardware register definitions to retrieve precise register names, bit positions, and addresses for supported microcontrollers. Provides access to the Raspberry Pi RP2040's hardware register definitions through bundled SVD files, enabling detailed searches for its peripherals and registers.

How do I use mcp-svd?

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., "@mcp-svd Look up the bitfields for the GPIOA MODER register in svd/STM32F411.svd" 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-svd

by pkt-lab

Overview Schema Related Servers Score Discussions

TypeScript

Local

mcp-svd

An MCP (Model Context Protocol) server that exposes ARM CMSIS SVD hardware register definitions to AI coding assistants. Instead of hallucinating register names, bit positions, and addresses, your AI assistant can query the exact definitions straight from the official SVD file for your microcontroller.

Install

From GitHub (no npm needed):

npm install github:pkt-lab/mcp-svd

Or clone and build manually:

git clone https://github.com/pkt-lab/mcp-svd
cd mcp-svd
npm install && npm run build

Related MCP server: JLink MCP Server

Claude Desktop configuration

If installed via npm (GitHub):

{
  "mcpServers": {
    "mcp-svd": {
      "command": "node",
      "args": ["./node_modules/mcp-svd/dist/index.js"]
    }
  }
}

If cloned locally:

{
  "mcpServers": {
    "mcp-svd": {
      "command": "node",
      "args": ["/absolute/path/to/mcp-svd/dist/index.js"]
    }
  }
}

Config file location:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json

Restart Claude Desktop after editing.

MCP tools

`list_peripherals`

{ "svd_file": "svd/STM32F411.svd" }

`lookup_register`

{ "svd_file": "svd/STM32F411.svd", "peripheral": "USART1", "register": "CR1" }

`describe_field`

{ "svd_file": "svd/STM32F411.svd", "peripheral": "GPIOA", "register": "MODER", "field": "MODE0" }

`search_registers`

{ "svd_file": "svd/rp2040.svd", "query": "uart" }

Returns up to 10 peripheral+register matches (case-insensitive substring).

REST API

REST_PORT=3000 node dist/index.js

# List peripherals
curl "http://localhost:3000/api/v1/peripherals?svd=svd/STM32F411.svd"

# List registers
curl "http://localhost:3000/api/v1/registers/GPIOA?svd=svd/STM32F411.svd"

# Describe a field
curl "http://localhost:3000/api/v1/field/GPIOA/MODER/MODE0?svd=svd/STM32F411.svd"

Using your own SVD file

Download from cmsis-svd-data or your chip vendor, then pass the path:

{ "svd_file": "/path/to/your/device.svd", "peripheral": "SPI0", "register": "CR" }

Bundled SVD files

File	Device
`svd/STM32F411.svd`	STM32F411
`svd/nRF52840_xxAA.svd`	Nordic nRF52840
`svd/rp2040.svd`	Raspberry Pi RP2040

License

MIT

Available Tools

4 tools

describe_fieldA

Describe a specific bit-field within a register: its bit offset, width, access type, and enumerated values if defined. Use this when you need to understand or set a specific control bit or flag.

ParametersJSON Schema

Name	Required	Description
`svd_file`	Yes	Absolute or relative path to the .svd file
`peripheral`	Yes	Peripheral name (e.g. GPIOA, UART0)
`register`	Yes	Register name (e.g. CR1, MODER)
`field`	Yes	Field name (e.g. UE, MODE0, RXNEIE)

TDQS

A4.1/5.0

Behavior3/5

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 mentions the tool describes field attributes (e.g., access type, enumerated values), which implies a read-only, informational operation. However, it lacks details on error handling, output format, or any behavioral constraints (e.g., file access requirements, performance limits), leaving gaps in transparency for a tool with no annotation support.

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 front-loaded with the core purpose in the first sentence, followed by a clear usage guideline. Both sentences are essential and waste no words, making it efficient and easy to parse for an agent selecting tools.

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

Completeness3/5

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

Given no annotations and no output schema, the description adequately covers the tool's purpose and usage. However, it lacks details on behavioral aspects (e.g., what the output looks like, error cases) and does not compensate for the absence of structured fields. For a tool with 4 parameters and no output schema, more contextual information would improve completeness.

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 description coverage is 100%, with all four parameters (svd_file, peripheral, register, field) well-documented in the schema. The description does not add any parameter-specific details beyond what the schema provides, such as examples or constraints. Baseline 3 is appropriate since the schema handles the heavy lifting, but no extra semantic value is added.

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 specific action ('Describe a specific bit-field') and resource ('within a register'), listing key attributes like bit offset, width, access type, and enumerated values. It distinguishes from sibling tools (e.g., list_peripherals, lookup_register) by focusing on detailed field-level information rather than peripheral/register listing or lookup.

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 states when to use this tool: 'Use this when you need to understand or set a specific control bit or flag.' This provides clear context for usage versus alternatives, guiding the agent to select this tool for detailed field analysis rather than broader operations offered by siblings.

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

list_peripheralsA

List all peripherals defined in an ARM CMSIS SVD file. Returns each peripheral's name, base address, and description. Use this to discover what hardware blocks are available in a microcontroller.

ParametersJSON Schema

Name	Required	Description	Default
`svd_file`	Yes	Absolute or relative path to the .svd file

TDQS

A4/5.0

Behavior3/5

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 the tool's read-only nature and output format, but lacks details on error handling, file format constraints, or performance characteristics. It doesn't contradict any annotations, but could benefit from more operational context.

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 perfectly concise with two sentences that each serve distinct purposes: the first explains what the tool does and returns, the second provides usage context. There's no wasted language or redundancy, making it highly efficient and front-loaded with essential information.

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?

For a single-parameter read operation with no output schema, the description provides adequate context about what the tool does and when to use it. However, without annotations or output schema, it could benefit from more detail about error conditions or output format specifics to achieve full completeness.

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?

The input schema has 100% description coverage, clearly documenting the single required parameter 'svd_file'. The description doesn't add any parameter-specific information beyond what the schema provides, maintaining the baseline score of 3 for high schema coverage situations.

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 specific action ('List all peripherals'), resource ('in an ARM CMSIS SVD file'), and output format ('Returns each peripheral's name, base address, and description'). It distinguishes this tool from sibling tools like 'describe_field', 'lookup_register', and 'search_registers' by focusing on peripheral discovery rather than register-level operations.

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 provides clear context for when to use this tool ('to discover what hardware blocks are available in a microcontroller'), which implicitly suggests it's for initial exploration rather than detailed register analysis. However, it doesn't explicitly state when not to use it or name specific alternatives among the sibling tools, keeping it from a perfect score.

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

lookup_registerA

Get full details for a specific register within a peripheral, including address offset, size, access type, reset value, and all bit-fields with their positions. Use this when you need exact register layout for low-level firmware code.

ParametersJSON Schema

Name	Required	Description
`svd_file`	Yes	Absolute or relative path to the .svd file
`peripheral`	Yes	Peripheral name (e.g. GPIOA, UART0, SPI1)
`register`	Yes	Register name (e.g. CR1, MODER, CONFIG)

TDQS

A4.1/5.0

Behavior3/5

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 implies a read-only operation ('Get full details') but doesn't disclose behavioral traits like error handling, performance characteristics, or output format. While it adds context about low-level firmware use, it lacks details on what happens if inputs are invalid or how results are structured.

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 efficiently structured in two sentences: the first states the purpose and key details, and the second provides usage guidelines. Every sentence adds value without redundancy, making it front-loaded and appropriately sized for the tool's complexity.

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

Completeness3/5

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

Given no annotations and no output schema, the description is moderately complete but has gaps. It covers purpose and usage well but lacks behavioral details like error cases or output structure. For a tool with 3 required parameters and no structured output, more context on what 'full details' includes would improve completeness, though it's adequate for basic use.

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 description coverage is 100%, so the schema already documents all three parameters (svd_file, peripheral, register) with clear descriptions. The description adds no additional parameter semantics beyond implying they are used to locate a specific register, which is already evident from the schema. 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.

Purpose5/5

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

The description clearly states the specific action ('Get full details') and resource ('for a specific register within a peripheral'), listing concrete attributes like address offset, size, access type, reset value, and bit-fields. It explicitly distinguishes from siblings by specifying exact register layout for low-level firmware code, unlike broader tools like list_peripherals or search_registers.

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 provides explicit guidance on when to use this tool ('when you need exact register layout for low-level firmware code'), implying alternatives like search_registers for broader queries or describe_field for bit-level details. It clearly defines the context without exclusions, helping the agent choose correctly among siblings.

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

search_registersA

Search across all peripherals and registers in an SVD file using a case-insensitive substring match. Returns up to 10 matches with peripheral name, register name, and description. Use this when you know part of a register name but not which peripheral it belongs to.

ParametersJSON Schema

Name	Required	Description	Default
`svd_file`	Yes	Absolute or relative path to the .svd file
`query`	Yes	Search string matched against peripheral and register names (case-insensitive substring)

TDQS

A4.4/5.0

Behavior4/5

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 search scope (all peripherals and registers), matching method (case-insensitive substring), and result limits (up to 10 matches with specific fields). However, it lacks details on error handling, performance expectations, or pagination for results beyond 10.

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 front-loaded with the core functionality in the first sentence and follows with usage guidance. Every sentence earns its place by adding distinct value—no redundant or vague phrasing. It's appropriately sized for a tool with two parameters and clear purpose.

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 tool's moderate complexity (search function with two parameters) and lack of annotations or output schema, the description is largely complete. It covers purpose, usage, and key behaviors. However, without an output schema, it doesn't detail the structure of returned matches (e.g., field types or ordering), leaving a minor gap in full context.

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 description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds minimal value beyond the schema by mentioning the case-insensitive substring match for the query parameter, but it doesn't provide additional syntax, format details, or examples. This meets the baseline for high schema coverage.

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 specific action ('Search across all peripherals and registers'), the resource ('in an SVD file'), and the method ('case-insensitive substring match'). It distinguishes this tool from siblings by emphasizing its cross-peripheral search capability, unlike tools that might focus on specific peripherals or registers.

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 states when to use this tool: 'when you know part of a register name but not which peripheral it belongs to.' This provides clear guidance on its intended context and distinguishes it from alternatives like list_peripherals or lookup_register, which might be used for different scenarios.

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

Install Server

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

TDQS

A4.4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: list_peripherals discovers hardware blocks, lookup_register provides detailed register layout, describe_field focuses on specific bit-fields, and search_registers enables substring matching. The descriptions explicitly differentiate use cases, eliminating any ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (describe_field, list_peripherals, lookup_register, search_registers) using snake_case throughout. The verbs (describe, list, lookup, search) are distinct and semantically appropriate, creating a predictable and readable naming convention.

Tool Count5/5

With 4 tools, the server is well-scoped for exploring ARM CMSIS SVD files, covering discovery (list_peripherals, search_registers) and detailed inspection (lookup_register, describe_field). Each tool earns its place without redundancy, making the set concise yet complete for the domain.

Completeness5/5

The tool surface provides complete coverage for navigating and understanding SVD files: from high-level peripheral listing to low-level bit-field details, with search functionality to bridge gaps. There are no obvious missing operations, enabling agents to perform all typical workflows without dead ends.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

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

driflyte-mcp-server
com.driflyte
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
Search Web Scraping Knowledge & Memory
211
gread A
io.github.NitroRCr
An MCP server that gives your AI access to the source code and docs of all public github repos
Version Control Code Analysis Documentation Access
5361
Danushkumar-V-mcp-discordOAuth
ai.smithery
An MCP server that integrates with Discord to provide AI-powered features.
Communication Social Media App Automation
2
mcp
dev.augments
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Developer Tools Documentation Access
2128

Related MCP Servers

stm32-mcp-docs
Embedded system Documentation Access Developer Tools
creativec09
A
license
Not graded
quality
C
maintenance
MCP server that provides semantic search and documentation for STM32 microcontrollers, with specialized agents and slash commands for embedded development assistance.
Updated 6 months ago (2026-03-17 03:08 UTC)
11
MIT
JLink MCP Server
Embedded system Developer Tools
cyj0920
A
license
Not graded
quality
C
maintenance
An MCP server that provides comprehensive debugging capabilities for J-Link debuggers, enabling memory, flash, register, and RTT operations through AI assistants.
Updated 5 months ago (2026-04-11 16:08 UTC)
33
MIT
McuBuddy
Embedded system Developer Tools
cunjun
A
license
C
quality
A
maintenance
MCP server for AI-assisted MCU and embedded firmware debugging. It connects to real hardware via debug probes, inspects CPU/memory/peripherals, manages Keil builds, and provides structured evidence for fault diagnosis.
Updated 17 days ago (2026-08-17 06:12 UTC)
19
4
MIT
mcp-stm32cubeide-server
Embedded system Developer Tools
Helistana
A
license
Not graded
quality
C
maintenance
An MCP server that lets AI coding agents drive the full STM32 development loop—code generation, build, flash, debug, serial monitoring, and fault diagnosis—end to end via CubeIDE, CubeMX, CubeProgrammer, OpenOCD, and GDB.
Updated 21 days ago (2026-08-13 19:34 UTC)
MIT

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/pkt-lab/mcp-svd'

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