Skip to main content
Glama
zebbern

hacktricks-mcp

by zebbern
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

hacktricks-mcp

MCP server that gives AI agents fast, offline full-text search and section-level retrieval over the HackTricks offensive-security wiki.

Unlike grep-based alternatives, this server ships with a pre-built SQLite FTS5 search index (1,000+ pages) inside the package. No install-time clone, no ripgrep dependency, no network access at query time. A GitHub Action re-syncs the index with upstream every 3 days and commits it back to this repo.

Quick start

Requirements: Node.js 22.13 or newer (uses the built-in node:sqlite, zero native dependencies).

Claude Code:

claude mcp add hacktricks -- npx -y @zebbern/hacktricks-mcp

Codex CLI:

codex mcp add hacktricks -- npx -y @zebbern/hacktricks-mcp

Any MCP client (Claude Desktop, Cursor, Kimi, etc.), config JSON:

{
  "mcpServers": {
    "hacktricks": {
      "command": "npx",
      "args": ["-y", "@zebbern/hacktricks-mcp"]
    }
  }
}

As a plugin (bundles the agent skill that teaches efficient usage): this repo is a valid plugin for Claude Code (.claude-plugin/), Codex (.codex-plugin/) and Kimi (kimi-plugin/). Add it from your client's plugin marketplace flow pointing at zebbern/hacktricks-mcp, or for Kimi Work use this plugin link.

Then ask things like:

  • "Search HackTricks for kerberoast and give me the attack commands"

  • "How do I escalate privileges from the lxd group?"

  • "Show me the SSRF section of the pentesting-web pages"

Related MCP server: grimoire

Tools at a glance

Tool

What it does

hacktricks_search

Ranked full-text search with snippets, category filter and abbreviation handling (privesc, sqli, rce, ...)

hacktricks_get_page

Read a page, a single section, or just its code blocks

hacktricks_get_toc

The wiki category tree, so agents can see where topics live

All tools are strictly read-only. Full reference: docs/tools.md.

Documentation

Security and legal

  • The server executes nothing from the wiki; it is a read-only search interface. All queries are parameterized, and user input is escaped before query construction.

  • HackTricks content is offensive-security reference material. Use it only on systems you are authorized to test.

  • Content belongs to HackTricks / Carlos Polop and contributors; this repo contains derived index data plus original server code (MIT).

Credits

Available Tools

3 tools
hacktricks_get_pageRead HackTricks PageA
Read-onlyIdempotent

Retrieve content of a HackTricks page found via hacktricks_search. By default returns the page outline plus content (truncated if very long). Use section= to read one section by heading name, or codeOnly=true to get just the commands/payloads. This is the token-efficient way to consume long pages.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesPage path from hacktricks_search (e.g. 'windows-hardening/active-directory-methodology/kerberoast.md'). Unique suffixes like 'kerberoast' also work.
sectionNoOptional heading name to extract just that section (case-insensitive substring match)
codeOnlyNoIf true, return only fenced code blocks (commands/payloads) from the page or section

Output Schema

ParametersJSON Schema
NameRequiredDescription
urlYes
pathYes
titleYes
contentYes
outlineYes
truncatedYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive behavior, so the safety profile is covered. The description adds real behavioral context the annotations cannot: the default response shape (outline plus content), that long content is truncated, and the alternate modes. Truncation disclosure is especially useful for an agent planning token budget.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with the core action before the mode options. Every sentence earns its place: purpose, default behavior, and alternatives — with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and the description still supplies the crucial default-response and truncation context an agent needs. Combined with readOnly/idempotent annotations and a fully described schema, nothing an agent needs to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all three parameters are already documented with examples and semantics, making 3 the baseline. The description's restatement of section= and codeOnly=true usage adds routing guidance but little semantic detail beyond the schema, such as the case-insensitive matching already noted there.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (retrieve) and resource (HackTricks page), and explicitly ties the input to the sibling hacktricks_search output ('found via hacktricks_search'). This lets an agent distinguish it from hacktricks_search and hacktricks_get_toc without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clearly frames the context of use (consuming a page found via search) and names the two modes — section= for a single heading, codeOnly=true for commands/payloads — with the rationale that this is the token-efficient path for long pages. It does not, however, address when to prefer this over hacktricks_get_toc, leaving one sibling relationship unaddressed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

hacktricks_get_tocHackTricks Table of ContentsA
Read-onlyIdempotent

Get the HackTricks wiki structure: categories and page tree. Call without arguments for the top-level overview, or pass a category to see its pages. Useful to understand where a topic lives before searching.

ParametersJSON Schema
NameRequiredDescriptionDefault
categoryNoOptional category name to expand (e.g. 'Linux Hardening'). Omit for top-level overview.

Output Schema

ParametersJSON Schema
NameRequiredDescription
treeYesIndented text tree of matching pages
categoriesYes

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered by structured data. The description's contribution ('top-level overview' vs. 'expand a category') largely duplicates the schema, and with an output schema present there is no need to describe returns. Some value, but not rich behavioral context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, no padding, and the core purpose is front-loaded before the invocation detail and the workflow hint. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-optional-parameter read tool with an output schema and full annotation coverage, the description supplies purpose, both calling modes, and intended workflow. It is essentially complete; only an explicit sibling contrast would strengthen it further.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with one optional parameter whose meaning ('Optional category name to expand... Omit for top-level overview') is already fully documented in the schema. The description restates the same omit/pass behavior without adding format, syntax, or example detail beyond what the schema provides, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Get the HackTricks wiki structure: categories and page tree,' which precisely describes a table-of-contents retrieval. It hints at the search sibling with 'before searching,' but does not name or contrast itself against hacktricks_search or hacktricks_get_page explicitly, so it falls short of full sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear invocation guidance for both modes ('Call without arguments for the top-level overview, or pass a category to see its pages') and positions the tool in a workflow ('understand where a topic lives before searching'). It stops short of naming the alternative tools or stating when not to use this one.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv0.1.0
    • First observedhacktricks_get_page
    • First observedhacktricks_get_toc
    • First observedhacktricks_search
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.3/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: full-text search for finding pages, page retrieval for consuming content, and TOC for structural overview. There is no overlap in action or resource that would cause misselection.

Naming Consistency5/5

All tool names follow a consistent snake_case pattern with the same 'hacktricks_' prefix and action-oriented verbs (search, get_page, get_toc). The convention is predictable and readable.

Tool Count5/5

Three tools is exactly right for a read-only wiki access server: search, retrieve, and navigate structure. Each tool earns its place without redundancy or bloat.

Completeness5/5

The surface fully covers the domain of consuming the HackTricks wiki: searching, retrieving pages with section/code filtering, and browsing the table of contents. No obvious gaps for a read-only access layer.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • search-docs

    otolab
    A
    license
    A
    quality
    A
    maintenance
    Enables AI agents to search local Markdown documents using natural language, with automatic indexing and section-level retrieval.
    10
    8 npm
    1
    MIT

  • grimoire

    PentHertz
    A
    license
    A
    quality
    C
    maintenance
    Enables AI models to search and retrieve offline security knowledge from over 20 curated sources including HackTricks, PayloadsAllTheThings, and OWASP guides, via the Model Context Protocol.
    9
    201
    MIT

  • HackTricks MCP Server

    Xplo8E
    A
    license
    A
    quality
    D
    maintenance
    Enables searching and querying HackTricks pentesting documentation directly from Claude, with tools for quick lookup, grouped search results, page outlines, section extraction, and cheatsheet mode.
    7
    54 npm
    10
    MIT