Plunger: See Exactly What Your AI Agent Is Sending to APIs

AI agents calling APIs is now routine, but one critical question remains unresolved: what exactly is it sending out? Where did your token go? Did some variable go undefined and get leaked to the server as literal text? When you try to review what happened after the fact, you find that curl leaves no record at all.

Plunger is built precisely for this pain point. It's an HTTP client designed for both humans and AI agents—a single program with three entry points: a graphical window for you, a command line for scripts, and an MCP server for agents. All three share the same saved requests, the same variables, and the same history.

Three Entry Points, One Set of Data

Plunger's core design philosophy is "same source for humans and machines." Requests you open in the window are also accessible to agents via MCP or CLI; every request an agent sends lands in real time in the history you see, tagged with its source as CLI or MCP.

This means debugging no longer requires guesswork. When an agent behaves unexpectedly, you can pull up the actual request it sent and the response it received, instead of staring at a black box.

Responses are returned as a tree structure that can be collapsed, searched, and used to directly copy the JSON path of any node—for deeply nested API responses, this detail saves a lot of time manually digging through structures.

MCP (Model Context Protocol) is an open protocol introduced by Anthropic in late 2024 to let AI models connect to external tools and data sources in a standardized way. Before MCP, every agent framework (LangChain, AutoGPT, etc.) defined "tool calls" its own way, forcing the same API client to be adapted separately for different frameworks. MCP abstracts this into a protocol layer: clients (agent hosts) communicate with MCP servers via JSON-RPC, and servers expose three categories of capabilities—tools, resources, and prompts. Plunger runs as an MCP server, meaning any MCP-compatible agent—Claude Desktop, Cursor, various IDE plugins—can call it directly, without the Plunger team writing a separate adapter for each host. This is also currently the most universal way to connect via an "agent entry point."

Variable Mechanism: Better to Fail to Send Than to Send Wrong

Plunger extracts the parts of a request that change into variables. For example, the base address and API key are both variables, and the request itself only holds references.

This design's value lies in the choice of failure mode. When you forget to define a variable, Plunger refuses to send and clearly tells you which one is missing—rather than sending a placeholder like {{token}} to the server as-is. The latter is precisely the most hidden and dangerous mistake when agents call APIs: the request appears to succeed, but sensitive information or placeholders have already flowed somewhere they shouldn't.

Save requests with Ctrl-S, and archive to groups directly from the menu. Groups support nesting, so even large API projects stay tidy, and agents can file their requests into the same groups.

Sending with unresolved template variables is a classic class of API call incident. A typical scenario: the request body contains "Authorization": "Bearer {{api_key}}", but the environment variable file path is wrong or the variable name is misspelled, and the client sends it without validation—so the server receives the literal text {{api_key}}. Most servers respond with a 401, which looks like just an "authentication failure"; but some servers log the request body as-is or echo it into the error response, exposing the placeholder along with the field name it claims to protect. For agents the problem is more serious: it won't stop on seeing a 401 to check configuration like a human would, but may retry, switch paths, and spread the same faulty request pattern to other endpoints. Plunger chooses to do "pre-send validation" on the client side, essentially moving the error from "silent remote failure" to "explicit local rejection"—a classic example of the fail-mode tradeoff in security design.

Fetch Precisely What You Need, Not the Full Response

When an agent sends a request via the CLI or MCP, it can request only the fields it needs. The demo shows how to extract just one field from a large response.

The significance for agents isn't just "saving tokens." Limiting the scope of returned values is itself a form of permission reduction—data an agent can't obtain, it can't misuse or leak. Combined with the design that "the token it uses is never shown to it," sensitive credentials are invisible on the agent side.

Workflows: Making Multi-Step Calls Observable

When one response feeds into the next request, Plunger lets you save the steps as a workflow. An agent can run the entire chain in one call, while you watch it light up level by level like a flowchart in the interface.

The values passed at each step are written on the connecting lines—what the previous step handed to the next is immediately clear. This turns "an agent chaining API calls" from a series of hard-to-trace independent events into a replayable, auditable visual process.

Workflow in the context of API orchestration refers to chaining multiple requests into a directed pipeline by dependencies, where the output of one step becomes the input of the next. The traditional approach is to write scripts (Shell, Python) that pass data between steps via variables, but readability and debuggability degrade sharply as the number of steps grows. Visual workflows draw this chain explicitly: each node is a request, and connecting lines are labeled with the specific values passed. This is especially important for agent scenarios: multi-step calls autonomously orchestrated by an agent often complete in seconds, and when something goes wrong a human only sees a final result. With a visual chain, you can replay node by node to pinpoint exactly which step's input was contaminated and which step's filtering logic failed.

Security Auditing: Tamper-Evident, Credentials Masked Before Hitting Disk

Plunger claims that every action an agent takes is written to a tamper-evident log. Credentials in request headers, query strings, and request bodies are masked before touching disk, and chain verification can be performed at any time.

This design places "post-hoc accountability" and "pre-emptive leak prevention" in the same mechanism. For teams that need to use AI agents to call APIs under compliance frameworks, a verifiable log chain is often more appealing than the features themselves.

Tamper-evident log differs from ordinary logs in "verifiable as unmodified," not "impossible to modify." It is typically implemented via chained hashing: each log record contains the hash of the previous record, forming a hash chain; any modification to historical records causes all subsequent hashes to mismatch. This is homologous to blockchain's Merkle structure, but doesn't require distributed consensus—a single machine can implement it. Combined with credential masking before disk write, even if the log file is fully obtained, an attacker cannot get usable tokens. In compliance scenarios (such as SOC 2, ISO 27001 audits), this mechanism is often used to demonstrate "log trustworthiness"—auditors don't need to trust the log storage provider, only verify the hash chain.

Installation and Authorization

Plunger is an open-source project under the MIT license. According to the video, it can be installed via pip, homebrew, or WinRAR (the WinRAR bit is almost certainly a joke in the demo), or you can simply run plunger install to hook it into your agent.

What Problem Does It Solve

Placing Plunger back in the context of the agent toolchain, it fills a long-neglected gap: observability and credential boundaries.

curl is designed to be one-off, stateless, and use-and-discard, which is fine for manual human debugging, but agents call APIs at high frequency, in batches, and automatically—at which point "no record" becomes a systemic risk. With its shared trio of requests/variables/history, plus masked logs and enforced variable validation, Plunger attempts to bring agent API calls onto an auditable track.

For developers integrating agents into production environments, this isn't just a more convenient HTTP client—it's more like a logged gate between the agent and your backend.

One-line Summary

Plunger is a shared HTTP client for humans and AI agents, using variable validation and masked tamper-evident logs to fill in the observability and credential boundaries of agent API calls.

Paragraph Summary

Plunger addresses the pain point that "what an AI agent sends out can't be traced" when calling APIs, providing an HTTP client whose GUI, CLI, and MCP entry points share one set of requests, variables, and history. Its variable mechanism refuses to send when undefined rather than leaking placeholders, field-level selection narrows agent permission boundaries and hides tokens from it, and tamper-evident logs plus pre-disk credential masking enable auditing. Workflows turn an agent's multi-step calls into a visual, replayable chain. The article argues it fills a long-neglected link in the agent toolchain: observability and credential boundaries, positioning it as a logged gate between the agent and the backend.