Wiring VS Code to the MCP

With the Kali container running and the MCP server bound to 127.0.0.1:5000, the next step is to point VS Code at it. Three pieces of configuration — .vscode/mcp.json, the Copilot agent-mode toggle, and a small loopback prompt — get you from a running container to a working agent session.

Prerequisites

• VS Code, current stable release.
• The GitHub Copilot and GitHub Copilot Chat extensions, signed in with an account that has Copilot access.
• The Kali MCP lab from Section 04 or 05, running and serving on localhost:5000.
• A folder open in VS Code that will hold the engagement files (authorisation, notes, report). The MCP config sits inside that folder.

Step 1 — Create .vscode/mcp.json

In your engagement folder, create a .vscode subfolder and a mcp.json inside it. VS Code discovers MCP servers from this file at workspace scope; keeping the config in the engagement folder means each audit can have its own list of available tools.

{
  "servers": {
    "kali-mcp": {
      "type": "http",
      "url": "http://localhost:5000",
      "description": "Kali toolset via mcp-kali-server (Docker, localhost-bound)"
    }
  }
}

Step 2 — Enable agent mode in Copilot Chat

Open the Copilot Chat side panel (the chat-bubble icon in the activity bar). At the bottom of the chat, there is a mode selector — switch it from Ask to Agent. Agent mode is what enables tool-call proposals; without it, Copilot will happily talk about Nmap but cannot run it.

When agent mode loads, VS Code reads .vscode/mcp.json and the MCP server appears as an attached toolset. You can see the list of available tools in the chat's Tools picker — Nmap, Hydra, cURL, OpenSSL, and so on, each exposed as an MCP tool the assistant can propose.

Step 3 — Verify the approval boundary

Before pointing the assistant at any real target, prove to yourself that the approval gate works. Send this prompt in agent mode:

Run a TCP scan of localhost on ports 1-1024 using nmap, default scripts off.

The assistant should propose a tool call that looks roughly like this:

Three things to check before clicking Approve:

• The target argument is what you expect. If the assistant has substituted a different address, deny and ask why.
• The flags are not doing anything you did not ask for — no -A (aggressive), no scripts enabled, no UDP.
• The target is in scope. For this loopback test, the answer is yes; for a real engagement, the answer is "the authorisation file says so".

What "the approval boundary intact" actually looks like

Through the rest of the guide, you will see the phrase "the approval boundary intact" used about the workflow. Concretely, that means four things hold:

1. No tool call leaves the assistant's process without an approve click.
2. The target argument of every proposed call is visible to you before approval.
3. The flags of every proposed call are visible to you before approval.
4. You have time, between the proposal and the approval, to read both against the authorisation file.

If any of those four things is not true — most often because someone enabled auto-approve "just to speed things up" — the workflow has lost its primary safety property, and you are operating outside the boundary the rest of this guide assumes.

Configuration variants

Pointing at a remote lab

If the Kali container is running on a separate workstation on your own network — for example, a homelab box — change the URL to that host's address.

{
  "servers": {
    "kali-mcp": {
      "type": "http",
      "url": "http://10.0.0.42:5000",
      "description": "Kali MCP on homelab box"
    }
  }
}

If you do this, the MCP server is no longer loopback-bound and the first trust boundary has changed shape. You need to be confident that the network path between your laptop and the lab is one you control end-to-end. For most readers, the loopback configuration on a single workstation is the right starting point.

Multiple MCP servers

Agent mode can attach more than one MCP server at a time. If you have, for example, a separate MCP server exposing your ticketing system or your asset inventory, add it as another entry in the same mcp.json:

{
  "servers": {
    "kali-mcp": {
      "type": "http",
      "url": "http://localhost:5000"
    },
    "assets-mcp": {
      "type": "http",
      "url": "http://localhost:5100",
      "description": "Read-only asset inventory"
    }
  }
}

Troubleshooting