The useful part is the front of the workflow: an alert email or a chat message pasted in whole, with several observables of different kinds mixed through it, becomes one analysis run across the engines you picked. Analysis is asynchronous, so the shape is analyse, poll, read — and the web URL turns the finished result into a link for whoever needs the full picture inside Cyberbro.
A client for a Cyberbro instance. Hand it text containing IPs, domains, URLs, hashes or Chrome extension IDs — several at once — choose which engines to run, then poll for the results or open them in Cyberbro's own web view.
- Observables analysed through Cyberbro — IPs, domains, URLs, hashes and Chrome extension IDs — several in a single call
- The engines your instance actually has, listed before you choose which to run
- An analysis checked for completion by its ID, and the full results retrieved once it is done
- The web GUI URL for an analysis, for handing a finding to someone who is not in the conversation
A running Cyberbro instance, with CYBERBRO_URL pointing at it — http://localhost:5000, for example. Install with uvx mcp-cyberbro or pip install mcp-cyberbro, and pass the URL as --cyberbro_url or through the environment. API_PREFIX defaults to api and SSL_VERIFY toggles certificate checking. The transport is selectable — stdio, sse or streamable-http — with MCP_HOST, MCP_PORT and path variables for the HTTP forms; the published ghcr.io/stanfrbd/mcp-cyberbro image starts in streamable-http on port 8000, and running it as stdio takes a two-line Dockerfile of your own. Nothing to authorize for the server itself.
One command — uvx mcp-cyberbro