# Understanding the bootstrap-manifest.json Schema in reverse-skill: A Complete Guide to Adding New Tools

> Learn the bootstrap-manifest.json schema in reverse-skill to define and add new tools. This guide explains how to obtain, verify, and expose tool capabilities as MCP services.

- Repository: [ZhaoXu/reverse-skill](https://github.com/zhaoxuya520/reverse-skill)
- Tags: how-to-guide
- Published: 2026-08-05

---

**The [`bootstrap-manifest.json`](https://github.com/zhaoxuya520/reverse-skill/blob/main/bootstrap-manifest.json) schema in reverse-skill is a JSON configuration that defines every installable tool, specifying how to obtain, verify, and expose each capability as an MCP service.**

The [`bootstrap-manifest.json`](https://github.com/zhaoxuya520/reverse-skill/blob/main/bootstrap-manifest.json) file serves as the single source of truth for the **reverse-skill** project's on-demand tool provisioning system. Located in [`skills/scripts/bootstrap-manifest.json`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/scripts/bootstrap-manifest.json), this JSON file describes how the bootstrap scripts download, install, and verify reverse engineering tools without requiring any code changes. The schema is intentionally permissive—each capability entry contains only the fields required for its specific installation method.

## Core Schema Structure

The root of [`bootstrap-manifest.json`](https://github.com/zhaoxuya520/reverse-skill/blob/main/bootstrap-manifest.json) contains a single `capabilities` array. Each object in this array represents one tool with a unique `name` and a `bootstrapKind` that determines which additional fields are required.

### Universal Fields

Every capability entry must include these base fields:

- **`name`** — Unique identifier used throughout the router (e.g., `"jadx"`, `"frida"`)
- **`bootstrapKind`** — Installation method that dictates required extra fields
- **`docsUrl`** — Link to upstream documentation
- **`canAutoInstall`** — Boolean indicating unattended installation support

### bootstrapKind Values and Required Fields

The `bootstrapKind` field is the primary discriminator. According to the reverse-skill source code, supported kinds include:

| `bootstrapKind` | Required Additional Fields |
|-----------------|---------------------------|
| `github-release-zip` | `repo`, `assetRegex`, `installDir`, optionally `releaseTag`, `assetSha256`, `preferApiDigest` |
| `github-release-jar-wrapper` | `repo`, `assetRegex`, `installDir`, `verifyCommand` |
| `pip-package` | `pipPackage`, `verifyCommand` |
| `npm-mcp` | `npmPackage`, `mcpNames`, `mcpUrl` |
| `winget-package` | `wingetId`, `installDir`, `verifyCommand` |
| `git-clone` | `repo`, `installDir`, `postInstallSteps` |
| `local-http-mcp` | `mcpUrl`, `servicePort`, `startupDirCandidates`, `startCommand`, `startArgs`, `verificationMode` |
| `manual` | `manualInstallHint`, `note` |

Reference the complete list in [[`skills/scripts/bootstrap-manifest.json`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/scripts/bootstrap-manifest.json)](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/scripts/bootstrap-manifest.json) lines 1–400 for real-world examples.

## MCP Service Configuration

Tools that expose an MCP (Micro-Control-Program) service require additional fields to define how the router connects to them:

- **`mcpNames`** — Array of capability names this service registers (e.g., `["jshook"]`)
- **`mcpUrl`** — HTTP endpoint for MCP communication (e.g., `"http://localhost:23816/mcp"`)
- **`mcpCommand`** / **`mcpArgs`** — Alternative command-based MCP execution
- **`mcpEnv`** — Environment variables passed to the MCP process
- **`verificationMode`** — How `bootstrap-reverse.ps1` validates the service: `"service-or-registration"`, `"service-and-registration"`, etc.

The `anything-analyzer` entry (lines 110–127) demonstrates this pattern for `local-http-mcp` services.

## How to Add a New Tool to bootstrap-manifest.json

Adding a capability requires no code changes—only a valid JSON entry in the manifest. Follow this six-step process:

1. **Determine the `bootstrapKind`** based on how the tool is distributed
2. **Construct the JSON object** with all required fields for that kind
3. **Append to the `capabilities` array** in [`skills/scripts/bootstrap-manifest.json`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/scripts/bootstrap-manifest.json)
4. **Add Linux support** (optional) by mirroring the entry in [`kali/scripts/bootstrap-manifest.json`](https://github.com/zhaoxuya520/reverse-skill/blob/main/kali/scripts/bootstrap-manifest.json) with apt/pip equivalents
5. **Regenerate the tool index** using [`skills/scripts/refresh-tool-index.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/scripts/refresh-tool-index.sh) or `.ps1`
6. **Test the installation** with `bootstrap-reverse.ps1 -Capability <name>`

### Example: Adding a Winget Package

```json
{
  "name": "httpx",
  "bootstrapKind": "winget-package",
  "wingetId": "ProjectDiscovery.httpx",
  "installDir": "%LOCALAPPDATA%\\httpx",
  "docsUrl": "https://github.com/projectdiscovery/httpx",
  "canAutoInstall": true,
  "verifyCommand": "httpx"
}

```

Insert this object at the end of the `capabilities` array, then validate:

```powershell

# Update tool-index.md from the manifest

.\skills\scripts\refresh-tool-index.ps1

# Test the new entry

.\skills\scripts\bootstrap-reverse.ps1 -Capability httpx

```

### Example: GitHub Release ZIP with Integrity Verification

```json
{
  "name": "bkcrack",
  "bootstrapKind": "github-release-zip",
  "repo": "kimci86/bkcrack",
  "assetRegex": "^bkcrack-1\\.8\\.1-win64\\.zip$",
  "installDir": "%USERPROFILE%\\Tools\\bkcrack",
  "docsUrl": "https://github.com/kimci86/bkcrack",
  "canAutoInstall": true,
  "verifyCommand": "bkcrack",
  "releaseTag": "v1.8.1",
  "preferApiDigest": true
}

```

This entry pins to version 1.8.1 using `releaseTag` and prefers GitHub API digest verification over manual SHA-256 hashes.

## Advanced: MCP-Exposed Service Configuration

For tools that run as persistent HTTP services, define lifecycle management:

```json
{
  "name": "my-local-service",
  "bootstrapKind": "local-http-mcp",
  "repoUrl": "https://github.com/example/my-local-service",
  "installDir": "%USERPROFILE%\\Tools\\my-local-service",
  "startupDirCandidates": ["%USERPROFILE%\\Tools\\my-local-service"],
  "startCommand": "npm",
  "startArgs": ["run", "start"],
  "mcpNames": ["my-service", "local-mcp"],
  "mcpUrl": "http://localhost:3000/mcp",
  "servicePort": 3000,
  "docsUrl": "https://github.com/example/my-local-service",
  "canAutoInstall": true,
  "verificationMode": "service-or-registration"
}

```

The `verificationMode: "service-or-registration"` tells `bootstrap-reverse.ps1` to succeed if either the HTTP service responds or the capability registers via MCP handshake.

## Tool Index Generation and Routing

The [`bootstrap-manifest.json`](https://github.com/zhaoxuya520/reverse-skill/blob/main/bootstrap-manifest.json) is not consumed directly by the runtime router. Instead, the [`refresh-tool-index.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/refresh-tool-index.sh) script (line 111 in [`docs/ARCHITECTURE.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/docs/ARCHITECTURE.md)) parses all manifest entries and generates [`tool-index.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/tool-index.md)—a flattened, searchable index that the routing layer consults to resolve capability requests.

Regenerate this index after any manifest change:

```bash

# Linux/macOS via WSL or native shell

bash skills/scripts/refresh-tool-index.sh

# Windows PowerShell

.\skills\scripts\refresh-tool-index.ps1

```

## File Reference Map

| File | Purpose |
|------|---------|
| [`skills/scripts/bootstrap-manifest.json`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/scripts/bootstrap-manifest.json) | Primary schema source and capability registry |
| [`kali/scripts/bootstrap-manifest.json`](https://github.com/zhaoxuya520/reverse-skill/blob/main/kali/scripts/bootstrap-manifest.json) | Linux-specific installation methods |
| `skills/scripts/bootstrap-reverse.ps1` | PowerShell bootstrap engine that consumes the manifest |
| [`skills/scripts/refresh-tool-index.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/scripts/refresh-tool-index.sh) | Bash script generating [`tool-index.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/tool-index.md) |
| [`docs/ARCHITECTURE.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/docs/ARCHITECTURE.md) | Visual bootstrap flow documentation |
| [`skills/CONTRIBUTING.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/CONTRIBUTING.md) | Contributor guide section 4.1 for registering capabilities |

## Summary

- **[`bootstrap-manifest.json`](https://github.com/zhaoxuya520/reverse-skill/blob/main/bootstrap-manifest.json)** is the declarative configuration driving all tool installations in reverse-skill
- **Eight `bootstrapKind` values** cover common distribution methods from GitHub releases to Winget packages
- **Data-only additions** require no code changes—append valid JSON and regenerate the index
- **MCP service fields** (`mcpUrl`, `verificationMode`, etc.) expose tools as discoverable microservices
- **[`refresh-tool-index.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/refresh-tool-index.sh)** bridges the manifest to the runtime routing layer via [`tool-index.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/tool-index.md)
- **Cross-platform support** mirrors entries between `skills/` (Windows) and `kali/` (Linux) manifests

## Frequently Asked Questions

### What happens if my bootstrapKind requires fields I don't provide?

The installation fails at runtime. `bootstrap-reverse.ps1` performs minimal validation—missing required fields typically cause the specific installation routine to error out. Check existing entries in [`bootstrap-manifest.json`](https://github.com/zhaoxuya520/reverse-skill/blob/main/bootstrap-manifest.json) for your `bootstrapKind` to identify mandatory fields.

### Can I pin a specific version without using releaseTag?

Yes. For `github-release-*` kinds, use `assetRegex` with a literal version string like `"^jadx-1\\.5\\.6\\.zip$"` instead of a permissive pattern. For package managers, specify exact versions in `pipPackage` (`"frida-tools==12.0.0"`) or `npmPackage` (`"@scope/pkg@1.2.3"`).

### How does verificationMode affect installation success?

`verificationMode` controls what constitutes a successful bootstrap. `"service-or-registration"` succeeds if either the HTTP service responds or MCP registration occurs. `"service-and-registration"` requires both. This accommodates tools with asynchronous startup behavior.