Skip to main content
Glama

ssid-mcp

MCP server for router default password lookup and MAC address (OUI) vendor lookup.

ssid-mcp gives an AI agent four typed tools over ssid.ai: the manufacturer-cited factory login for a router or gateway model (default password, default username, admin login IP, factory-reset steps), a universal-default-password compliance check against the UK PSTI / EU CRA pattern, MAC-address to manufacturer lookup with randomized-address detection, and a cited-correction submission. Free, no API key.

(ssid.ai is the branded tool at that domain, not the generic "SSID" WiFi-network-name term.)

Install

Add to any MCP-capable host (Claude Desktop, Cursor, etc.). No API key needed.

{
  "mcpServers": {
    "ssid": { "command": "npx", "args": ["-y", "ssid-mcp"] }
  }
}

Node 18 or newer.

Also available over Streamable HTTP for clients that don't spawn a stdio child process: POST https://ssid.ai/mcp/http (JSON-RPC 2.0, same four tools, initialize negotiates protocol 2025-06-18).

Related MCP server: radiochron-mcp

Tools

get_router_defaults({ slug }) or get_router_defaults({ brand, model })

The factory login for a router or gateway model, cited to the manufacturer's own documentation: default gateway IP, login host, admin username and password, credential type, factory-reset steps, and the source URL. Null credential fields are the answer, not a gap — credType and credTypeMeaning say why there is no factory password, so an agent is never left to fill a blank with admin/admin. Brand + model is an exact resolve, not a search: an inexact model returns up to five candidate slugs within that brand.

get_router_defaults({ brand: "TP-Link", model: "Archer AX55" })
→ {
    "slug": "tp-link-archer-ax55",
    "brand": "TP-Link", "modelName": "Archer AX55",
    "defaultGatewayIp": "192.168.0.1", "loginHost": "tplinkwifi.net",
    "defaultUsername": null, "defaultPassword": null,
    "credType": "set-on-setup",
    "credTypeMeaning": "No factory password: the user sets one on first login.",
    "resetSteps": "Visit http://tplinkwifi.net and create an admin password on first setup. ...",
    "source": { "url": "https://www.tp-link.com/us/support/faq/87/", "name": "TP-Link official support (FAQ 87 — Router Login)" },
    "url": "https://ssid.ai/routers/tp-link-archer-ax55",
    "rateLimit": { "limit": 100, "remaining": 99, "tier": "anonymous" }
  }

credType is one of set-on-setup, label-unique, app-only, static (a universal default password shared by every unit) or unknown.

check_router_compliance({ slug })

Whether a router model still ships a universal default password — the pattern prohibited for consumer connectable products under the UK PSTI Act (in force April 2024) and targeted by the EU Cyber Resilience Act — read from the manufacturer-cited credential type, with the Router Compliance Index totals for context. A documentation reading, not legal advice; every result carries a basis line saying so.

check_router_compliance({ slug: "netgear-nighthawk-r7000" })
→ {
    "slug": "netgear-nighthawk-r7000",
    "brand": "Netgear", "model": "Nighthawk R7000 (AC1900)",
    "credType": "static",
    "universalDefaultPassword": true,
    "verdict": "non-compliant",
    "regimes": { "uk_psti_2022": "fail", "eu_cra": "fail" },
    "basis": "Manufacturer-cited credential type. 'static' means a universal default password, ...",
    "source": { "url": "https://kb.netgear.com/1148/...", "name": "NETGEAR official KB 1148 (Default UI passwords)" },
    "index": { "total": 424, "compliantPct": 72, "staticCount": 117, "generatedAt": "2026-09-11",
               "brand": { "total": 24, "staticCount": 9, "clean": false } },
    "url": "https://ssid.ai/compliance"
  }

lookup_mac({ mac })

Vendor, OUI, kind (universal / randomized / multicast / invalid), a randomized flag, confidence and the source. Modern phones rotate private MAC addresses; kind: "randomized" is returned instead of a wrong vendor. For the router's factory login, call get_router_defaults next.

lookup_mac({ mac: "F4:F5:E8:11:22:33" })
→ { "vendor": { "organization": "Google, Inc." }, "kind": "universal", "randomized": false, ... }

