devglow
NPM · DEVGLOW-MCP · SCANNED SEP 24
Start, stop, and inspect local dev servers in a desktop app instead of the agent's session.
Available components
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
- 31 of 96 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 (MIT).Pass
- Actively maintained (last published 2 days ago).Pass
- Disclosure check failed: no security disclosure policy was found in the source repository. See how to fix → Fail
Schema Quality & AI Usability69
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 2345 tokens (~180/item across 13 items; 13 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 Management100
- No destabilizing schema changes in the last 30 days.Pass
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 Safety75
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- 0 of 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation; "delete_project" implies "delete" and declares no destructiveHint at all, which the MCP spec reads as destructive by default. See how to fix → Fail
- An AI judge read all 14 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
How do I install the devglow MCP server?
devglow runs locally as an npm package, launched with npx -y devglow-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 · devglow-mcp
claude mcp add app-devglow-devglow -- npx -y devglow-mcp
{
"mcpServers": {
"app-devglow-devglow": {
"command": "npx",
"args": [
"-y",
"devglow-mcp"
]
}
}
} {
"servers": {
"app-devglow-devglow": {
"command": "npx",
"args": [
"-y",
"devglow-mcp"
]
}
}
} codex mcp add app-devglow-devglow -- npx -y devglow-mcp
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"app-devglow-devglow": {
"type": "local",
"command": [
"npx",
"-y",
"devglow-mcp"
],
"enabled": true
}
}
} openclaw mcp add app-devglow-devglow --command npx --arg -y --arg devglow-mcp
mcp_servers:
app-devglow-devglow:
command: "npx"
args: ["-y", "devglow-mcp"] {
"McpServers": {
"app-devglow-devglow": {
"Transport": "stdio",
"Command": "npx",
"Arguments": [
"-y",
"devglow-mcp"
]
}
}
} assistant mcp add app-devglow-devglow -t stdio -c npx -a -y devglow-mcp
{
"mcpServers": {
"app-devglow-devglow": {
"command": "npx",
"args": [
"-y",
"devglow-mcp"
]
}
}
} 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.
- 24 Sept 26 0
- Stability: 0.97 → pass security
- 23 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 93 to 97. That category is still filling its 30-day observation window: 28 days of observed history at the previous scan, 29 at this one. The score rises as the window fills, whether or not the server changes.
- 20 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 83 to 87. That category is still filling its 30-day observation window: 25 days of observed history at the previous scan, 26 at this one. The score rises as the window fills, whether or not the server changes.
- 18 Sept 26 −2
- Stability: pass → 0.80 functional
- 17 Sept 26 0
- Stability: 0.97 → pass security
- 16 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 93 to 97. That category is still filling its 30-day observation window: 28 days of observed history at the previous scan, 29 at this one. The score rises as the window fills, whether or not the server changes.
- 13 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 83 to 87. That category is still filling its 30-day observation window: 25 days of observed history at the previous scan, 26 at this one. The score rises as the window fills, whether or not the server changes.
- 11 Sept 26 −2
- Stability: pass → 0.80 functional
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 24 Sept 2026 · Analysed npm/devglow-mcp@1.3.2
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 96 packages
| Packages resolved | 96 |
|---|---|
| Stale | 31 |
| 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 →
check_port Check port availability ~71
Check if a TCP port is in use on localhost. When occupied, also reports who holds it — and if it's a devglow-managed project (so the user can recognize their own process). Call this BEFORE run_process / create_project to avoid silent conflicts.
| Name | Type | Req | Description |
|---|---|---|---|
| port | number | yes | Port number to check |
No output schema declared.
No examples provided.
create_project Create a permanent project (without running) ~351
Register a permanent DevGlow project WITHOUT running it. This is how you 'add a project to DevGlow' — there is no config file to author (no devglow.json / DEVGLOW.md); calling this tool IS the registration. Use it for bulk registration when you want to record metadata only (no port binding, no browser tab, no dependency install). To start the project later, call start_project. Use run_process instead when you need to actually launch a server for verification or one-off work.
| Name | Type | Req | Description |
|---|---|---|---|
| command | string | yes | Shell command to run when the user starts the project. |
| description | string | – | Short summary of what the app does (max 280 chars). |
| interactive | boolean | – | Run in a PTY (interactive terminal) so tty-driven tools like `flutter run` / `expo start` enter interactive mode and accept key input (hot reload r, restart R). DEFAULT: omit — the command is auto-de… |
| name | string | yes | Display name. |
| path | string | yes | Working directory (supports ~/). |
| port | number | – | Port number the command listens on, if any. Used for the Open ↗ button. |
| tags | array | – | Tags. DEFAULT: omit (no tags). Tags are the user's manual grouping system — do NOT auto-fill with technology guesses (e.g., 'db', 'test', 'api'). Only set this when the new project clearly belongs to… |
No output schema declared.
No examples provided.
delete_project Delete a permanent project ~64
Delete a kept (permanent) DevGlow project. Stops the process if running. Does NOT apply to AI processes — those are dismissed via the UI.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | Project id (call list_projects first). Must be a permanent project, not an AI process. |
No output schema declared.
No examples provided.
get_logs Get process logs ~50
Export and retrieve recent logs from a running or stopped process.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | Project or AI process ID |
| lines | number | – | Number of recent lines to return (default: 100) |
No output schema declared.
No examples provided.
get_project Get full project details ~78
Get the full metadata for a single project or AI process (path, command, port, tags, description, status). Use this when you need details beyond what list_projects shows — for example, to duplicate a project with the same path or read its description before editing.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | Project or AI process ID (from list_projects) |
No output schema declared.
No examples provided.
get_status Get project status ~32
Get the running status of a specific project or AI process.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | Project or AI process ID |
No output schema declared.
No examples provided.
list_projects List all projects ~21
List all registered user projects and AI temporary processes with their status.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
run_process Run a new AI process ~242
Create and start ONE new temporary process. Shows in DevGlow's AI Processes section. User can later [keep] or [dismiss] it. Before calling this, run list_projects: if the user already registered a project for this path/command, call start_project instead so you run THEIR command, not a new one. Only use run_process when no matching project exists. If you are starting more than one process, call workspace_run once instead of calling this repeatedly — otherwise each process waits in the sidebar and the user sees nothing happen.
| Name | Type | Req | Description |
|---|---|---|---|
| command | string | yes | Shell command to execute |
| description | string | – | Short summary of what the app does (max 280 chars). Helps the user remember the project later. Write 1-2 plain sentences from the user's perspective. |
| name | string | yes | Display name for the process. Do NOT include port number in the name — use the port parameter instead. |
| path | string | yes | Working directory (supports ~/) |
| port | number | – | Port number the process will listen on. Check package.json scripts or config files for --port flags. Important for DevGlow to show the correct port badge. |
No output schema declared.
No examples provided.
start_project Start a registered project ~80
Start a user-registered project using its configured command (cannot modify the command). PREFER this over run_process: call list_projects first, and if a project for this path/command already exists, start it here instead of re-running it yourself. This reuses the command the user registered.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | Project ID (from list_projects) |
No output schema declared.
No examples provided.
stop_process Stop an AI process ~27
Stop a running AI temporary process by name.
| Name | Type | Req | Description |
|---|---|---|---|
| name | string | yes | AI process name |
No output schema declared.
No examples provided.
stop_project Stop a project ~28
Stop a running project or AI process.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | Project or AI process ID |
No output schema declared.
No examples provided.
update_project Update a project's metadata ~264
Update a kept (permanent) DevGlow project's metadata. Pass only the fields you want to change. Does NOT apply to temporary AI processes — for those, set fields at run_process time or have the user keep the process first.
| Name | Type | Req | Description |
|---|---|---|---|
| command | string | – | New shell command. |
| description | – | – | Short summary (max 280 chars). Pass null or empty string to clear. |
| id | string | yes | Project id (call list_projects first). Must be a permanent project, not an AI process (those have ids starting with 'ai-'). |
| interactive | boolean | – | Toggle PTY (interactive terminal) mode. true = run through a pseudo-terminal so tools like flutter run / expo start accept hot reload (r) / restart (R) keys; false = plain pipe. Only set when the use… |
| name | string | – | New display name. |
| path | string | – | New working directory (supports ~/). |
| port | number|null | – | New port number. Pass null to clear the existing port. |
| tags | array | – | Tags as a list of strings. Pass [] to clear. Do NOT invent tags; only set this when the user explicitly asks, or when reusing an existing tag visible in list_projects. |
No output schema declared.
No examples provided.
workspace_run Run processes in a new workspace ~239
Start two or more processes and arrange them on screen together in a new DevGlow workspace. PREFER this over repeated run_process calls whenever you are starting more than one process — the user does not have to ask to see them. Repeated run_process calls leave each process sitting in the sidebar until the user clicks it into a pane, so starting three that way makes the app look like nothing happened. Each process here starts exactly as run_process would. Always creates a new workspace: a name that already exists gets a numbered variant, and no existing workspace is ever modified, so a repeat call cannot disturb the user's arrangement. DevGlow chooses the split layout from its own window size; you cannot specify one. If DevGlow is closed it will be launched.
| Name | Type | Req | Description |
|---|---|---|---|
| name | string | yes | Name for the new workspace, as the user will see it in the sidebar. Describe the group, not one process (e.g. 'api stack', 'checkout debug'). |
| processes | array | yes | Processes to start, in the order they should appear on screen. Panes beyond DevGlow's 8-pane cap still run; they just wait in the sidebar. |
No output schema declared.
No examples provided.
What is the devglow MCP server?
devglow is an MCP server listed in the public MCP registry as app.devglow/devglow. Start, stop, and inspect local dev servers in a desktop app instead of the agent's session. This page covers its npm package (devglow-mcp).
Is the devglow MCP server safe to use?
devglow scores 81 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 24 September 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 devglow MCP server expose?
devglow exposes 13 tools: list_projects, get_status, get_project, get_logs, check_port, and 8 more. Their descriptions and schemas cost roughly 1,547 tokens of context every time the server is loaded.
Is the devglow MCP server still maintained?
devglow is still listed as active in the MCP registry. We last reached this channel on 24 September 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 devglow MCP server under?
devglow declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.