Which integrations are available for this server?

Allows an AI assistant to monitor and control OpenWrt-based WiFi routers, including listing connected devices, inspecting WiFi networks, checking WAN status, changing SSIDs, and rebooting the router.

How do I use router-mcp?

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., "@router-mcp list connected devices" 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.

router-mcp

by sudip490

Overview Schema Related Servers Score Discussions

TypeScript

Local

router-mcp

npm

A Model Context Protocol (MCP) server + CLI that lets an AI assistant (Claude, or any MCP client) monitor and control your WiFi router — list connected devices, inspect WiFi networks, check WAN status, change SSIDs, reboot, and more.

Published as @subashgautam/router-mcp. After a global install the CLI command is just router-mcp.

Built on @modelcontextprotocol/sdk. Designed around pluggable adapters, so it can target any router family. It ships with:

openwrt — talks to OpenWrt (and most derivatives) over SSH using ubus / uci.
mock — realistic fake data so you can try everything with no hardware.

It is also a normal TypeScript/JavaScript library you can import.

Features

🔌 MCP server — exposes router operations as MCP tools to any MCP client.
🖥️ CLI — drive your router straight from the terminal (router-mcp devices, status, wifi, ...).
🧩 Pluggable adapters — add a new router backend by implementing one interface.
🔒 Safe by default — read-only unless you explicitly opt in to writes (--allow-write) and raw command execution (--allow-exec).
📦 Library + CLI — import { OpenWrtAdapter } from "@subashgautam/router-mcp" or run the binary.

Related MCP server: STB MCP Server

Install

# Use immediately with no install
npx @subashgautam/router-mcp status --adapter mock

# Or install globally for the CLI (provides the `router-mcp` command)
npm install -g @subashgautam/router-mcp

# Or as a project dependency (library use)
npm install @subashgautam/router-mcp

Requires Node.js >= 18.

Quick start

1. Try it with no hardware (mock adapter)

npx @subashgautam/router-mcp status   --adapter mock
npx @subashgautam/router-mcp devices  --adapter mock
npx @subashgautam/router-mcp wifi     --adapter mock

Tip: after npm install -g @subashgautam/router-mcp you can drop the npx @subashgautam/ prefix and just run router-mcp status etc.

2. Point it at a real OpenWrt router

# Prefer the env var (or --key) so the password isn't visible in the process list:
ROUTER_HOST=192.168.1.1 ROUTER_USER=root ROUTER_PASSWORD='yourpass' npx @subashgautam/router-mcp devices

# --password also works, but see the security note below.
npx @subashgautam/router-mcp devices --host 192.168.1.1 --user root --password 'yourpass'

3. Use it as an MCP server (Claude Desktop, etc.)

Add to your MCP client config (see examples/claude_desktop_config.json):

{
  "mcpServers": {
    "router": {
      "command": "npx",
      "args": ["-y", "@subashgautam/router-mcp", "serve"],
      "env": {
        "ROUTER_ADAPTER": "openwrt",
        "ROUTER_HOST": "192.168.1.1",
        "ROUTER_USER": "root",
        "ROUTER_PASSWORD": "your-router-password",
        "ROUTER_ALLOW_WRITE": "1"
      }
    }
  }
}

Then ask your assistant things like "which devices are connected to my router?" or "rename my 2.4GHz WiFi to HomeNet".

MCP tools

Tool	Permission	Description
`router_status`	read	Model, firmware, hostname, uptime, load, memory.
`list_devices`	read	Connected/known clients: MAC, IP, hostname, signal, interface.
`list_wifi_networks`	read	Configured SSIDs with id, state, channel, band, encryption.
`wan_info`	read	WAN/upstream: up state, protocol, public IP, gateway, uptime.
`set_wifi`	write	Change an SSID's name, password, channel, or enabled state.
`reboot_router`	write	Reboot the router (requires `confirm: true`).
`run_command`	exec	Run a raw shell command on the router.

Write tools appear only when the server is started with --allow-write; run_command only with --allow-exec.

CLI reference

router-mcp [serve] [options]      Start the MCP server over stdio (default)
router-mcp <command> [options]    Run a command directly against the router

Commands:
  serve            Run the MCP server (stdio). Default when no command given.
  status           Show router model, firmware, uptime, load, memory.
  devices          List connected/known devices.
  wifi             List configured WiFi networks.
  wan              Show WAN/upstream connection info.
  reboot           Reboot the router (needs --allow-write).
  exec "<cmd>"     Run a raw shell command on the router (needs --allow-exec).

Options:
  --adapter <openwrt|mock>   Default: openwrt if --host given, else mock.
  --host --port --user --password --key --wan-iface
  --allow-write  --allow-exec  --json  -h/--help  -v/--version