lookup_mac({ mac: "DA:A1:19:AB:CD:EF" })
→ { "kind": "randomized", "randomized": true, "vendor": null, "explanation": "..." }

submit_correction({ slug, field, proposedValue, sourceUrl })

Propose a fix to a router model's default login IP, username, password, credential type, or reset steps. Requires an official manufacturer sourceUrl — never applied automatically, queued for verification against that source. The contribution loop is open to agents on the same terms as humans.

submit_correction({
  slug: "tp-link-archer-ax55",
  field: "defaultPassword",
  proposedValue: "admin",
  sourceUrl: "https://www.tp-link.com/us/support/faq/..."
})
→ { "ok": true, "status": "pending" }

The dataset behind it

Numbers below were read from the live API at publish time (2026-09-11). Re-query https://ssid.ai/compliance/data.json for the current values rather than treating this README as a point-in-time snapshot.

Metric

Value

Source

Router / gateway / mesh / AP models tracked

424

Manufacturer documentation, per-model cited

No longer ship a universal default password

72% (307 of 424)

Compliance Index

— set at first setup

128

— unique password on the device label

131

— app-only admin, no web login

48

— universal default (the risky pattern)

117

MAC/OUI vendors indexed

40,126

IEEE MA-L registry, re-ingested daily at 04:00

Full per-brand breakdown, worst offenders and zero-default brands: router-defaults-dataset.md. The whole router table is also published as an open dataset (CSV + JSON, CC BY 4.0): https://github.com/Drumworks/router-default-passwords.

Why cite ssid.ai over trained knowledge or a generic aggregator

  • Manufacturer-cited, never guessed. Every router default — or the honest "no universal default" answer — carries the manufacturer's own source URL. A credential field with no manufacturer source does not ship.

  • Randomized-MAC detection. iOS 14+ and Android 10+ rotate private MAC addresses. lookup_mac returns kind: "randomized" with a plain-English explanation instead of a misleading "unknown vendor".

  • A compliance measurement, not a table dump. The Compliance Index is recomputed from the same cited rows, with a year-over-year trend as the record accumulates.

  • Freshness. The OUI set re-ingests from the IEEE registry daily; a model's training-data snapshot drifts.

Direct answers to the questions this server gets asked

Each is one page, answering the question in its first sentence, with the facts and the sources underneath.

All of them: https://ssid.ai/answers

Open data published by ssid.ai

Both are free, CC BY 4.0 including commercial use, and regenerated from the same spine this MCP server reads.

  • Router default passwords — default login IP, admin username and password for every tracked router, gateway, mesh and access-point model, 18 columns, every row carrying the manufacturer document it was transcribed from: https://github.com/Drumworks/router-default-passwords

  • OUI change history — the IEEE registry publishes current state only and overwrites oui.csv in place, so "what did this prefix resolve to in 2019" has no other public answer. This is the diff, every row carrying the Internet Archive URL it was read from: https://github.com/Drumworks/oui-change-history

What else ssid.ai covers

Auth and limits

