Manufacturer-cited router default logins and compliance check, plus MAC/OUI vendor lookup. Free.
Scored across 4 tools
Each tool targets a distinct operation: MAC lookup, router defaults retrieval, compliance check, and correction submission. There is no overlap that could cause an agent to misselect, as the descriptions clearly separate the different purposes.
All tool names follow a consistent verb_noun pattern in snake_case: check_, get_, lookup_, submit_. No mixed conventions or vague verbs.
Four tools is well-scoped for a specialized server covering lookup, retrieval, compliance, and correction. The count fits the domain without being thin or bloated.
Core workflows are covered: identify vendor via MAC, get router defaults, check compliance, and propose corrections. A minor gap is the lack of a search/list tool for router models, but brand+model input and slug references mitigate this.
Whether a router model still ships a universal default password, the pattern prohibited for consumer connectable products under the UK PSTI Act and targeted by the EU Cyber Resilience Act, based on the manufacturer-cited credential type, with the ssid.ai Router Compliance Index totals for context. Pass the ssid.ai slug (get it from get_router_defaults). Documentation reading, not legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ssid.ai router slug |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool is read-only ('Documentation reading') and that it provides context via the Router Compliance Index totals. However, it doesn't describe what the output looks like, whether it can fail (e.g., unknown slug), or any rate limits. The 'not legal advice' caveat is useful but doesn't fully compensate for missing behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that front-loads the core purpose and regulatory context. It includes the essential usage instruction (get slug from get_router_defaults) and a caveat. It's slightly long but every clause adds meaning; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup tool with no output schema, the description covers the input source and the regulatory context. However, it doesn't describe the return value shape or possible error conditions (e.g., invalid slug). The sibling get_router_defaults is referenced, which helps, but the agent still lacks a full picture of what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the only parameter (slug) is described as 'ssid.ai router slug'. The description adds the crucial detail that the slug comes from get_router_defaults, which is valuable. However, it doesn't add format details (e.g., URL-safe, case sensitivity) beyond what the schema provides. Baseline 3 is appropriate since the schema already documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: checking whether a router model ships a universal default password, and ties it to specific regulations (UK PSTI, EU CRA). It names the resource (router model via ssid.ai slug) and the specific question being answered. It also distinguishes itself from siblings by referencing get_router_defaults as the source for the slug.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent to pass the ssid.ai slug obtained from get_router_defaults, which is a clear usage instruction. It also notes the tool is documentation reading, not legal advice, which sets expectations. However, it doesn't explicitly state when NOT to use this tool or name alternatives beyond the slug source.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Default gateway IP, admin username and password (or the fact that there is none), credential type and factory-reset steps for a router or gateway model, each cited to the manufacturer's own documentation with the source URL. Pass the ssid.ai slug, or brand plus model. Use after lookup_mac identifies the vendor, or whenever a user asks for a router's default login, factory password, gateway address or reset procedure. Covers the 409-model ssid.ai directory; no listing or wildcard search.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | ssid.ai router slug, e.g. tp-link-archer-ax55 (from ssid.ai/routers/<slug>) | |
| brand | No | Manufacturer, e.g. TP-Link, Netgear, ASUS | |
| model | No | Model as printed on the device, e.g. Archer AX55 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It discloses that results are cited to manufacturer documentation with source URLs, covers only the 409-model directory, and clarifies input requirements (slug or brand+model). It does not mention error handling or read-only nature, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (about 3 sentences) and front-loads the core function, then gives usage context and scope. It is efficiently worded without redundancy, though a bullet list could improve scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description adequately explains what the tool returns and its scope. It covers the 409-model limitation and the citation behavior. It could mention not-found handling or that it is read-only, but for a lookup tool this is sufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining that either slug OR brand+model can be passed, which is not evident from individual parameter descriptions. This clarifies the invocation pattern beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns default gateway IP, admin username/password, credential type, and factory-reset steps for a router model, with citations. It distinguishes from siblings by specifying it is for default login info and not a listing or wildcard search, which sets it apart from potential search or compliance tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: after lookup_mac identifies the vendor, or whenever a user asks for default login, factory password, gateway address, or reset procedure. It also excludes listing/wildcard search, guiding the agent away from misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Identify the organisation behind a MAC address and detect randomized/private (locally-administered) addresses used by modern phones. Resolves the IEEE registries longest-prefix-first, so an address inside a block the IEEE subdivided returns the company that actually holds it (MA-M, MA-S or IAB) rather than the MA-L registrar. Returns vendor, blockType (MA-L | MA-M | MA-S | IAB), block start/end for a sub-block, OUI, kind, randomized flag, confidence and the source registry file. A randomized address keeps vendor: null and adds cidRegistrant when its prefix is a registered Company ID (DA:A1:19 is Google's). For the router's factory login, call get_router_defaults next.
| Name | Required | Description | Default |
|---|---|---|---|
| mac | Yes | A MAC address in any format, e.g. F4:F5:E8:11:22:33 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it delivers richly: it explains longest-prefix-first registry resolution, sub-block handling (MA-M/MA-S/IAB), the exact returned fields, null vendor behavior for randomized addresses, cidRegistrant addition, and the source registry file. It even gives a concrete example, DA:A1:19 as Google's Company ID.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: purpose, resolution algorithm, return fields, randomized-address edge case, and next-step sibling guidance. It is front-loaded with the core purpose and maintains a clear logical structure without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup tool with no output schema and no annotations, the description is remarkably complete: it explains behavior, outputs, edge cases, and related-tool routing. An agent has enough information to invoke the tool correctly and interpret its results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the single mac parameter, including format guidance and an example. The tool description does not add parameter-level semantics beyond what the schema states, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: identify the organization behind a MAC address and detect randomized/private addresses. It also distinguishes itself from sibling tools by covering lookups, not compliance checks, router defaults, or corrections, and even points to get_router_defaults for 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys clear usage context: it is for MAC/OUI vendor identification and randomized-address detection. It explicitly routes the user to get_router_defaults when the need is a router factory login, which serves as an alternative-usage signal, though it does not explicitly contrast with check_router_compliance or submit_correction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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/.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The router's ssid.ai slug, e.g. 'tp-link-archer-ax55' | |
| field | Yes | Which field is wrong | |
| sourceUrl | Yes | Official https manufacturer source confirming the correct value | |
| proposedValue | Yes | The correct value, per the cited source |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure. It states the tool never applies changes automatically and requires an official source, which is critical for a mutation tool. It does not describe potential side effects (e.g., creating a support ticket) but the queuing behavior is well disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no fluff. The core purpose is front-loaded, followed by the key constraint and behavioral note. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a proposal tool with no output schema, the description explains the purpose, constraints, and outcome (queued, not applied). It does not mention what the tool returns (e.g., a confirmation ID), which is a minor gap but acceptable given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema documents all four parameters. The description adds marginal value by echoing the field enum and clarifying that proposedValue must be 'per the cited source' and that sourceUrl must be official. The slug usage hint is useful but not essential. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Propose a fix to a router model's default gateway IP, username, password, credential type, or reset steps on ssid.ai.' It enumerates the exact fields the tool can correct, which distinguishes it from siblings like get_router_defaults (read-only) and check_router_compliance (validation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the key usage constraint: 'Requires an official manufacturer source URL (never an aggregator/forum)' and notes the tool queues for verification rather than applying changes. It also gives a slug format hint. It does not explicitly contrast with sibling tools, but the purpose is clear enough that an agent can infer when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_router_complianceget_router_defaultslookup_macsubmit_correctionmacvendors.com MCP — MAC address (OUI) → hardware manufacturer lookup.
Live DNS, email-auth and redirect checks, HTTP security headers, uptime history, PC hardware prices.
Free anonymous website, DNS, email and TLS checks, plus monitor read and opt-in write access.
Free no-key IP intelligence: geolocation, VPN detection, DNS, WHOIS, blacklists, breach checks
Add one secure layer between your agents and this server.