Environment variables

ROUTER_ADAPTER, ROUTER_HOST, ROUTER_PORT, ROUTER_USER, ROUTER_PASSWORD, ROUTER_KEY, ROUTER_WAN_IFACE, ROUTER_ALLOW_WRITE, ROUTER_ALLOW_EXEC.

Library usage

import { OpenWrtAdapter, startStdioServer } from "@subashgautam/router-mcp";

// Use an adapter directly
const router = new OpenWrtAdapter({ host: "192.168.1.1", password: "..." });
console.log(await router.getStatus());
console.log(await router.listDevices());
await router.close();

// Or start a full MCP server programmatically
await startStdioServer({ adapter: "openwrt", host: "192.168.1.1", password: "...", allowWrite: true });

Writing a custom adapter

Implement the RouterAdapter interface and pass an instance to buildServer:

import { buildServer, type RouterAdapter } from "@subashgautam/router-mcp";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";

class MyRouterAdapter implements RouterAdapter {
  readonly name = "myrouter";
  async getStatus() { /* ... */ return {}; }
  async listDevices() { return []; }
  async getWifiNetworks() { return []; }
  async getWanInfo() { return {}; }
  async setWifi() { /* ... */ }
  async reboot() { /* ... */ }
}

const server = buildServer({
  adapter: new MyRouterAdapter(),
  config: { allowWrite: true, allowExec: false },
});
await server.connect(new StdioServerTransport());

Security notes

The server is read-only by default. Enabling --allow-write / --allow-exec lets an AI client change settings or run commands on your router — only enable what you need.
Avoid --password on the command line — process arguments are world-readable on most systems (ps aux, /proc/<pid>/cmdline), so the password leaks to other local users. Prefer key-based SSH auth (--key) or the ROUTER_PASSWORD environment variable.
run_command is powerful; treat it like giving shell access. It is only available with --allow-exec.
Wifi network ids passed to set_wifi are validated against the uci section-name charset ([A-Za-z0-9_]) before use, so a malicious id cannot inject shell commands.

License

MIT © SwiftTech

Available Tools

7 tools

list_devicesList connected devicesA

Read-only

List clients known to the router (DHCP leases plus wireless associations): MAC, IP, hostname, signal (dBm) and interface.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so the description does not need to restate. It adds useful content about what is listed (DHCP leases, wireless associations) and the fields returned, which enhances transparency beyond annotations.

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 a single, front-loaded sentence with no wasted words. Every part ('List clients known to the router', parenthetical explanation, field list) is necessary and contributes to understanding.

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 no parameters, no output schema, and good annotations, the description fully explains the tool's purpose and return values (MAC, IP, hostname, signal, interface). It is complete for a read-only list operation.

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

Parameters4/5

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

The tool has zero parameters, and the schema coverage is 100% (implicitly, as there are no properties). Per guidelines, a baseline of 4 is appropriate since the description needs no parameter information.

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 verb 'List' and the resource 'clients known to the router', specifying the data fields (MAC, IP, hostname, signal, interface). It distinguishes from siblings like list_wifi_networks which lists networks, not clients.

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

Usage Guidelines3/5

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

The description implies usage for seeing connected devices but does not explicitly mention when to use or not use this tool versus alternatives like list_wifi_networks or router_status. No exclusionary guidance is provided.

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

list_wifi_networksList WiFi networksA

Read-only

List configured wireless networks (SSIDs) with their id, enabled state, channel, band and encryption. Use the id with set_wifi.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, indicating safe read behavior and dynamic results. The description adds value by detailing the output fields, which is sufficient for this simple tool without need for additional caveats.

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?

Two concise sentences front-load the purpose and key fields, with zero redundancy or wasted words. Every sentence earns its place.

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 read-only list tool with no parameters and no output schema, the description is fairly complete: it lists the returned fields and hints at cross-tool usage. It could mention possible empty results or error scenarios, but given the simplicity and annotation coverage, this is adequate.

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

Parameters4/5

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

The tool has no parameters and schema coverage is 100% (empty object). The description does not add parameter information, but baseline for 0 parameters is 4, and no further semantic clarification is needed.

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 lists configured wireless networks and specifies the exact fields returned: id, enabled state, channel, band, and encryption. It also notes the id's integration with set_wifi, providing a concrete use case.

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 explicitly mentions using the id with set_wifi, which serves as a guideline for when to use this tool. While it doesn't explicitly state when not to use it, the context of sibling tools like set_wifi and reboot_router helps differentiate, and the advice is clear and actionable.

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

reboot_routerReboot routerA

