一个全面的模型上下文协议 (MCP) 服务器，为安全专业人员提供事件响应和网络分析工具。该服务器允许像 Claude 这样的 AI 代理执行各种与网络相关的查找和分析，以协助安全调查。
IR Toolshed MCP 服务器提供了一套可通过模型上下文协议访问的网络和安全工具。它旨在成为网络事件响应人员的通用服务，使他们能够使用以下工具执行基本查找：
ASN（自治系统编号）查找
DNS 查找和分析
WHOIS 记录检索
IP地理定位
以及更多网络分析功能即将推出
每个工具都附有详细的文档作为资源，使人工智能系统能够轻松了解如何使用这些工具以及预期的输出。
Related MCP server: Wireshark MCP
ASN 查找工具返回有关 IP 地址的信息，包括：
被查询的IP地址
与 IP 地址关联的 AS 编号
拥有 AS 编号的组织的名称
DNS 查找工具提供域的 DNS 记录信息：
支持多种记录类型（A、AAAA、MX、NS、TXT）
返回格式化的 DNS 记录
处理 IPv4 和 IPv6 查询
WHOIS 查询工具检索域名注册信息：
域名所有权详情
注册日期
名称服务器信息
注册商详细信息
IP 地理定位工具使用 MaxMind 的 GeoLite2 数据库提供位置信息：
国家和城市级别的位置数据
纬度和经度坐标
网络信息
时区数据
注意：地理定位工具需要 MaxMind 许可证密钥。您可以：
从以下网址获取免费密钥： https://dev.maxmind.com/geoip/geolite2-free-geolocation-data
任何一个：
设置 MAXMIND_LICENSE_KEY 环境变量
使用工具时将其作为参数提供
出现提示时输入
未来版本中将会添加更多工具。
Python 3.8 或更新版本（推荐 3.13+）
uv Python 包管理器
克隆此存储库：
git clone <repository-url>
cd ir-toolshed-mcp-server创建虚拟环境：
uv venv激活虚拟环境：
.venv\Scripts\activatesource .venv/bin/activate以开发模式安装包：
uv pip install -e .使用以下命令启动 MCP 服务器：
uv run mcp dev src/mcp_server.py这将以开发模式启动服务器，使其可供 Claude Desktop 等 MCP 客户端使用。
当连接到 MCP 客户端（例如 Claude Desktop）时，您可以通过提供 IP 地址来使用 ASN 查找工具：
asnlookup("8.8.8.8")示例输出：
{
"ip_addr": "8.8.8.8",
"as_number": "15169",
"as_name": "GOOGLE - Google LLC"
}当连接到 MCP 客户端（例如 Claude Desktop）时，您可以通过提供域名来使用 DNS 查找工具：
dnslookup("example.com")示例输出：
{
"domain": "example.com",
"record_type": "A",
"record_value": "93.184.216.34"
}当连接到 MCP 客户端（例如 Claude Desktop）时，您可以通过提供域名来使用 WHOIS 查询工具：
whoislookup("example.com")示例输出：
{
"domain": "example.com",
"ownership_details": "Google LLC",
"registration_date": "2004-04-26",
"nameserver_information": "ns1.google.com",
"registrar_details": "MarkMonitor Inc."
}当连接到 MCP 客户端（例如 Claude Desktop）时，您可以通过提供 IP 地址来使用地理定位工具：
geolocation("8.8.8.8")示例输出：
{
"ip_addr": "8.8.8.8",
"country": "US",
"city": "Mountain View",
"latitude": 37.40599,
"longitude": -122.078514,
"network": "AS15169 Google LLC",
"timezone": "America/Los_Angeles"
}每个工具都遵循一致的错误处理模式：
常规错误响应格式：
{
"status": "error",
"error": "Detailed error message",
"query": "Original query value"
}特定工具的错误示例：
ASN 查找：
{
"ip_addr": "<queried-ip>",
"status": "error",
"error": "Invalid IP address format"
}DNS查找：
{
"domain": "<queried-domain>",
"record_type": "<requested-type>",
"status": "error",
"error": "DNS resolution failed"
}WHOIS查询：
{
"domain": "<queried-domain>",
"status": "error",
"error": "WHOIS server not available"
}地理位置：
{
"ip_addr": "<queried-ip>",
"status": "error",
"error": "MaxMind database not found or license key invalid"
}该项目遵循标准 Python 包结构：
irtoolshed_mcp_server/ # Main package directory
├── __init__.py # Package initialization
├── asnlookup.py # ASN lookup functionality
├── dnslookup.py # DNS lookup functionality
├── geolookup.py # Geolocation functionality
├── mcp_server.py # Main MCP server implementation
└── whoislookup.py # WHOIS lookup functionality
tests/ # Test directory
├── test_asnlookup.py # ASN lookup tests
├── test_dnslookup.py # DNS lookup tests
├── test_geolookup.py # Geolocation tests
└── test_whoislookup.py # WHOIS lookup tests克隆此存储库：
git clone <repository-url>
cd ir-toolshed-mcp-server创建虚拟环境并安装依赖项：
uv venv
source .venv/bin/activate # On Windows use: .venv\Scripts\activate
uv pip install -e ".[dev]"运行测试套件：
uv run pytest这将：
运行tests/目录中的所有测试
显示测试覆盖率信息
显示任何故障的详细输出
注意：某些测试需要额外的配置：
地理定位测试需要 MaxMind GeoLite2 数据库和许可证密钥
如果 WHOIS 服务不可用，WHOIS 测试可能会失败
该项目使用多种工具来维护代码质量：
用黑色格式化代码：
uv run black .使用 isort 对导入进行排序：
uv run isort .使用 mypy 运行类型检查：
uv run mypy .使用 ruff 进行 linting：
uv run ruff .已完成：✓ ASN 查询✓ DNS 记录查询（A、AAAA、MX 等）✓ WHOIS 记录检索✓ IP 地理定位服务
计划纳入的未来工具：
域名信誉评分
SSL证书分析
网络端口扫描
威胁情报集成
被动 DNS 历史记录
电子邮件安全分析（SPF、DKIM、DMARC）
BGP路由分析
网络流量可视化
恶意软件哈希查找
URL 信誉检查
欢迎贡献代码来添加新的 IR 工具或改进现有的 IR 工具。请遵循以下步骤：
分叉存储库
创建功能分支
按照 mcp_server.py 中的现有模式添加您的工具
包括适当的文档作为资源
提交拉取请求，并清晰描述你的更改
Apache 2.0
此服务器仅用于合法的安全研究和事件响应。用户在使用这些工具时必须确保遵守所有适用的法律法规。
| Name | Required | Description | Default |
|---|---|---|---|
| ipaddr | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | ||
| record_type | No | A |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| ipaddr | Yes | ||
| license_key | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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.
v0.1.0asnlookupdnslookupgeolookupwhoislookupScored across 4 tools
Each tool has a clearly distinct purpose: asnlookup for Autonomous System Number queries, dnslookup for DNS resolution, geolookup for geographic IP location, and whoislookup for domain registration details. There is no overlap or ambiguity between these tools, making it easy for an agent to select the correct one based on the specific information needed.
All tool names follow a consistent pattern of noun+lookup (e.g., asnlookup, dnslookup, geolookup, whoislookup), using lowercase and no separators. This predictable naming scheme enhances readability and makes the tool set easy to navigate without any deviations or mixed conventions.
With 4 tools, this server is well-scoped for its purpose in IR (Incident Response) or network investigation. Each tool earns its place by covering a distinct aspect of network intelligence (ASN, DNS, geolocation, WHOIS), providing a focused and efficient set without being too thin or overloaded.
The tool set covers core network investigation functions comprehensively, with no obvious gaps for basic lookups. However, minor gaps might exist for advanced IR workflows, such as IP reputation checks or threat intelligence queries, but agents can likely work around this with the provided tools for most common tasks.
Cybersecurity MCP server for URL scanning, threat intelligence, and domain reputation.
The Google GKE MCP server is a managed Model Context Protocol server that provides AI applications with tools to manage Google Kubernetes Engine (GKE) clusters and Kubernetes resources. It exposes a structured, discoverable interface that allows AI agents to interact with GKE and Kubernetes APIs, enabling them to inspect cluster configurations, retrieve Kubernetes resource YAMLs, monitor operations like cluster upgrades, diagnose issues, and optimize costs—all without needing to parse text output or use complex kubectl commands.
The Telnyx MCP server is an official implementation of the Model Context Protocol that enables AI clients (like Claude Desktop, Cursor, and OpenAI Agents) to interact with Telnyx's telephony, messaging, and AI assistant APIs. It provides comprehensive capabilities including making and managing phone calls, sending SMS/MMS messages, purchasing and configuring phone numbers, creating AI assistants with custom instructions, managing cloud storage buckets, scraping and embedding website content, and handling integration secrets. The server exists as both a local implementation and a remotely hosted version, allowing developers to integrate real-world communication infrastructure directly into AI applications.
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
