Provides tools for searching TryHackMe rooms by topic or keyword, retrieving room overviews (metadata, difficulty, task outlines), fetching specific task instructions, commands and questions, exporting full room content as structured Markdown, listing curated foundational learning topics, and checking authentication status. Supports session cookie authentication to access subscriber/VIP rooms.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@TryHackMe MCP Server find TryHackMe Linux rooms and pull the first tasks"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
This MCP server connects your AI assistant (Claude Desktop, Antigravity IDE, Cursor, Windsurf, etc.) directly to TryHackMe. It enables you to pull room descriptions, step-by-step walkthroughs, terminal commands, and questions directly into your workspace for training and reference.
Vercel checkpoint bypass: Automatically handles the TryHackMe bot challenge in the background, caching clearance tokens for fast subsequent API calls.
Account-aware extraction: Supports session cookie (connect.sid) authentication to access subscriber and VIP rooms.
Clean Markdown export: Converts raw HTML room materials into readable Markdown with syntax-highlighted code blocks, command snippets, and hints.
Curated tracks: Includes built-in references to core learning modules across Linux, Docker, Bash scripting, networking, and security.
Related MCP server: Kali MCP Server
If you have uv installed, you can add this MCP server directly without cloning the repository.
Open your Claude Desktop configuration file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Add the tryhackme entry to mcpServers:
{
"mcpServers": {
"tryhackme": {
"command": "uvx",
"args": [
"--from",
"git+https://github.com/bledny1099/tryhackme-mcp",
"tryhackme-mcp"
]
}
}
}Restart Claude Desktop (Cmd + Q on macOS and relaunch).
Open Cursor Settings (Cmd + , or click gear icon).
Go to Features -> MCP Servers.
Click Add New MCP Server.
Fill in:
Name: tryhackme
Type: command
Command:
uvx --from git+https://github.com/bledny1099/tryhackme-mcp tryhackme-mcpYou can run the server as a standalone HTTP/SSE service that provides an endpoint URL:
uvx --from git+https://github.com/bledny1099/tryhackme-mcp tryhackme-mcp --transport sse --port 8000SSE endpoint URL: http://localhost:8000/sse
Tool | Parameters | Description |
| None | Checks current authentication status and session validity. |
|
| Searches rooms by topic or keyword (e.g., |
|
| Returns room metadata, difficulty, estimated time, and task outline. |
|
| Fetches full instructions, commands, and questions for a specific task. |
|
| Exports complete room content as a structured Markdown document. |
| None | Lists recommended foundational learning rooms grouped by category. |
Free and public rooms work out of the box without logging in. For VIP/subscriber rooms or account-specific progress, provide your connect.sid session cookie.
git clone https://github.com/bledny1099/tryhackme-mcp.git
cd tryhackme-mcp
uv run python login.pyThis opens a Chrome window, waits for your login on TryHackMe, and saves your session into .env.
Add THM_SESSION to the env block in your MCP client configuration:
{
"mcpServers": {
"tryhackme": {
"command": "uvx",
"args": [
"--from",
"git+https://github.com/bledny1099/tryhackme-mcp",
"tryhackme-mcp"
],
"env": {
"THM_SESSION": "your_connect_sid_cookie_here"
}
}
}
}Once configured, your AI assistant can interact with TryHackMe:
User: "Find TryHackMe rooms about Linux fundamentals and pull the content of task 2 from linuxfundamentalspart1."The model calls:
thm_search_rooms(query="linux")
thm_get_task(room_code="linuxfundamentalspart1", task_no=2)
The model receives the exact theoretical notes, command syntax, and exercise questions in clean Markdown.
Check current TryHackMe authentication status and session validity.
Returns details on whether the MCP server is currently connected under your account.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, but the tool is a zero-parameter read-only check, so risk is inherently low. It discloses that it reports whether the MCP server is connected under the caller's account, but says nothing about failure modes, expiry implications, or required credentials.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences that lead with the core purpose. The second sentence partially restates the first, but it is far from wasteful and reads well.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the description need not enumerate return fields, and a zero-param auth check is simple enough that little else is required. Only the lack of any when-to-use framing leaves a small gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so there is nothing for the description to clarify; baseline 4 applies. Schema description coverage is also 100%, leaving no gap to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource: it checks TryHackMe authentication status and session validity. This is unambiguously distinct from the sibling content-retrieval tools (thm_search_rooms, thm_get_room_overview, etc.), though it makes no explicit effort to contrast itself with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to call this tool versus other options — for example, whether it should be run before other calls or after an auth failure. The description only restates what the tool does, not the conditions that select it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List curated TryHackMe foundational learning rooms grouped by category (Linux, Networking, Security).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. 'List' strongly implies a read-only, non-destructive operation, but it says nothing about caching, rate limits, or whether the curated set is static or account-dependent. Adequate but thin for a zero-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that names exactly what is returned and how it is organized, with zero filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not explain return values, and with no parameters there is little else to specify. The only shortfall is the absence of guidance on how this catalog relates to the sibling search/overview tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so per the rubric the baseline is 4. There is no parameter syntax the description could usefully add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (curated TryHackMe foundational learning rooms) plus the grouping dimension and example categories. An agent can distinguish it from thm_search_rooms by the 'curated' qualifier, though the description never names that sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'curated' implies a browse-the-preset-catalog use case as opposed to searching, which gives implicit guidance, but there is no explicit statement of when to prefer this over thm_search_rooms or thm_get_room_overview. Usage must be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract complete room content into structured Markdown with all tasks, theory, code, and exercises.
Args: room_code: The room identifier (e.g. 'linuxfundamentalspart1').
| Name | Required | Description | Default |
|---|---|---|---|
| room_code | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses the return format ('structured Markdown') which the output schema alone would not convey in words, but says nothing about auth requirements, rate limits, or whether the extraction is read-only. Partial coverage of an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence carries the purpose and output scope, followed by a compact Args block that adds the example. Slight redundancy from restating the single parameter, but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 needn't be re-explained, and the description correctly conveys the Markdown shape. However, for an unannotated tool with a sibling auth-checker (thm_check_auth), the absence of any auth or access caveat leaves a real gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does: room_code is explained as 'the room identifier' with a concrete example ('linuxfundamentalspart1'). That is materially more useful than the bare 'Room Code' title in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Extract') and resource ('complete room content') with an enumerated output scope (tasks, theory, code, exercises). The word 'complete' implicitly separates it from thm_get_room_overview and thm_get_task, but it never names those siblings, so differentiation is left to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit statement of when to use this tool versus thm_get_room_overview or thm_get_task, nor any stated prerequisites such as authentication. 'Complete' hints at 'use when you need everything', but that is implied usage at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an overview of a TryHackMe room, including difficulty, estimated time, and tasks outline.
Args: room_code: The room identifier (e.g. 'linuxfundamentalspart1').
| Name | Required | Description | Default |
|---|---|---|---|
| room_code | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses the shape of the returned summary (difficulty, time, tasks outline) and the verb 'Get' implies a non-mutating call, but it says nothing about auth requirements, rate limits, or whether the overview is cached/live.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded purpose sentence followed by a short args block; no filler. The 'Args:' section is slightly redundant against the schema but costs little.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 re-explained, and the single required parameter is documented by example. Still missing is any routing versus the overlapping sibling thm_get_room_full, which is the main decision an agent faces here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It gives a concrete example identifier ('linuxfundamentalspart1'), which clarifies the expected room_code format beyond the bare string type, but adds no information about validity, case sensitivity, or lookup failure behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get an overview of a TryHackMe room') and enumerates what the overview contains (difficulty, estimated time, tasks outline). It does not, however, distinguish itself from the sibling thm_get_room_full, leaving the overview-vs-full boundary implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is given. The obvious alternative, thm_get_room_full, is never mentioned, nor is any condition that would select the overview over the full room or thm_search_rooms.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full educational content, commands, theory, and questions for a specific task in a room.
Args: room_code: The room identifier (e.g. 'linuxfundamentalspart1'). task_no: The task number (1-indexed).
| Name | Required | Description | Default |
|---|---|---|---|
| task_no | Yes | ||
| room_code | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully enumerates what content is returned (commands, theory, questions), but says nothing about authentication requirements, rate limits, or behavior on invalid room/task values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded purpose sentence followed by a compact Args block; every line contributes. The blank-line Args formatting is slightly verbose but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 both inputs are described. The only meaningful gap is the absence of any note about authentication or failure conditions for a read tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does: it documents both parameters, gives a concrete room_code example, and adds the critical '1-indexed' note for task_no that the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb ('Get') and resource ('full educational content, commands, theory, and questions for a specific task in a room'), plus scope detail that separates it from thm_get_room_full and thm_get_room_overview by targeting a single task rather than an entire room.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance or named alternatives. Usage is only implied by the phrase 'a specific task in a room', leaving the agent to infer that room-wide retrieval belongs to the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search TryHackMe rooms by keyword (e.g., 'linux', 'bash', 'networking', 'privesc').
Args: query: Search term or topic. limit: Maximum number of rooms to return (default: 10).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It doesn't state whether this requires authentication (likely needed given thm_check_auth sibling), whether results are paginated, or how results are ordered. For a search tool with zero annotation coverage, this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise, front-loaded with purpose and examples, then brief parameter notes. The 'Args:' block is standard and doesn't waste words, though the single-sentence intro could be slightly tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present (not shown), return format need not be explained. However, for a search tool with no annotations, the description should mention authentication requirements and possibly result behavior. It covers parameters adequately but lacks behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description does add meaning by explaining that query is a 'search term or topic' and limit is 'maximum number of rooms to return (default: 10)'. However, this merely restates the parameter names without adding format, constraints, or examples beyond the one keyword example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) and resource (TryHackMe rooms), and gives concrete keyword examples that make the scope unmistakable. It's clearly distinguished from siblings like thm_get_room_overview or thm_get_room_full which fetch by room rather than search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (search by keyword/topic) but doesn't say when to use this versus alternatives like thm_get_curated_topics or thm_get_room_full. No explicit when-not conditions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0thm_check_auththm_get_curated_topicsthm_get_room_fullthm_get_room_overviewthm_get_taskthm_search_roomsScored across 6 tools
Most tools have clearly distinct purposes: auth check, keyword search, curated listing, room overview, single task, and full-room extraction. The only mild overlap is granularity between thm_get_task/thm_get_room_full and thm_get_room_overview/thm_get_room_full, since full content subsumes the others, but the scopes are described clearly enough to choose between them.
All six tools follow a consistent `thm_` prefix plus verb_noun pattern (check_auth, search_rooms, get_room_overview, get_task, get_room_full, get_curated_topics). The convention is uniform and predictable throughout with no style mixing.
Six tools is well-scoped for a focused content-reading/extraction server. Each tool earns its place, covering auth, discovery, and content retrieval at varying granularities without bloat.
The content-access surface is fairly complete: auth, search, curated discovery, overview, task-level, and full-room extraction are all present. Minor gaps exist around user progress/completion tracking or answer retrieval, but the core read workflow has no dead ends.
Web search, URL content extraction to Markdown, site mapping, and recursive web crawler.
Web search, fetch, extract, and research for AI agents. Markdown output + AI-synthesized answers.
Read any web page as clean Markdown for AI agents: fetch, search, metadata, links. SSRF-safe.
Fetch pages as markdown, search web and news, extract structured data. For AI agents.
