用于家庭网络发现和安全扫描的 MCP 服务器。它可以发现本地网络上的设备、识别制造商、标记潜在的安全问题，并导出为 Obsidian 清单格式。
如果您正在管理家庭或小型办公室网络，此 MCP 服务器可以让您：
发现所有设备 - 通过 ARP 表扫描查找连接到您网络的所有设备
识别制造商 - 自动进行 MAC 地址到制造商的查找
标记安全问题 - 识别未知或潜在风险设备（如来自特定地区的物联网设备等）
跟踪变化 - 检测两次扫描之间新增或移除的设备
记录您的网络 - 导出为 Markdown 以供 Obsidian 或其他文档系统使用
Related MCP server: Network Scanner MCP
类别 | 功能 |
发现 | 基于 ARP 的网络扫描，通过 Ping 扫描实现全面发现 |
识别 | MAC 地址制造商查找，设备分类 |
安全 | 标记未知设备，识别潜在的物联网风险 |
变化检测 | 比较扫描结果，跟踪新增/移除的设备 |
导出 | Markdown 和 JSON 格式，Obsidian 兼容清单 |
Node.js 18+
macOS 或 Linux（使用 arp 命令）
对本地子网的网络访问权限
npx mcp-homescan或者全局安装：
npm install -g mcp-homescangit clone https://github.com/aplaceforallmystuff/mcp-homescan.git
cd mcp-homescan
npm install
npm run build添加到您的 Claude Desktop 配置文件中：
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"homescan": {
"command": "npx",
"args": ["-y", "mcp-homescan"],
"env": {
"HOMESCAN_SUBNET": "192.168.1"
}
}
}
}添加到 ~/.claude.json：
{
"mcpServers": {
"homescan": {
"command": "npx",
"args": ["-y", "mcp-homescan"],
"env": {
"HOMESCAN_SUBNET": "192.168.1"
}
}
}
}变量 | 描述 | 默认值 |
| 要扫描的网络子网 (例如 |
|
"Scan my home network for devices"
"What devices are on my network?"
"Refresh the network scan and show all devices"
"What's the device at 192.168.1.34?"
"Look up the manufacturer for MAC address aa:bb:cc:dd:ee:ff"
"Show me any flagged devices on my network"
"Are there any unknown devices I should investigate?"
"Have any new devices appeared since the last scan?"
"Show me what's changed on my network"
"Export my network inventory to markdown"
"Generate a network report"
工具 | 描述 |
| 发现本地网络上的所有设备 |
| 通过 IP 获取特定设备的详细信息 |
| 通过 MAC 地址查找制造商 |
| 生成全面的网络发现报告 |
| 将设备导出为 Markdown 或 JSON 格式 |
| 比较当前扫描与之前的扫描，显示变化 |
| 列出被标记为需要安全审查的设备 |
# Watch mode for development
npm run watch
# Build TypeScript
npm run build
# Run locally
node dist/index.js确保您处于同一网段，并且子网配置正确。尝试使用 refresh: true 运行以先执行 Ping 扫描。
在某些系统上，ARP 表可能需要提升权限。如果需要，请尝试使用 sudo 运行。
某些设备可能不会响应 ARP 查询。请使用 refresh: true 运行 homescan_discover 以先对网络进行 Ping 扫描。
检查您的网络配置并更新 HOMESCAN_SUBNET 以匹配您的本地网络（常见值：192.168.1, 192.168.0, 10.0.0）。
此工具仅扫描您的本地网络
不会向外部发送任何数据
被标记的设备仅供参考 — 请在采取行动前进行核实
请参阅 SECURITY.md 了解漏洞披露信息
请参阅 ROADMAP.md 了解计划的工作和范围评估。
欢迎贡献！请参阅 CONTRIBUTING.md 了解指南。
MIT - 详情请参阅 LICENSE。
Get detailed information about a specific device by IP address
| Name | Required | Description | Default |
|---|---|---|---|
| ip | Yes | IP address of the device to look up |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Get detailed information' implies a read-only operation, it doesn't specify what 'detailed information' includes, whether there are rate limits, authentication requirements, error conditions, or what happens if the IP isn't found. For a lookup tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a simple lookup tool and front-loads the essential information about what the tool does.
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?
Given the lack of annotations and output schema, the description is incomplete for effective tool selection. While the purpose is clear, it doesn't explain what 'detailed information' will be returned, how results are formatted, or what distinguishes this from similar sibling tools. For a tool in a family of related scanning utilities, more context about its specific role would be helpful.
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 schema description coverage is 100% with the single 'ip' parameter well-documented in the schema itself ('IP address of the device to look up'). The description adds no additional parameter semantics beyond what the schema already provides, so it meets the baseline for high schema coverage without adding value.
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 action ('Get detailed information') and target resource ('about a specific device by IP address'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'homescan_mac_lookup' or 'homescan_discover', which likely serve related but distinct purposes in the homescan system.
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 provides no guidance on when to use this tool versus alternatives. With sibling tools like 'homescan_mac_lookup' (presumably for MAC address lookups) and 'homescan_discover' (likely for device discovery), there's no indication of when IP-based lookup is preferred or what prerequisites might be needed for successful operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare current network scan to the last scan and show new/removed devices
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions comparing scans and showing devices, but lacks details on what 'current' and 'last' scans refer to (e.g., stored data, real-time scans), whether this is a read-only operation, potential side effects, or output format. For a tool with zero annotation coverage, this is a significant gap in transparency.
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, efficient sentence that front-loads the core functionality. It uses clear language without redundancy, making it easy to parse quickly. Every word contributes directly to understanding the tool's purpose.
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?
Given the complexity of comparing network scans and the lack of annotations and output schema, the description is incomplete. It doesn't explain how scans are stored or retrieved, what 'new/removed devices' means in practice, or the format of the results. For a tool that likely involves data analysis and comparison, more context is needed to guide effective use.
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 has 0 parameters with 100% coverage, so no parameters need documentation. The description doesn't add parameter details, which is acceptable given the schema's completeness. A baseline of 4 is appropriate as it doesn't need to compensate for any gaps.
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: 'Compare current network scan to the last scan and show new/removed devices.' It specifies the verb 'compare' and the resource 'network scan' with a clear outcome. However, it doesn't explicitly differentiate from sibling tools like 'homescan_report' or 'homescan_flagged', which might also involve scan analysis.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., requiring a previous scan), exclusions, or comparisons to siblings like 'homescan_report' for broader analysis or 'homescan_discover' for initial scanning. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover all devices on the local network using ARP table. Returns IP, MAC address, and manufacturer for each device found.
| Name | Required | Description | Default |
|---|---|---|---|
| refresh | No | If true, performs a ping sweep first to populate ARP cache with all active devices. Takes longer but finds more devices. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the action (discover devices via ARP table) and return data, but does not cover aspects like performance (e.g., speed, network impact), error handling, or prerequisites (e.g., network permissions). It adds basic context but lacks depth for a tool with potential network interactions.
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 and front-loaded, consisting of two sentences that efficiently convey the tool's purpose and return data. Every sentence adds value without redundancy, making it easy to understand quickly.
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?
Given the tool's moderate complexity (network discovery with one parameter) and no annotations or output schema, the description is adequate but incomplete. It covers the core functionality and return data but lacks details on behavioral traits (e.g., network impact, error cases) and does not explain the output format beyond a high-level list, which could be insufficient for an agent to handle results effectively.
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 schema description coverage is 100%, so the schema fully documents the single parameter 'refresh'. The description does not add parameter-specific details beyond what the schema provides, but with only one optional parameter, the baseline is high. It implicitly supports the parameter by mentioning the ARP cache and ping sweep in the context of discovery.
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 with specific verbs ('discover all devices') and resources ('local network using ARP table'), and distinguishes it from siblings by specifying the discovery method and return data (IP, MAC, manufacturer). It goes beyond a tautology of the name 'homescan_discover' by explaining the action and scope.
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 implies usage for network device discovery but does not explicitly state when to use this tool versus alternatives like 'homescan_diff' or 'homescan_flagged'. It provides some context (local network, ARP-based) but lacks explicit guidance on exclusions or comparisons with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export discovered devices to Obsidian inventory format. Returns an array of files that can be saved to your vault.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Export format (default: markdown) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool returns 'an array of files that can be saved to your vault,' which adds useful context about output behavior. However, it lacks details on permissions needed, rate limits, whether it's idempotent, or error handling, leaving gaps in behavioral understanding.
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 two sentences, front-loaded with the core purpose and followed by output details. Every word earns its place with no redundancy or fluff, making it highly efficient and easy to parse quickly.
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?
Given the tool's moderate complexity (export with format options), no annotations, and no output schema, the description does well by stating the purpose and output format. However, it could improve by mentioning dependencies (e.g., requires prior discovery) or example use cases. It's mostly complete but has minor gaps in contextual guidance.
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 description coverage is 100%, so the schema already documents the 'format' parameter with enum values and default. The description doesn't add any parameter-specific details beyond what the schema provides, such as explaining the implications of choosing markdown vs. json formats. Baseline 3 is appropriate as the schema handles parameter documentation adequately.
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 specific action ('Export discovered devices') and target resource ('to Obsidian inventory format'), distinguishing it from siblings like homescan_device (likely device details) or homescan_report (likely summary reports). It explicitly mentions the output format conversion, which is unique among the listed 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?
The description implies usage when you want to export devices to Obsidian format, but it doesn't explicitly state when to use this vs. alternatives like homescan_report or homescan_diff. No guidance on prerequisites (e.g., must run discovery first) or exclusions is provided, leaving usage context somewhat inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List devices flagged for security review (unknown manufacturers, Chinese IoT devices, randomized MACs)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the tool lists flagged devices but does not disclose behavioral traits such as whether this is a read-only operation, requires authentication, has rate limits, or what the output format looks like. It adds some context on the types of flags but lacks critical operational 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, efficient sentence that front-loads the purpose with specific details (e.g., 'unknown manufacturers, Chinese IoT devices, randomized MACs'), with no wasted words or 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?
Given the tool has no parameters, no annotations, and no output schema, the description provides a clear purpose but lacks completeness in behavioral context (e.g., output format, safety profile). It is adequate for a simple list tool but could benefit from additional operational details.
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 has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter semantics, but this is acceptable given the lack of parameters, warranting a baseline score above 3 for not omitting necessary information.
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 verb 'List' and the resource 'devices flagged for security review', with specific criteria (unknown manufacturers, Chinese IoT devices, randomized MACs) that distinguish it from sibling tools like 'homescan_device' or 'homescan_discover'.
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 implies usage by specifying the types of flagged devices, but it does not explicitly state when to use this tool versus alternatives like 'homescan_report' or 'homescan_export', nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up the manufacturer of a device from its MAC address
| Name | Required | Description | Default |
|---|---|---|---|
| mac | Yes | MAC address to look up (format: xx:xx:xx:xx:xx:xx) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool performs a lookup, implying a read-only operation, but does not disclose any behavioral traits such as rate limits, authentication needs, error handling, or what happens if the MAC address is invalid. This leaves significant gaps in understanding the tool's behavior.
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, clear sentence that efficiently conveys the tool's purpose without any wasted words. It is appropriately sized and front-loaded, making it easy for an agent to parse quickly.
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?
Given the tool's low complexity (one parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on usage, behavioral context, and output, which are needed for a more complete understanding. The schema handles parameter documentation, but overall completeness is limited.
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 has 100% description coverage, with the 'mac' parameter fully documented in the schema. The description adds no additional meaning beyond what the schema provides (e.g., it does not explain the lookup process or output format). Since the schema does the heavy lifting, 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 clearly states the tool's purpose with a specific verb ('look up') and resource ('manufacturer of a device'), and it specifies the input ('from its MAC address'). However, it does not explicitly differentiate this tool from its siblings (e.g., homescan_device, homescan_discover), which might also involve device-related operations, so it falls short of a perfect score.
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 provides no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions, nor does it reference sibling tools for comparison. This lack of usage instructions leaves the agent without direction on appropriate scenarios for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a comprehensive network discovery report in markdown format, including device summary, categories, and security flags
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool generates a report but doesn't describe what triggers the generation, whether it's read-only or has side effects, performance characteristics, or error handling. This leaves significant gaps in understanding how the tool behaves beyond its basic function.
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, efficient sentence that front-loads the key action ('Generate a comprehensive network discovery report') and specifies format and content without unnecessary details. It could be slightly improved by structuring it into bullet points for the content elements, but it's already very concise.
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?
Given the tool has no parameters and no output schema, the description adequately covers the basic purpose and output format. However, it lacks details on behavioral aspects (e.g., whether it's a read operation, if it triggers network scans, or how it interacts with sibling tools), which are important for a tool in a network discovery context with multiple related tools.
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 has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's output and purpose. This meets the baseline for a tool with no parameters.
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 with a specific verb ('Generate') and resource ('network discovery report'), specifying the output format ('markdown') and content scope ('device summary, categories, and security flags'). However, it doesn't explicitly differentiate this report generation from sibling tools like homescan_export or homescan_flagged, which may also involve reporting functions.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, timing, or compare it to siblings like homescan_export (which might export data) or homescan_flagged (which might focus on security flags), leaving the agent without context for tool selection.
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.
homescan_devicehomescan_diffhomescan_discoverhomescan_exporthomescan_flaggedhomescan_mac_lookuphomescan_reportScored across 7 tools
Each tool has a clearly distinct purpose with no overlap: device lookup, diff comparison, network discovery, export, flagged device listing, MAC lookup, and report generation. The descriptions make it easy for an agent to select the right tool for each specific task without confusion.
All tools follow a consistent 'homescan_' prefix with descriptive suffixes (e.g., device, diff, discover), using snake_case uniformly. This predictable pattern enhances readability and makes the tool set easy to navigate.
With 7 tools, the server is well-scoped for network scanning and security analysis. Each tool serves a unique function in the discovery, analysis, and reporting workflow, with no redundancy or missing elements for its domain.
The tool set provides complete coverage for network scanning tasks: discovery (homescan_discover), detailed inspection (homescan_device, homescan_mac_lookup), comparison (homescan_diff), security analysis (homescan_flagged), and output (homescan_export, homescan_report). No obvious gaps exist for the server's purpose.
Security scanner for n8n workflows + live MCP Trust-Check. 18 rules, OWASP mapped. Paid x402 API.
Compliance & security scan for your app: secrets, exposed files, headers, privacy, AI-disclosure.
Markdown-based note-taking with a hosted MCP server. Your notes serve you and your AI.
EOL dates, risk scores, CISA KEV exposure, SBOM audits and edge-device EOS for 500+ products.