Destructive

Reboot the router. The connection will drop and the router will be unreachable for ~1-2 minutes.

ParametersJSON Schema

Name	Required	Description	Default
`confirm`	Yes	Must be true to actually reboot. A safety guard against accidental reboots.

TDQS

A4/5.0

Behavior4/5

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

Adds specific behavioral detail beyond annotations: connection drop and unreachable duration (~1-2 min). Annotations give destructiveHint=true, but description adds the temporal impact.

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?

Two concise sentences, front-loaded with the action, no redundant information. Every word earns its place.

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 simplicity (one param, no output schema), the description covers the effect and duration. Lacks details on post-reboot state but sufficient for basic usage.

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% for the single parameter 'confirm'. The description adds no extra meaning beyond what the schema already provides.

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?

Clearly states the action 'Reboot' and the resource 'router'. Distinguishes from sibling tools like list_devices or router_status by focusing on a specific disruptive operation.

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

Usage Guidelines3/5

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

Implied usage: the description notes the effect (connection drop, unreachable for 1-2 min), which signals it's for reboots. But no explicit when-to-use vs alternatives or when not to use.

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

router_statusRouter statusA

Read-only

Get router identity and health: model, firmware, hostname, uptime, load average and memory.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior4/5

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

Description adds context beyond annotations (readOnlyHint, openWorldHint) by specifying the exact attributes returned. No contradictory or missing behavioral traits.

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?

Single sentence, clear and to the point. Could be more structured (e.g., bullet points) but efficient for the content.

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 no-parameter, read-only tool with no output schema, the description adequately covers what is returned. Could add real-time vs cached detail, but sufficient given sibling context.

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

Parameters4/5

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

No parameters to document, so baseline is 4. Description doesn't need to add parameter meaning since schema coverage is 100% (no params).

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?

Description clearly states the action ('Get router identity and health') and lists specific fields (model, firmware, hostname, uptime, load average, memory). Distinguishes from sibling tools like list_devices (device list) and wan_info (WAN status) by focusing on the router itself.

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

Usage Guidelines3/5

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

No explicit guidance on when to use this tool vs alternatives. The purpose implies it's for general router status, but no exclusion or when-not-to-use is provided.

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

run_commandRun a raw commandA

Destructive

Run an arbitrary shell command on the router and return its output. Powerful and dangerous — only enabled when the operator started the server with exec permission.

ParametersJSON Schema

Name	Required	Description	Default
`command`	Yes	The shell command to execute on the router

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already indicate destructiveHint=true and readOnlyHint=false. Description adds that it is 'powerful and dangerous' and requires operator-granted exec permission, enhancing transparency without contradiction.

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?

Two concise sentences with front-loaded purpose, zero redundancy, and all necessary information.

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?

For a simple destructive tool with one parameter and no output schema, the description covers the critical permission constraint, making it fully adequate for correct agent 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?

The lone parameter 'command' is fully described in the schema (100% coverage). The description adds no new semantic details beyond what the schema provides, meeting the baseline.

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 runs an arbitrary shell command on the router and returns output, distinguishing it from sibling tools like list_devices or reboot_router.

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 states it is powerful and dangerous, only enabled when exec permission is granted, guiding agents to use cautiously and only when authorized.

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

set_wifiChange a WiFi networkA

Destructive

Modify an existing wireless network identified by its id (from list_wifi_networks). Any subset of fields may be supplied. Changes are committed and the radios reloaded.

ParametersJSON Schema

Name	Required	Description
`id`	Yes	Wifi network id from list_wifi_networks
`ssid`	No	New SSID (network name)
`channel`	No	New radio channel (e.g. 6, 36, or 'auto')
`enabled`	No	Enable or disable the network
`password`	No	New pre-shared key / passphrase

TDQS

A4.2/5.0

Behavior4/5

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

Annotations indicate destructive and open-world nature, but the description adds critical detail: 'Changes are committed and the radios reloaded.' This reveals a reload side effect beyond what annotations convey. No contradiction with annotations.

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?

Two sentences, no fluff. The first sentence defines the action and identifier; the second explains partial updates and commitment behavior. Every part earns its place.

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?

The description explains what the tool does, how to identify the network, partial update capability, and behavior (commit/reload). No output schema exists, so return values are not expected. Minor omission: no mention of error cases or confirmation, but overall complete enough.

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?

