OpenDeviceDB
NPM · @OPENDEVICEDB/MCP
Check 21,000+ devices with open firmware or protocols before reverse engineering one.
Available components
Last scanned (3 hours ago)
Scores higher than 55% of npm servers
Category IoT and Hardware
How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →
Supply Chain Security98
- No malware found by supply-chain analysis.Pass
- No known CVEs affecting this package version or its production dependencies.Pass
- No install/post-install scripts declared.Pass
- 30 of 93 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency45
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Provenance check failed: no build-provenance attestation is published. See how to fix → View diagnostics → Fail
- Clear OSI-approved license (AGPL-3.0-or-later).Pass
- Actively maintained (last published 18 days ago).Pass
- Disclosure check failed: no security disclosure policy was found in the source repository. See how to fix → Fail
Schema Quality & AI Usability64
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 1437 tokens (~239/item across 6 items; 6 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management63
- Stability observed for 19 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- All 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.Pass
- An AI judge read all 7 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 5 Nov 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 60 to 63. That category is still filling its 30-day observation window: 18 days of observed history at the previous scan, 19 at this one. The score rises as the window fills, whether or not the server changes.
- 3 Nov 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 53 to 57. That category is still filling its 30-day observation window: 16 days of observed history at the previous scan, 17 at this one. The score rises as the window fills, whether or not the server changes.
- 31 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 43 to 47. That category is still filling its 30-day observation window: 13 days of observed history at the previous scan, 14 at this one. The score rises as the window fills, whether or not the server changes.
- 29 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 37 to 40. That category is still filling its 30-day observation window: 11 days of observed history at the previous scan, 12 at this one. The score rises as the window fills, whether or not the server changes.
- 27 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 30 to 33. That category is still filling its 30-day observation window: 9 days of observed history at the previous scan, 10 at this one. The score rises as the window fills, whether or not the server changes.
- 25 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 23 to 27. That category is still filling its 30-day observation window: 7 days of observed history at the previous scan, 8 at this one. The score rises as the window fills, whether or not the server changes.
- 23 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 17 to 20. That category is still filling its 30-day observation window: 5 days of observed history at the previous scan, 6 at this one. The score rises as the window fills, whether or not the server changes.
- 21 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 10 to 13. That category is still filling its 30-day observation window: 3 days of observed history at the previous scan, 4 at this one. The score rises as the window fills, whether or not the server changes.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 5 Nov 2026 · Analysed npm/@opendevicedb/mcp@0.3.0
Provenance No attestation
The registry publishes no build provenance for this version, so there is nothing to verify.
| Result | No attestation |
|---|---|
| Ecosystem | npm |
Background: How many MCP packages publish verified provenance →
Dependencies 93 packages
| Packages resolved | 93 |
|---|---|
| Stale | 30 |
| Tree resolution | Complete |
Background: SBOMs and build attestations, explained →
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
claim_device Claim a device you are about to reverse engineer ~337
Record that you (your human) are working on a device, with a scope, contact and expiry (default 30 days, max 90), so other agents do not duplicate the work. Creates a stub record if the device is unknown (then give vendor, model, category). Writes data/devices/<id>.yaml in the local repository checkout (needs ODB_REPO); you then open a pull request — the result gives the exact commands.
| Name | Type | Req | Description |
|---|---|---|---|
| agent | string | – | Agent/tooling used, e.g. "claude-code + rea 6.5.0". |
| category | string | – | Required only when the device is not in OpenDeviceDB yet. |
| contact | string | yes | How others can reach the claimant: email, GitHub handle, URL of a tracking issue. |
| days | integer | – | Claim duration in days (default 30, max 90). Expired claims are ignored. |
| force_new | boolean | – | Create a new record even though a similar device exists (only if you are sure it is a different device). |
| id | string | – | Device id if it already exists (from lookup_device/search_devices). Otherwise give vendor + model. |
| model | string | – | Model name, used to build the id when the device is new. |
| scope | string | yes | What you will reverse engineer, e.g. "BLE pairing + telemetry", "full Wi-Fi control". |
| vendor | string | – | Manufacturer, used to build the id when the device is new. |
| who | string | yes | Who is working on it: your human's name or handle (and project). |
No output schema declared.
No examples provided.
list_sources List the databases OpenDeviceDB aggregates ~55
Imported source databases with name, url, license, snapshot date and record count, plus the number of curated records. Use it to judge coverage and freshness: a device absent here may still be covered by a source that was not imported.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
lookup_device Look up a device before reverse engineering it ~329
CALL THIS FIRST, before you start reverse engineering any device (drone, camera, router, plug, robot, wearable...). It tells you whether the protocol or a free firmware already exists, whether someone is working on it right now (live claims), and gives a one-line recommendation (e.g. "open firmware exists: use X", "claimed by Y until Z: contact them"). Give identifiers when you have them (FCC id, USB vid:pid, BLE name, Zigbee model): they match better than names. The record's `install` routes (when present) say how to put the open firmware on the device: official guide, installer, difficulty, safety flags. If it answers found: false, nothing is known: call claim_device before starting.
| Name | Type | Req | Description |
|---|---|---|---|
| ble_name | string | – | Bluetooth LE advertised name. |
| fcc_id | string | – | FCC ID from the label, e.g. "SS3-NEO2". Identifiers are the most reliable match. |
| id | string | – | OpenDeviceDB id (<vendor-slug>/<model-slug>) if you already have it, e.g. from search_devices. |
| model | string | – | Model name as printed on the device or box, e.g. "Neo 2". |
| usb | string | – | USB vendor:product id in lowercase hex, e.g. "2ca3:001f" (from lsusb). |
| vendor | string | – | Manufacturer or brand, e.g. "DJI". |
| zigbee_model | string | – | Zigbee modelId reported by the device. |
No output schema declared.
No examples provided.
publish_findings Publish what you found ~244
CALL THIS WHEN YOU FINISH (or stop) a reverse-engineering job, even with partial results. Merges your findings into the record: summary and status replace (status only moves forward), interfaces merge by transport+name (yours replace), projects by url, install routes by method+guide, identifiers and aliases are unioned, verification is appended. The result is validated against the schema; nothing is written on error. Link to your protocol docs/code hosted elsewhere; never include firmware images, vendor code, keys, or anything defeating Remote ID, geofencing or other safety functions (POLICY.md). Set provenance.ai_assisted honestly. Then open a pull request — the result gives the commands.
| Name | Type | Req | Description |
|---|---|---|---|
| allow_downgrade | boolean | – | Allow lowering the status (only when the previous status was wrong; explain why in summary or verification notes). |
| id | string | yes | Device id (from lookup_device or claim_device). |
| patch | object | yes | Findings to merge into the record. |
| release_claim_of | string | – | Remove the live claims of this claimant (the `who` you used in claim_device) now that the work is published. |
No output schema declared.
No examples provided.
request_device Request a device (say your user wants it) ~198
Use when your user wants a device to become usable with open code but will not reverse engineer it themselves (lookup_device found nothing usable). Returns the existing request to add a 👍 to, or a pre-filled link to a new public GitHub issue that the user reviews and submits. Read-only: this tool never posts anything.
| Name | Type | Req | Description |
|---|---|---|---|
| ble_name | string | – | Bluetooth LE advertised name. |
| fcc_id | string | – | FCC ID from the label. |
| goal | string | – | What your user wants to do with it, in their words (e.g. "fly it from Python now that the app is gone"). |
| model | string | yes | Exact model name, e.g. "Bebop 2". |
| usb | string | – | USB vendor:product id (lsusb). |
| vendor | string | yes | Manufacturer or brand, e.g. "Parrot". |
| zigbee_model | string | – | Zigbee modelId. |
No output schema declared.
No examples provided.
search_devices Search the device directory ~174
Ranked full-text search over vendor, model, aliases and identifiers across curated records and imported databases (OpenWrt, Zigbee2MQTT, Tasmota...). Use it to explore ("all DJI drones", "open-firmware cameras") or when lookup_device finds nothing and you suspect another name. Each result has an id to pass to lookup_device.
| Name | Type | Req | Description |
|---|---|---|---|
| category | string | – | Restrict to one device category. |
| limit | integer | – | Maximum results (default 20). |
| query | string | yes | Words to match: vendor, model, alias, or an identifier (FCC id, USB vid:pid, BLE name, chip, SKU). Empty string lists everything. |
| status | string | – | Restrict to one effective status (unknown, in-progress, partial-protocol, controllable, open-firmware). |
No output schema declared.
No examples provided.
How do I install the OpenDeviceDB MCP server?
OpenDeviceDB runs locally as an npm package, launched with npx -y @opendevicedb/mcp. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
npm · @opendevicedb/mcp
claude mcp add org-opendevicedb-opendevicedb -- npx -y @opendevicedb/mcp
What is the OpenDeviceDB MCP server?
OpenDeviceDB is an MCP server listed in the public MCP registry as org.opendevicedb/opendevicedb. Check 21,000+ devices with open firmware or protocols before reverse engineering one. This page covers its npm package (@opendevicedb/mcp).
Is the OpenDeviceDB MCP server safe to use?
OpenDeviceDB scores 77 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 5 November 2026. It declares no install or post-install scripts. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the OpenDeviceDB MCP server expose?
OpenDeviceDB exposes 6 tools: lookup_device, search_devices, claim_device, publish_findings, request_device, list_sources. Their descriptions and schemas cost roughly 1,337 tokens of context every time the server is loaded.
Is the OpenDeviceDB MCP server still maintained?
OpenDeviceDB is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.
What licence is the OpenDeviceDB MCP server under?
OpenDeviceDB declares the AGPL-3.0-or-later licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.