pentest-mcp-server

Pentest Analyze Response

pentest_analyze_response

Read-onlyIdempotent

Analyze an HTTP response from authorized probing for information leakage, fingerprinting signals, and related exposure. Structured findings cover version disclosures, stack traces, debug headers, internal paths, authentication patterns, CORS configuration, detection signals, remediation, and associated methodology vectors.

Input Schema

TableJSON Schema

Name	Required	Description
`context`	No	Freeform context about the authorized test target — e.g., "login endpoint", "GraphQL API", "file upload handler". Narrows the pattern matching to relevant categories. Max 2,000 characters.
`status_code`	No	HTTP status code (100–599). Helps classify the response type.
`response_body`	No	Raw HTML, JSON, XML, or error response body text. Maximum 10,000 characters.
`response_headers`	No	Raw HTTP response headers, optionally including the status line. Maximum 20,000 characters.

Output Schema

TableJSON Schema

Name	Required	Description
`error`	No	Present when the call failed. Absent on success.
`summary`	No	One-paragraph summary of findings and associated follow-up actions.
`findings`	No	Structured findings ordered by severity descending (high first).
`fingerprints`	No	Detected server, framework, language, database, cloud, and other technology signals.
`nextToolSuggestions`	No	Suggested tools derived from detected fingerprints and findings.
`authorized_use_reminder`	No	Reminder that response analysis is for authorized testing only. Rendered first.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 16, 2026

changedOutput schema / properties / findings / items / properties / suggested_vector / description

Previous value: -"Pentest_guide vector name for follow-up when this finding maps to an attack vector. Absent when no direct vector mapping exists."New value: +"Pentest_get_guide vector name for follow-up when this finding maps to an attack vector. Absent when no direct vector mapping exists."

changedOutput schema / properties / nextToolSuggestions / items / properties / toolName / description

Previous value: -"Suggested tool name (e.g., \"pentest_guide\")."New value: +"Suggested tool name (e.g., \"pentest_get_guide\")."

Changed16 schema fields changedAug 22, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / additionalProperties
```
Added value: +false
```

changedInput schema / properties / response_body / description

Previous value: -"Response body text. Paste raw HTML, JSON, XML, or error text. Truncate to the first 10,000 characters for very large responses — the first portion carries most leakage signals."New value: +"Raw HTML, JSON, XML, or error response body text. Maximum 10,000 characters."

changedInput schema / properties / response_headers / description

Previous value: -"Raw HTTP response headers (paste from Burp, curl -v, or similar). Include the status line if available. Max 20,000 characters."New value: +"Raw HTTP response headers, optionally including the status line. Maximum 20,000 characters."

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / anyOf

Added value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "authorized_use_reminder",
+      "findings",
+      "fingerprints",
+      "summary",
+      "nextToolSuggestions"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]

addedOutput schema / properties / error

Added value: +{
+  "additionalProperties": {},
+  "description": "Present when the call failed. Absent on success.",
+  "properties": {
+    "code": {
+      "description": "JSON-RPC error code for this failure.",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "data": {
+      "additionalProperties": {},
+      "properties": {
+        "reason": {
+          "description": "Machine-readable failure mode. Declared by this tool: `no_input`: Neither response_headers nor response_body was provided. Other values are possible when a failure originates below the handler.",
+          "examples": [
+            "no_input"
+          ],
+          "type": "string"
+        },
+        "recovery": {
+          "additionalProperties": {},
+          "description": "Actionable next step for the caller.",
+          "properties": {
+            "hint": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "hint"
+          ],
+          "type": "object"
+        },
+        "retryable": {
+          "description": "Whether retrying may succeed.",
+          "type": "boolean"
+        }
+      },
+      "type": "object"
+    },
+    "message": {
+      "description": "Human-readable description of what went wrong.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "code",
+    "message"
+  ],
+  "type": "object"
+}

changedOutput schema / properties / findings / items / properties / detection / description

Previous value: -"How a defender or SIEM would detect exploitation of this finding."New value: +"Observable signals associated with exploitation of this finding."

changedOutput schema / properties / fingerprints / description

Previous value: -"Technology fingerprinting summary for use in target_context when calling pentest_guide or pentest_map_techniques."New value: +"Detected server, framework, language, database, cloud, and other technology signals."

changedOutput schema / properties / nextToolSuggestions / description

Previous value: -"Suggested next tool calls — typically pentest_guide with fingerprint-populated stack, or pentest_generate_payloads for directly exploitable findings."New value: +"Suggested tools derived from detected fingerprints and findings."

changedOutput schema / properties / nextToolSuggestions / items / description

Previous value: -"A suggested follow-up tool call with pre-filled arguments."New value: +"A suggested tool with arguments derived from the analysis."

changedOutput schema / properties / nextToolSuggestions / items / properties / args / description

Previous value: -"Pre-filled arguments derived from detected fingerprints and findings. Pass directly to the suggested tool."New value: +"Arguments derived from detected fingerprints and findings."

changedOutput schema / properties / nextToolSuggestions / items / properties / reason / description

Previous value: -"Why this tool is the logical next step given the analysis findings."New value: +"Relationship between the analysis findings and the suggested tool."

changedOutput schema / properties / nextToolSuggestions / items / properties / toolName / description

Previous value: -"Tool name to call next (e.g., \"pentest_guide\")."New value: +"Suggested tool name (e.g., \"pentest_guide\")."

changedOutput schema / properties / summary / description

Previous value: -"One-paragraph summary of findings and recommended next steps for the authorized tester."New value: +"One-paragraph summary of findings and associated follow-up actions."

removedOutput schema / required

Removed value: -[
-  "authorized_use_reminder",
-  "findings",
-  "fingerprints",
-  "summary",
-  "nextToolSuggestions"
-]

First observedMay 31, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already carry readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered elsewhere. The description earns credit by disclosing the authorization precondition and by enumerating the categories of structured findings produced (version disclosures, stack traces, debug headers, CORS, detection signals, remediation), which tells the agent what kind of analysis result to expect beyond the raw schema.

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

Conciseness4/5

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

Two sentences, purpose front-loaded before the findings enumeration, no filler. The second sentence is a long comma series, which is dense but still informative rather than padded; it stays within acceptable size for a tool with a rich output schema.

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?

With an output schema present, the description need not explain return shape, and it correctly focuses on what the tool consumes (an HTTP response) and what dimensions it analyzes. The notable remaining gap is guidance on when this analysis is warranted versus the sibling guide/lookup tools, plus any indication of how truncation limits affect results.

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%, and each of the four parameters already documents its own format, bounds, and purpose (context narrows matching, body/header size caps). The description adds nothing parameter-specific, so the baseline 3 for schema-sufficient tools applies.

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 (analyze) plus a precisely scoped resource (an HTTP response from authorized probing), and names the analysis goals: information leakage, fingerprinting signals, exposure. The sibling tools are all payload/technique generators and lookups, so this tool's resource is unmistakably distinct without needing to name an alternative.

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

Usage Guidelines3/5

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

"From authorized probing" implies the precondition and the general use case (post-request response triage), but there is no explicit when-to-use, no when-not-to-use, and no routing to or from the sibling payload tools. Usage is inferable but never stated, which lands it at the minimum-viable level.

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

All pentest-mcp-server tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.