Input schema has 100% description coverage for all 5 parameters, so the schema already explains each field. The description only reiterates that any subset may be supplied, which adds no new meaning. Baseline 3 is appropriate.

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 modifies an existing wireless network, specifies the identifier source (list_wifi_networks), and allows partial updates. This verb+resource combination is unambiguous and distinct from sibling tools, which focus on listing, rebooting, or status checks.

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 explicitly ties usage to an ID from list_wifi_networks, providing clear context. However, it does not mention when not to use this tool or list alternative approaches for wifi changes (though no alternatives exist among siblings). The guidance is adequate.

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

wan_infoWAN connection infoA

Read-only

Get the upstream/WAN connection: up state, protocol, public IP, gateway and uptime.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior4/5

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

The description adds value beyond annotations by specifying the returned fields (up state, protocol, IP, gateway, uptime). Annotations already declare readOnlyHint and openWorldHint, so the non-destructive, read-only behavior is clear. No contradictions.

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?

Single sentence of 13 words, efficiently conveying all essential information. No redundant or unnecessary content. Front-loaded with the main action.

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 the tool's trivial complexity (zero parameters, no output schema), the description fully covers its purpose and returned data. No additional information is needed for correct usage.

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

Parameters4/5

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

No parameters exist, so the description cannot add parameter-level detail. Schema coverage is 100% trivially. Baseline score of 4 is appropriate as there is no missing parameter information.

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 function: retrieving upstream/WAN connection details, and lists the exact data fields (up state, protocol, public IP, gateway, uptime). It is distinct from sibling tools like 'router_status' or 'list_devices'.

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

Usage Guidelines3/5

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

No explicit guidance on when to use versus alternatives. However, the tool's simplicity and zero parameters make its usage obvious—it is for retrieving WAN info. No exclusions or when-not-to-use advice is provided.

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.

7 tool updatesv0.1.0Jul 1, 2026
- First observedlist_devices
- First observedlist_wifi_networks
- First observedreboot_router
- First observedrouter_status
- First observedrun_command
- First observedset_wifi
- First observedwan_info

Install Server

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

TDQS

A4.2/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: listing clients, listing WiFi networks, rebooting, system status, arbitrary commands, modifying WiFi, and WAN info. No overlap or ambiguity.

Naming Consistency4/5

Most tools use verb_noun (list_devices, reboot_router, run_command, set_wifi) while router_status and wan_info use noun_noun. This is a minor inconsistency, but the pattern is still predictable overall.

Tool Count5/5

7 tools is well-scoped for a router management server. Each tool covers a fundamental operation, neither too few nor too many.

Completeness3/5

Covers core router operations (clients, WiFi, reboot, status, WAN), but lacks a create_wifi tool for adding new networks. The run_command provides a fallback, but its restriction and danger limit completeness.

Maintenance

ActivityStale

ResponsivenessNo issues

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

Home Automation Mcp D
io.github.varvararatta
MCP server for Home Automation
Home Automation & IoT
2
Os Automation Mcp C
io.github.varvararatta
MCP server for OS Automation
OS Automation Command Line
2
hostinger-api-mcpOAuth
io.github.hostinger
MCP server for Hostinger API
Cloud Platforms Developer Tools
1150
AgentMarketplace A
io.github.raditotev
MCP Server for an Agent Task Marketplace
Autonomous Agents Agent Orchestration
221

Related MCP Servers

MikroTik WiFi Users
Networking & Infrastructure Monitoring
piotron
A
license
Not graded
quality
D
maintenance
MCP server for querying connected WiFi devices from MikroTik RouterOS, enriched with DHCP leases and ARP table entries.
Updated 6 months ago (2026-03-14 21:59 UTC)
MIT
STB MCP Server
Shell Access File Systems Monitoring
lightnet19
A
license
Not graded
quality
B
maintenance
MCP server for full control of STB (Amlogic S9xx / Armbian) via SSH, enabling shell commands, file management, Docker operations, AdGuard Home configuration, and system monitoring.
Updated a month ago (2026-08-07 12:07 UTC)
MIT
mikrotik-mcp
Networking & Infrastructure Command Line Monitoring
vesact
A
license
Not graded
quality
B
maintenance
MCP server for managing MikroTik RouterOS fleets, exposing 65+ tools for system administration, interfaces, firewall, DHCP/DNS, PPP, diagnostics, and SSH command execution with KeePass-backed credentials.
Updated a month ago (2026-08-05 18:58 UTC)
13
2
Apache 2.0
openwisp-mcp
Networking & Infrastructure Monitoring
marten-lucas
A
license
Not graded
quality
B
maintenance
MCP server for managing OpenWISP network infrastructure, enabling AI assistants to control devices, templates, topologies, and RADIUS sessions via the OpenWISP REST API.
Updated 23 days ago (2026-08-14 11:40 UTC)
21
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/sudip490/ROUTER-MCP-NPM-PACKAGE'

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