Router default logins, compliance index, MAC/OUI lookup. Reads free; submit_correction is Pro.
Scored across 4 tools
Each tool targets a distinct operation: compliance check, default credential retrieval, MAC lookup, and correction submission. However, check_router_compliance and get_router_defaults both deal with router default passwords and require the same slug, creating minor potential for confusion, though descriptions clearly differentiate their outputs.
All tool names use consistent snake_case with a clear verb_noun pattern: check_router_compliance, get_router_defaults, lookup_mac, submit_correction. This is highly predictable and easy to parse.
Four tools is well-scoped for a focused server covering router defaults, compliance, MAC lookup, and corrections. Each tool earns its place, and there is no redundancy or bloat.
The set covers reading defaults, checking compliance, looking up MACs, and submitting corrections. However, there is no listing or wildcard search for routers, which could create a discovery dead end when only a brand is known, though the server accepts brand+model combinations.
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/. Requires an ssid Pro key ($15/mo, ssid.ai/pricing) sent as SSID_API_KEY or a Bearer token; the three read tools stay free.
| 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 the full burden and delivers: it discloses the operation is queued for verification and "never applied automatically," plus authentication requirements (SSID_API_KEY or Bearer token, $15/mo Pro key). These are the exact non-obvious behaviors an agent needs before invoking a mutation-style tool.
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?
Purpose and constraints are front-loaded and every sentence is functional, but the trailing pricing/auth sentence is dense and packs plan cost, env-var name, Bearer option, and a free-tier note into one clause. Slightly crowded, though nothing is truly wasted.
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?
No output schema exists, and the description covers the important outcome (queued for verification, not applied). It does not describe what happens after submission (confirmation, review timeline, or error cases for invalid sources), which is a minor gap for a 4-parameter submission tool.
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 baseline is 3, but the description adds real meaning beyond the schema: it constrains sourceUrl to official manufacturer sources (not aggregators/forums) and specifies the slug format via ssid.ai/routers/<slug>. Enum values for field are left to the schema, which already documents them.
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?
States a specific verb ("Propose a fix") and an enumerated resource (default gateway IP, username, password, credential type, reset steps) scoped to ssid.ai router models. An agent can immediately distinguish this submission tool from the read-oriented siblings (get_router_defaults, check_router_compliance, lookup_mac).
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 the conditions and constraints: an official manufacturer source URL is required ("never an aggregator/forum"), the slug must come from ssid.ai/routers/<slug>, and a paid Pro key is needed while "the three read tools stay free." This routes the agent to the right tool and sets prerequisites without inference.
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_correctionFind the organization behind a MAC address or OUI prefix in the IEEE registries. No auth, no key.
Free no-key IP intelligence: geolocation, VPN detection, DNS, WHOIS, blacklists, breach checks
Free anonymous website, DNS, email and TLS checks, plus monitor read and opt-in write access.
Free IPv4 lookups against a distributed attacker-observation corpus.
Add one secure layer between your agents and this server.
