pentest-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_engagementsA | List every engagement on this machine, newest activity first. |
| get_engagement_summaryA | Counts and metadata for the engagement. Call this first: it reports how many hosts, credentials, unvalidated credentials, successful and failed authentications, findings by status, open tasks, hosts with no service recorded, and entities carrying unverified values exist -- which tells you which further queries are worth making. |
| list_entitiesB | List entities of a type, optionally filtered. type is one of host, service, identity, credential, domain, share, artifact, web_endpoint. filter accepts {"validated": false} for credentials never successfully used, {"unverified": true} for entities whose values did not appear verbatim in the source, or any data field as an exact match. |
| get_entityA | Everything known about one entity, including its attributes, identity keys, relationships, authentication attempts, and the segments its evidence came from. Accepts an entity id, an identity key, or a plain name such as FILE01 or an IP address. |
| searchC | Search captured terminal output and entities for an exact value -- an IP address, hostname, username, filename, or secret. scope is segments, entities, or all. |
| get_segmentA | The recorded terminal output of one segment, with its pane, timestamp, and exact raw byte range. Set raw=true to get the original bytes including escape sequences rather than the normalized text. |
| get_provenanceB | Trace a fact back to its evidence: the observations that support an entity or finding, and for each the segment, terminal, timestamp, and exact byte range it came from. This answers 'where did this credential come from'. |
| get_recent_activityA | What happened recently, newest first: captured terminal activity with a preview of each segment. Use minutes for a relative window. |
| list_auth_attemptsA | Authentication attempts and their outcomes. Filter by result ('success' or 'failure'), by target, or by credential id. This is what shows which credentials work where, and what has already been tried. |
| list_findingsB | Findings, optionally filtered by status (candidate, confirmed, rejected, resolved). Automated extraction only ever creates candidates. |
| get_findingC | One finding with its affected entities and evidence references. |
| list_tasksC | Tasks implied by engagement state, optionally filtered by status. |
| record_observationA | Record something the operator saw or concluded that is not in captured terminal output -- a note, a hypothesis, a credential seen inside a GUI, or a correction. kind is one of host, domain, service, identity, credential, auth_attempt, share, artifact, web_endpoint, observation, relationship, note, task, finding_candidate, or correction. Use kind='correction' with data={"separate": ["", ""]} to assert that two identity keys are NOT the same thing; the entities separate on the next rebuild. All writes are attributed to the operator or agent, never to extraction. |
| update_findingA | Set a finding's status or fields. Use status='confirmed' to accept a candidate and status='rejected' to dismiss it; a rejected finding is not recreated by later extraction. |
| update_taskC | Set a task's status or fields. status is open, in_progress, done, or dismissed; a dismissed task is not recreated by later extraction. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 15 tools
Each tool targets a distinct resource and action: listing vs getting vs updating findings/tasks/entities, searching, tracing provenance, recording observations. No two tools appear to do the same thing, and overlaps like list_findings vs get_finding are cleanly separated by collection vs singleton semantics.
All tool names follow a consistent lowercase_verb_noun pattern (get_, list_, search, record_, update_). Verbs are uniform and actions are clear from names alone, with no camelCase or mixed conventions.
15 tools is well within the ideal range for a specialized MCP server. Each tool serves a distinct purpose in the penetration-testing workflow (observation, analysis, status management, provenance), with no redundancy or bloat.
The surface covers the full investigation lifecycle: capture review, entity management, finding workflow (candidate/confirm/reject), task tracking, provenance tracing, and operator note-taking. Minor gaps exist (no explicit engagement creation/deletion or direct entity editing), but these are addressable via record_observation and do not create dead ends.