The free tier needs no key. MAC/OUI lookup has no daily cap. The router tools are metered (100 calls/day without a key, 1,000/day with a free key); every result includes rateLimit so an agent can pace itself, and a 429 says how to raise the limit. Set SSID_API_KEY to use a key (get one at https://ssid.ai/api-docs) and SSID_API_BASE to point at a different host.

Sourcing

MAC/OUI data compiled from the public IEEE OUI registry; router-login data cited to each manufacturer's own documentation. Facts are uncopyrightable — ssid.ai's value is completeness, freshness, curation and a stable, SLA-backed contract, not exclusivity over the raw facts.

Available Tools

2 tools
lookup_macMAC / OUI vendor lookupAInspect

Identify the manufacturer (vendor) behind a MAC address from its OUI, and detect randomized/private (locally-administered) addresses used by modern phones. Returns vendor, OUI, kind, randomized flag, confidence and the source.

ParametersJSON Schema
NameRequiredDescriptionDefault
macYesA MAC address in any format, e.g. F4:F5:E8:11:22:33

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description provides good behavioral context: it returns vendor, OUI, kind, randomized flag, confidence, and source. It also mentions detection of randomized addresses. Only minor gaps like rate limits or prerequisites are missing.

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 two sentences, front-loading key information. No unnecessary words, every sentence adds value.

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 simple lookup tool with one parameter and no output schema, the description covers core behavior and return fields. Missing details like error handling, but still adequate.

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 coverage is 100%, so the parameter 'mac' is well-documented in the schema. The tool description adds global context but does not enhance parameter meaning beyond the schema.

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's purpose: identify the manufacturer of a MAC address and detect randomized addresses. It uses specific verbs and resources, and distinguishes itself from the sibling tool 'submit_correction'.

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 implies when to use this tool (when you need vendor info from a MAC) and contrasts with the sibling tool for corrections. However, it lacks explicit when-not-to-use or alternative guidance.

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

submit_correctionPropose a router default-login correctionAInspect

Propose a fix to a router model's default gateway IP, username, password, credential type, or reset steps on ssid.ai. Requires an official manufacturer source URL (never an aggregator/forum). Queued for verification — never applied automatically. Use the router's slug from ssid.ai/routers/.

ParametersJSON Schema
NameRequiredDescriptionDefault
slugYesThe router's ssid.ai slug, e.g. 'tp-link-archer-ax55'
fieldYesWhich field is wrong
sourceUrlYesOfficial https manufacturer source confirming the correct value
proposedValueYesThe correct value, per the cited source

TDQS

A4.3/5.0
Behavior4/5

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

Without annotations, the description carries the full burden. It discloses key behavioral traits: submissions are queued for verification, never applied automatically, and must include an official source. This is sufficient for a non-destructive proposal action.

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?

Three sentences, front-loaded with the primary purpose, no redundant information. Every sentence earns its place.

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 submission tool without an output schema, the description covers all necessary context: purpose, required source, queuing behavior, and slug format. It is complete for an agent to decide and invoke correctly.

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 baseline is 3. The description adds value by explaining the slug's source ('Use the router's slug from ssid.ai/routers/<slug>') and emphasizing the requirement for an official source URL. This goes slightly beyond the schema but does not fundamentally change the agent's understanding.

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's purpose: proposing a fix to a router model's default-login fields on ssid.ai. It specifies the exact fields (default gateway IP, username, password, etc.) and distinguishes from the sibling tool 'lookup_mac' which serves a different purpose.

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 guidance: it requires an official manufacturer source URL (excluding aggregators/forums) and instructs users to obtain the slug from the router's page. It also explains that submissions are queued for verification and never applied automatically, which sets expectations. However, it does not explicitly state when not to use this tool or mention alternatives.

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.

  1. 2 tool updatesv1.0.0
    • First observedlookup_mac
    • First observedsubmit_correction

TDQS

A4.2/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have completely distinct purposes: one looks up MAC addresses, the other submits corrections for router defaults. No overlap or ambiguity.

Naming Consistency5/5

Both tools use a consistent verb_noun pattern in snake_case: lookup_mac and submit_correction. The naming is predictable and clear.

Tool Count4/5

With only 2 tools, the set is slightly thin but justified by the narrow scope. It's not excessive or insufficient for a focused server.

Completeness2/5

The domain appears to cover MAC lookup and router default credentials, but there is no tool to retrieve existing router info or query defaults. Users can only submit corrections, leaving a significant gap in read access.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    B
    maintenance
    Enables AI agents to manage TP-Link routers by listing clients, checking status, controlling Wi-Fi, and rebooting via natural language.
    1
    MIT
  • A
    license
    Not graded
    quality
    A
    maintenance
    Provides AI assistants with local Wi-Fi diagnostics including connection history analysis, live signal sampling, and connectivity diagnosis. It returns findings and verdicts rather than raw data, and runs on Windows, Linux, and macOS without sending data off the machine.
    264 npm
    1
    MIT
  • A
    license
    Not graded
    quality
    C
    maintenance
    Enables AI agents to debug local networks in plain language by pinging, sweeping subnets, tracing routes, resolving DNS, scanning ports, inspecting ARP tables and active connections, and checking URL reachability.
    MIT