Skip to main content
Glama
getproxykit

ProxyKit-mcp

Official

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
PROXYKIT_MCP_TIERNoComma-separated allowlist: readonly (default), mutate, capture, analysis, replay.readonly
PROXYKIT_ENGINE_URLNoEngine control API URL.http://127.0.0.1:17171
PROXYKIT_CONTROL_AUTH_TOKENNoThe control token directly. Use the _FILE form instead where possible.
PROXYKIT_CONTROL_AUTH_TOKEN_FILENoPath to the engine's control.token. Preferred over PROXYKIT_CONTROL_AUTH_TOKEN.

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

CapabilityDetails
tools
{
  "listChanged": true
}
prompts
{
  "listChanged": true
}
resources
{
  "subscribe": true,
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
analyze_requestA

Run the engine's analysis pipeline on a single captured request (linting, schema drift, privacy, performance). Returns the structured explanation plus any new findings. Re-runs even if cached unless refresh is false.

attach_environmentA

Activate an environment so subsequent captures and replays resolve variables against it. Use list_environments to discover ids.

clear_trafficA

Delete every captured traffic entry from the engine buffer. Irreversible. Most MCP clients prompt for confirmation before invoking destructive tools — this is one of them.

compare_sessionsA

Diff a session against a baseline session and return a structured comparison (added/removed/changed requests, latency deltas, finding drift). Both sessions must be stopped.

create_chaos_ruleB

Create a chaos rule. Chaos injects latency, errors, throttling, and corruption patterns that mirror real-world degraded services.

create_mock_from_requestB

Convenience: fetch a captured request by id and scaffold a mock rule from its recorded response. Optional overrides let the caller tweak fields before persisting.

create_mock_ruleA

Create a mock rule. The rule fires for matching requests through both the capture proxy and the standalone mock server, and is persisted in the engine database. Returns the created rule with its assigned id.

create_rewrite_ruleA

Create a rewrite rule. Rewrites mutate live requests/responses (headers, body, status) without short-circuiting the upstream call.

delete_chaos_ruleB

Permanently delete a chaos rule by id.

delete_mock_ruleA

Permanently delete a mock rule by id. The action is recorded in the local audit log.

delete_rewrite_ruleB

Permanently delete a rewrite rule by id.

delete_rule_packA

Remove a rule pack from the engine. Does not uninstall rules the pack already added — use the individual delete_* tools in the mutate tier for that.

delete_sessionA

Permanently delete a session and its association with the captured requests (the requests themselves stay in the buffer).

dismiss_findingA

Mark a finding as dismissed so it stops appearing in default views. Reversible with restore_finding.

export_rule_packA

Export the current rule configuration as a portable pack manifest. The agent can then save it, share it, or hand it to import_rule_pack on another machine.

get_ca_statusA

Return whether a local CA root certificate is available for HTTPS interception. Only the public PEM is exposed; the private key never leaves the engine.

get_findings_summaryA

Return counts of current findings grouped by severity and category. Cheap; use this before list_findings to triage.

get_requestA

Return the full headers and redacted body of a single captured request by id.

get_sessionA

Return the manifest of a single session by id, including its included entries and any attached baseline.

import_rule_packA

Import a rule pack bundle (mocks + rewrites + redaction rules) into the engine. The pack is registered but not installed until install_rule_pack is called.

install_rule_packA

Install a previously-imported rule pack. This persists every rule inside the pack into the engine — potentially many rules at once, so use with care.

list_chaos_rulesA

List chaos rules. Chaos injects latency, errors, and partial failures matching real-world degraded-service patterns.

list_environmentsA

List configured environments and which one is active. Variables are returned with their keys but secret-shaped values are redacted.

list_findingsA

List engine findings (privacy, schema, performance, lint). Use severity or scope to narrow.

list_mock_rulesA

List configured mock rules. Each rule fires when a matching request flows through either the capture proxy or the standalone mock server.

list_paused_breakpointsA

List requests currently paused at a breakpoint, awaiting agent or human review before being released to the upstream.

list_rewrite_rulesA

List configured rewrite rules. Rewrites mutate live requests/responses (headers, body, status) without short-circuiting the upstream call.

list_rule_packsA

List installed rule packs. A rule pack is a versioned bundle of mocks/rewrites/redaction rules — useful for sharing a known-good configuration across machines or teams.

list_scriptsB

List installed JS hook scripts. Scripts run server-side in the engine's goja VM and can mutate any request/response programmatically.

list_sessionsA

List named sessions. A session is a bookmarked range of traffic captured for replay, sharing, or baseline diffing.

list_trafficA

List captured HTTP/HTTPS requests. Filters narrow by method, URL substring, response status, and page through the result set. Response bodies are redacted server-side before return.

propose_redaction_rulesA

Scan recent captured traffic for PII / secret patterns not covered by existing redaction rules and return only the redaction-kind suggestions. Scanning records each suggestion in the engine. Installing one is not exposed over MCP — accept it in the ProxyKit app's suggestions view, or add the rule directly with proxykit redaction add --path <key>.

proxy_statusA

Return whether the MITM proxy is running, which port it is bound to, whether TLS interception is configured, and how many captured entries are in the buffer.

release_breakpointA

Release a paused request so it continues to the upstream (or returns to the client, depending on which side was paused). Optionally pass edits to mutate the request before release.

replay_requestA

Re-issue a captured request — optionally with method/url/body/headers overrides — and return the upstream response. Use this to verify a fix against the real backend or A/B between two URLs.

replay_sessionA

Re-fire every captured request in a session against the real upstream. Returns one row per attempted request with status, duration, and error if any. One failure does not abort the loop.

rescan_findingsA

Re-scan every captured request through the findings detectors. Useful after adding a redaction rule or changing detector config. Returns analyzed and findings counts.

restore_findingA

Restore a previously dismissed finding so it appears in default views again.

run_ai_workflowA

Run one of ProxyKit's built-in local workflows over engine data. These workflows are deterministic — they do not call an external LLM. Returns markdown the agent can chain into its own reasoning ("explain_failure → generate_issue → suggest_tests").

search_trafficA

Substring search across captured URLs and a window of recent entries. For very large captures, narrow the window with method+status first.

start_captureA

Start the capture proxy. Optionally choose a port and toggle TLS interception. If the proxy is already running, this returns the current status.

start_sessionA

Start a named session. All traffic captured while the session is active is tagged with the session id, so the agent can later replay or compare it. Returns the new session record.

stop_captureA

Stop the capture proxy. Captured entries already in the buffer are preserved.

stop_sessionA

Stop an active session. After stopping, the engine automatically rescans the captured entries for findings.

toggle_chaos_ruleA

Enable or disable a chaos rule by id. Omit enabled to flip.

toggle_mock_ruleA

Enable or disable a mock rule by id without changing any other fields. Omit enabled to flip the current value.

toggle_rewrite_ruleA

Enable or disable a rewrite rule by id. Omit enabled to flip.

update_chaos_ruleC

Update a chaos rule by id. Partial.

update_mock_ruleB

Update an existing mock rule by id. Pass only the fields you want to change; missing fields keep their current value. Returns the updated rule.

update_rewrite_ruleC

Update a rewrite rule by id. Partial — only changed fields need be passed.

Prompts

Interactive templates invoked by user choice

NameDescription
diagnose_requestWalk through diagnosing a single captured request: pull headers/body, run the analysis pipeline, and explain the most likely cause of any non-2xx or finding.
draft_regression_testDraft a regression test from a captured request: an assertion rule that locks in the recorded contract, plus the replay command that exercises it.
summarize_sessionProduce a human-readable summary of a captured session — P50/P95 latency, error rate, top endpoints, notable findings, and a one-paragraph narrative.

Resources

Contextual data attached and managed by the client

NameDescription
Active environmentThe currently-active environment (name + variables, with secret-shaped values redacted). Useful for the agent to know which base URLs / auth values will be substituted into upcoming requests.
Current findings snapshotLatest findings summary (counts) plus the most recent findings list. Cheap to read; pull this before deciding whether to call rescan_findings.
Engine statusWhether the proxy is running, on which port, with how many captured entries. Same shape as the proxy_status tool.

TDQS

B3.4/5.0

Scored across 50 tools

Disambiguation4/5

Tools cluster into clear functional families (traffic, sessions, mocks, rewrites, chaos, findings, rule packs), and descriptions carefully differentiate the three parallel rule types. Minor overlap remains between list_traffic and search_traffic, and create_mock_rule vs create_mock_from_request, but boundaries are mostly inferable.

Naming Consistency5/5

Nearly every tool follows a strict snake_case verb_noun pattern (list_*, get_*, create_*, update_*, delete_*, toggle_*, start_*/stop_*, replay_*, import_/install_/export_*). The few noun-phrased tools like proxy_status and get_ca_status still fit cleanly. Consistency is excellent.

Tool Count2/5

At 50 tools the surface is very heavy, with three separate rule families (mock/rewrite/chaos) each carrying a full 5-6 tool CRUD set, plus sessions, findings, packs, envs, breakpoints, and scripts. The domain is broad, but the count sits at the extreme end and invites consolidation.

Completeness4/5

Coverage of the capture/replay/rule/findings lifecycle is thorough, including rule packs, environments, breakpoints, and CA status. Gaps are minor but real: scripts expose only list_scripts (no create/update/delete), breakpoints have no creation tool, and redaction rule installation is deliberately not exposed over MCP.

Maintenance

ActivityMaintained
ResponsivenessNo issues