Cyberbro 的模型上下文协议 (MCP) 服务器。
本项目打包为标准 Python 发行版，可通过以下方式启动：
uvx mcp-cyberbro
pip install mcp-cyberbro 然后运行 mcp-cyberbro
通过 Cyberbro 引擎分析可观测对象（IP、域名、URL、哈希等）。
在支持 MCP 的助手内直接集成威胁分析操作。
支持 stdio、sse 或 streamable-http 传输方式。
兼容任何支持这些传输方式的 MCP 客户端。
Related MCP server: cortex-mcp
uvx (独立运行)uvx mcp-cyberbro --cyberbro_url http://localhost:5000pippip install mcp-cyberbro
mcp-cyberbro --cyberbro_url http://localhost:5000pip install -e .
mcp-cyberbro --cyberbro_url http://localhost:5000默认容器命令以 streamable-http 模式在 8000 端口启动。
docker run --rm -p 8000:8000 \
-e CYBERBRO_URL=http://host.docker.internal:5000 \
ghcr.io/stanfrbd/mcp-cyberbro:latest强制使用 stdio 传输：
docker run -i --rm \
-e CYBERBRO_URL=http://host.docker.internal:5000 \
ghcr.io/stanfrbd/mcp-cyberbro:latest \
--transport stdio复制 .env.example 并至少设置：
CYBERBRO_URL (必需)
支持的环境变量：
CYBERBRO_URL
API_PREFIX (默认: api)
SSL_VERIFY (true/false)
MCP_TRANSPORT (stdio, sse, streamable-http)
MCP_HOST
MCP_PORT
MCP_MOUNT_PATH
MCP_SSE_PATH
MCP_STREAMABLE_HTTP_PATH
CLI 标志也可用，并会覆盖环境变量的值。
您可以将此服务器与 Claude Desktop、Claude Code、Cursor、兼容 OpenAI 的 MCP 客户端或任何其他 MCP 客户端一起使用。
使用 uvx 的配置示例：
{
"mcpServers": {
"cyberbro": {
"command": "uvx",
"args": ["mcp-cyberbro"],
"env": {
"CYBERBRO_URL": "http://localhost:5000"
}
}
}
}使用 Docker + stdio 的示例：
{
"mcpServers": {
"cyberbro": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-e",
"CYBERBRO_URL",
"ghcr.io/stanfrbd/mcp-cyberbro:latest",
"--transport",
"stdio"
],
"env": {
"CYBERBRO_URL": "http://localhost:5000"
}
}
}
}创建 .vscode/mcp.json
{
"servers": {
"mcp-cyberbro": {
"type": "stdio",
"command": "uvx",
"args": [
"mcp-cyberbro"
],
"env": {
"CYBERBRO_URL": "http://127.0.0.1:5000"
}
}
}
}包含用于 MCP 注册表发布的 server.json，指向 PyPI 包 mcp-cyberbro。
发布创建的工作流：
.github/workflows/publish-test-pypi.yml
.github/workflows/publish-pypi.yml
.github/workflows/publish-mcp-plugin.yml
analyze_observable
is_analysis_complete
get_analysis_results
get_engines
get_web_url
以下是您可以与任何连接到 Cyberbro 的 MCP 助手一起使用的实用提示词示例。
Cyberbro：检查 target.com 的指标。
你能用 Cyberbro 检查这个 IP 的信誉吗？192.168.1.1。使用 github、google 和 virustotal 引擎。
我想分析域名 example.com。Cyberbro 能告诉我关于它的什么信息？最多使用 3 个引擎。
使用 Cyberbro 分析这些可观测对象：suspicious-domain.com, 8.8.8.8, 和 44d88612fea8a8f36de82e1278abb02f。使用所有可用引擎。
我发现了这个 (hash|domain|url|ip|extension)。你能提交给 Cyberbro 进行分析并分析结果吗？
使用 Cyberbro 为域名 example.com 创建一份 OSINT 报告。使用所有可用引擎，并根据结果进行深入挖掘以获取更多信息。最多使用 10 个分析请求。
MIT
Trigger an analysis for a given observable (IP, domain, URL, hash, chrome extension id) using Cyberbro. It can support multiple observables at once separated by spaces. Args: text: Observable(s) to analyze. engines: List of engine names. Returns: The analysis response from Cyberbro API.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| engines | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. It lacks details on error handling, rate limits, response time, or side effects. Simply states it triggers analysis and returns response.
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?
Short and direct, with front-loaded purpose. Uses Args/Returns structure but still efficient. No redundant sentences.
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?
Missing key context: no output schema, no explanation of asynchronous behavior, no details on response format. With siblings like get_analysis_results, description should clarify that this returns initial response, not final 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?
Adds meaning to parameters by explaining 'text' as observable(s) and 'engines' as list of engine names. Notes multiple observables separated by spaces, but does not specify engine source or format constraints beyond 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 it triggers analysis for observables (IP, domain, URL, hash, chrome extension id) using Cyberbro. It distinguishes from siblings like get_analysis_results and get_engines by indicating it initiates 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?
Implies usage for initiating analysis, but no explicit when-to-use or alternatives compared to siblings. Mentions support for multiple observables, offering some guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the results of a previous analysis by analysis_id. Args: analysis_id: Analysis ID to retrieve results for. Returns: The analysis results from Cyberbro API.
| Name | Required | Description | Default |
|---|---|---|---|
| analysis_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full disclosure burden. It describes a read operation ('retrieve') but does not disclose error behavior (e.g., if analysis_id is invalid), idempotency, or any side effects. The description adds minimal value beyond the tool name and schema.
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 short and uses a clear docstring format with Args and Returns sections. Every sentence serves a purpose, but the Returns section is vague ('analysis results from Cyberbro API'). Still, it is front-loaded and efficient.
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 tool with one parameter and no output schema, the description should cover the return format, error cases, and lifecycle expectations. It only states 'the analysis results' generically. Combined with no annotations, the agent lacks context on when results are available or how to interpret them.
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 0%, so the description must compensate. It restates the parameter as 'analysis_id: Analysis ID to retrieve results for', which adds little meaning beyond the schema's 'title'. No constraints, formats, or examples are provided, leaving the parameter under-documented.
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 'Retrieve the results of a previous analysis by analysis_id', specifying the verb, resource, and key parameter. This distinguishes it from siblings like analyze_observable (starts analysis) and is_analysis_complete (checks status), making the purpose unambiguous.
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 after an analysis is started, but does not explicitly state when to use it versus alternatives such as is_analysis_complete or get_web_url. No conditions, prerequisites, or when-not-to-use information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available Cyberbro engines. This is the first tool to be called to get the usable engines. Returns: The list of engines.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states that the tool lists engines, lacking details on side effects, caching, or any constraints. The return info is minimal.
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 short but contains redundancy (the returns line repeats the purpose). It could be more concise by merging the last sentence.
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 zero parameters and no output schema, the description adequately covers the tool's purpose and usage order. It is sufficient for such a simple 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?
Input schema has no parameters (0 params), so description compensation is unnecessary. Baseline for zero parameters is 4, and no additional param info is needed.
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 lists available Cyberbro engines and positions it as the first tool to call. It distinguishes from siblings like analyze_observable, but does not explicitly contrast them.
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 a clear usage hint (call this first), but does not specify when not to use it or offer alternatives. Usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the web GUI URL for a given analysis ID. Args: analysis_id: Analysis ID to get the web URL for. Returns: The web URL from Cyberbro API - Useful for the user to check the results.
| Name | Required | Description | Default |
|---|---|---|---|
| analysis_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It only mentions the return value ('web URL from Cyberbro API') but does not disclose read-only nature, authentication needs, or side effects. Behavioral traits are inadequately addressed.
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 with two sentences and clearly separated args/returns. It is front-loaded with the core purpose. Minor improvement possible by structuring the return statement.
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 simple tool with one parameter and no output schema, the description is mostly adequate but lacks guidance on when to use vs siblings and does not explain if the URL requires authentication. A more complete description would mention usage context.
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?
With 0% schema description coverage, the description adds only a restatement of the parameter purpose ('Analysis ID to get the web URL for'). No format, constraints, or examples are provided, leaving the agent with minimal additional meaning.
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 retrieves a web GUI URL for a given analysis ID, using a specific verb and resource. It distinguishes from siblings like get_analysis_results (raw data) and is_analysis_complete (status check).
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?
No explicit guidance on when to use this tool versus alternatives like get_analysis_results or analyze_observable. The description merely states the function without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if the analysis is complete for the given analysis_id. Args: analysis_id: Analysis ID to check. Returns: The completion status from Cyberbro API.
| Name | Required | Description | Default |
|---|---|---|---|
| analysis_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks behavioral details such as whether the operation is read-only, error handling (e.g., if analysis_id is invalid), or rate limits. It only states that it returns completion status without specifying the format or possible values.
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 extremely concise, with the main purpose stated upfront. However, it could include more details without becoming overly long. The structure is clear but minimal.
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 simple tool with one parameter and no output schema, the description is somewhat complete. It explains the action and return type ('completion status'), but lacks specifics on the possible status values and error scenarios. Given the simplicity, it is adequate but could be improved.
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 has 0% description coverage, and the description only repeats the parameter name and purpose ('analysis_id: Analysis ID to check') without adding any new semantic information beyond what the schema's title already provides. It does not explain constraints, allowed values, or provide examples.
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 ('Check if the analysis is complete') and the resource ('for the given analysis_id'). The tool name itself is specific, and it is distinct from sibling tools like get_analysis_results which retrieve full results.
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 (e.g., get_analysis_results). It does not specify that it should be used for polling or as a prerequisite before retrieving results.
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.0.4get_analysis_resultsget_enginesget_web_urlis_analysis_completev0.0.3analyze_observableScored across 5 tools
Each tool serves a distinct function: triggering analysis, retrieving results, listing engines, getting web URL, and checking completion. No overlapping purposes.
All tool names follow the consistent verb_noun pattern in snake_case (e.g., analyze_observable, get_analysis_results), making them predictable and easy to distinguish.
With 5 tools, the set is well-scoped for the purpose of observable analysis via Cyberbro. Each tool fills a clear role without redundancy.
The workflow from listing engines to triggering analysis, checking completion, and retrieving results is fully covered. A minor gap is the lack of a tool to list past analyses by date or filter, but core operations are complete.
Enrich, search, assess, and manage threat intelligence through 80+ typed MCP tools.
Cybersecurity MCP server for URL scanning, threat intelligence, and domain reputation.
Email safety MCP server. Detects phishing, prompt injection, CEO fraud for AI agents.
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
