Build your hackbot, part 3: MCP tools and the CLI

Part two built an agent with two tools of your own. This post connects it to shared tools over the Model Context Protocol, adds an automatic scope check, and runs the result from the terminal or your editor. If MCP is new to you, read what is MCP first, and what are AI agents and tool use for the wider idea.

#From your own tools to shared tools

The two tools you wrote work, and they stop being enough the moment you want CVE lookups, a knowledge base, or web reads without coding each one. MCP is a standard way for an agent to use tools that someone else wrote and runs, so your loop can call them without new code. The Model Context Protocol defines the format, and many clients and servers already speak it.

#What NotHoly exposes over MCP

The NotHoly CLI ships a local MCP server. It runs over standard input and output and uses your CLI login, so no key goes into any config file.

Start the server and register it with a client. For the NotHoly CLI's own agent, the research tools are already present, so this matters most when you wire NotHoly's tools into another agent.

claude mcp add notholy -- notholy mcp

Any MCP client reads the same JSON shape.

{"mcpServers": {"notholy": {"command": "notholy", "args": ["mcp"]}}}

The tools work with any model, so an agent running a model from the catalog, or any other, can still reach NotHoly's CVE and knowledge-base data. The model decides when to call them, and the results come back as data for the loop to read.

#A scope check with notholy engage

Your Python agent trusts you to read each command for scope. The CLI can check it for you. notholy engage records what the program lets you touch and reads the target out of each command before it runs.

notholy engage init --name acme-web --scope "*.example.com,api.example.com" --exclude vpn.example.com
notholy connect claude

With an engagement active, an in-scope command goes through normal approval, and an out-of-scope target makes you type the host and logs the override. notholy connect claude installs the same check as a hook on shell commands, where an out-of-scope command is denied outright. The check reads command text and does not resolve names, so it catches mistakes and is no sandbox. It is the automatic version of the approval habit from part two.

#Run it from the CLI and the editor

You now have three ways to run an agent, and they share one account. Your own Python loop is the one you fully understand and can change. The NotHoly CLI runs a ready-made agent in the terminal with these guardrails built in. And notholy connect or notholy run points an editor agent at NotHoly models and tools, so the same loop runs where you read code.

notholy run claude

notholy run sets the environment for one process without touching your global config. notholy connect writes the config and can undo it. Either way, the model runs on NotHoly, the commands run on your machine, and the research tools come over MCP.

#When to use which

Use your own agent to learn and to control exactly what runs. Use the CLI agent when you want the guardrails without maintaining them. Use the editor integration when the work is reading and changing code. All three keep the same split from part one: the model plans, your machine acts, and every command is yours to approve.

#Next in this track

The agent finds and verifies; you still have to get paid for it. Writing bug bounty reports with AI turns your notes into a report a triager accepts.