Skip to main content
Glama

pentest-mcp-server

by io.github.cyanheads

Pentest Encode

pentest_encode
Read-onlyIdempotent

Transform a payload string through an ordered encoding chain for authorized filter research. Results include the final value, intermediate values, optional decode path and rationale, and detection guidance. All transforms are local; no live probing occurs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
chainYesOrdered list of encodings to apply (1–6 steps). Applied left to right. E.g., ["unicode", "url"] applies Unicode escape first, then URL-encodes the result.
explainNoWhether to include the decode path and bypass rationale.
payloadYesInput payload string to encode. Max 10,000 characters.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNoPresent when the call failed. Absent on success.
encodedNoFinal encoded payload after all chain steps applied.
originalNoThe input payload.
decode_pathNoStep-by-step explanation of how a decoder (WAF, server, browser) would reverse the encoding chain. Included when explain is true.
detection_noteNoDetection methods for encoded variants, including normalization and behavior signals.
bypass_rationaleNoWhy this encoding combination might bypass common filter patterns. Included when explain is true.
intermediate_stepsNoIntermediate values at each encoding step, for tracing the chain.
authorized_use_reminderNoReminder that encoding transforms are for authorized bypass research only.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed8 schema fields changed
    • 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 / explain / description
      Previous value: -"Include step-by-step decode explanation. Set to false for raw transform output only."New value: +"Whether to include the decode path and bypass rationale."
    • 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",
+      "original",
+      "encoded",
+      "intermediate_steps",
+      "detection_note"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]
    • changedOutput schema / properties / detection_note / description
      Previous value: -"How defenders detect encoded payload variants — decoding normalizers, entropy analysis, behavioral detection. Always included to maintain the dual offense/defense framing."New value: +"Detection methods for encoded variants, including normalization and behavior signals."
    • 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: `encoding_error`: An encoding step produced invalid output (e.g., base64 on invalid input). Other values are possible when a failure originates below the handler.",
+          "examples": [
+            "encoding_error"
+          ],
+          "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"
+}
    • removedOutput schema / required
      Removed value: -[
-  "authorized_use_reminder",
-  "original",
-  "encoded",
-  "intermediate_steps",
-  "detection_note"
-]
  2. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint, idempotentHint), the description discloses that all transforms are local and no live probing occurs, which reassures about network safety. It also outlines the output contents (final value, intermediate values, optional decode path, rationale, detection guidance), providing transparency about what the tool returns. No contradictions with 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?

The description is compact, consisting of two sentences that efficiently convey the core action and key details. It front-loads the verb and resource, then lists output features and safety notes without unnecessary elaboration. No filler or redundant phrasing.

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?

Given the schema with full descriptions and annotations indicating read-only and idempotent behavior, the description covers the tool's purpose, output, and safety. It does not delve into edge cases or error handling, but that is acceptable as the output schema likely describes the return format. The description is self-sufficient for an agent to decide when and how to invoke the tool.

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?

The schema already provides detailed descriptions for all three parameters (payload, chain, explain), including examples and constraints. The tool description does not add significant extra meaning to these parameters; it mostly reiterates the output structure. Since schema coverage is 100%, the baseline is 3, and the description does not elevate it further.

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?

The description clearly states the tool's function: transforming a payload string through an ordered encoding chain. It specifies the verb ('Transform') and the resource ('payload string'), and adds context with 'for authorized filter research.' This distinguishes it from sibling tools like payload generation or response analysis, though it does not explicitly name alternatives.

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?

The description conveys when to use the tool implicitly: when encoding a payload for filter research. It includes a safety note ('All transforms are local; no live probing occurs') that hints at usage boundaries. However, it does not explicitly compare with sibling tools (e.g., 'use pentest_generate_payloads for creation'), leaving some ambiguity about when this tool is preferred over alternatives.

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 toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: response analysis, payload encoding, payload generation, methodology guidance, ATT&CK group lookup, ATT&CK technique lookup, and technique mapping. There is no meaningful overlap or ambiguity between tool boundaries.

Naming Consistency4/5

All tools share the pentest_ prefix and most follow a verb_noun pattern such as analyze_response, generate_payloads, and lookup_technique. However, pentest_encode and pentest_guide are verb-only, creating a minor inconsistency in the naming convention.

Tool Count5/5

Seven tools is a well-scoped size for a pentest assistance server. Each tool covers a distinct capability without unnecessary duplication or bloat.

Completeness4/5

The tool set covers the main pentest workflow areas: response analysis, payload generation/encoding, methodology guidance, and ATT&CK reference/mapping. Minor gaps exist, such as no explicit reporting or active scanning tool, but the surface is coherent and usable for its apparent purpose.

Resources