Sometimes you don't need another platform. You just need to see what the API returned.
AI can write the code. AI can build the pipeline. We still look at the diff before we push. We still look at the logs when something feels wrong. And we still look at the JSON when an API doesn't do what we expected.
Seeing is believing. Plunger is for the moment between "I think it works" and "I can see it works."
Related MCP server: mcp-opentym
A small desktop app that sends an HTTP request and shows you what came back.
Request: GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS. Params, headers and a Bearer token field.
Body: JSON, form-urlencoded, raw text, or multipart form-data with real file uploads.
Response: status, time and size, the headers, and the body as a collapsible JSON tree. Copy it or save it to a file.
Variables: {{name}} anywhere in the request, plus {{$uuid}}, {{$timestamp}}, {{$randomInt}} and {{$env:NAME}} for reading an OS environment variable at send time. A request with an undefined variable is refused, never sent with the placeholder in it.
Import and export: paste a curl command (bash or Windows cmd, including -F uploads) or a PowerShell Invoke-WebRequest / Invoke-RestMethod command, such as DevTools' Copy as cURL or Copy as PowerShell; or open a HAR file. Copy any request back out as curl (bash), curl (Windows cmd), PowerShell or a JavaScript fetch call with Ctrl+Shift+C or File > Export request, shown with syntax highlighting.
Keep what matters: local history, named saved requests (Ctrl+S) and tabs (Ctrl+T).
Local HTTPS: skip certificate checks for a self-signed dev server, with a warning that stays visible while it's on.
Behind a proxy: Plunger uses your system proxy settings and the HTTP_PROXY, HTTPS_PROXY and NO_PROXY environment variables.
Find it again: the sidebar filter searches your whole history and saved requests by URL, method, name or status; right-click a value in a JSON response to copy its path or value.
It's a native program, not a web page, so it reaches whatever your machine can reach: localhost, a dev box on your network, an API that sends no CORS headers.
See the JSON, even when an AI sent the request.
Plunger is built to be driven safely by AI agents, not just clicked by people. The same plunger.exe is also a command-line API client and an MCP server, so an agent like Claude Code sends requests through Plunger's engine instead of running curl. No account, no cloud, no telemetry: now safe for your agents too.
One exe. Human GUI, agent CLI, agent MCP. The same safety guarantees in every mode.
{
"mcpServers": {
"plunger": { "command": "C:\\Tools\\plunger\\plunger.exe", "args": ["mcp"] }
}
}Run plunger install (or File > Set up AI agents... in the window) to register the MCP server in Claude Code, Cursor, Kiro, Codex, Windsurf, VS Code or Gemini CLI and write the always-on steering that tells the agent to use Plunger instead of curl. See docs/agents.md.
Undefined-variable safety. Plunger refuses to send a request with an undefined {{variable}}. curl will happily send the placeholder text.
Credential isolation. The agent writes {{token}} and never sees the value. Secrets you've chosen to remember are kept in Windows Credential Manager and filled in by Plunger; if a server echoes one back, it comes back as [redacted:token].
Shared human and agent history. You testing in the window and an agent testing from the command line read and write the same saved requests and history.
Structured, typed output. Status, timing, size, headers and the parsed JSON body come back as separate fields, not text the agent has to pick apart.
A local audit trail. Every agent request lands in the history you see in the window, tagged MCP or CLI, as it happens. curl leaves no record unless you build the logging yourself.
Tools: send_request, import_curl, list_saved_requests, get_history, list_variables, export_curl. From a terminal: plunger send "Saved request name", plunger send --url ..., plunger history. Setup, every tool and option, exit codes and the fine print are in docs/agents.md.
When one response feeds the next request (log in, then use the token; look up an id, then act on it), save the steps as a workflow. An agent runs it in one call (run_workflow, or plunger workflow run), and you see it as a flow in the window: a card per step on a rail of connected dots, the values a step hands on written on the connector, and every step lit up as it runs.
Built in Rust with egui because we wanted a small, fast, native application. No webview, no bundled browser: one exe of about 7 MB, which is also a command-line client and an MCP server for AI agents.
No account to create. No cloud to sync to. The only network traffic is the requests that get sent, by you or by an agent you've connected: no analytics, no telemetry, no update checks. History and saved requests live in one local folder, %APPDATA%\Plunger\data. Bearer tokens and secret variables are never written to a file unless you tick "remember", which keeps them in Windows Credential Manager. Credential-looking headers are blanked before history is saved. Details are in the privacy policy.
Plunger is MIT licensed. Read it, build it, change it.
A few promises, so you know what you're picking up:
It will never require an account.
It will never add telemetry.
Existing features will never move behind a paywall.
Microsoft Store (signed by Microsoft, no warning, updates itself; it can trail the newest release by a few days): get it here, or
winget install 9P7WRKLN6WHR --source msstoreScoop:
scoop bucket add metamug https://github.com/metamug/scoop-bucket
scoop install plungerpip / uv (Windows, Linux, macOS), from 0.5.1:
pip install plunger-cli # puts a `plunger` command on your PATH
pipx install plunger-cli # same, in its own environment (use this if pip says "externally-managed-environment")
uvx plunger-cli mcp # or run the MCP server without installing anythingmacOS (11 or later, Apple Silicon and Intel), Homebrew:
brew install --cask metamug/tap/plunger # Plunger.app, and a `plunger` command on your PATHOr download Plunger-<version>-macos.dmg from the releases page, open it and drag Plunger to Applications. The first time, right-click the app and choose Open (it is not signed with an Apple Developer ID yet; see docs/packaging-macos.md). pip install plunger-cli also works on a Mac.
Zip:
Download plunger-windows.zip and unzip it anywhere.
Run plunger.exe.
Windows 10 or 11, 64-bit. The zip isn't code-signed yet, so Windows may say "Windows protected your PC": click More info, then Run anyway. Or build it yourself.
To update the zip, replace the exe. To remove it, delete the exe and %APPDATA%\Plunger.
Paste a URL, or import a curl command.
Press Ctrl+Enter. While a request is in flight, press Escape to cancel waiting for it.
Read the response.
Press Ctrl+L to focus the URL field and select its contents.
Press Ctrl+F to search the response body: Enter and Shift+Enter (or Next / Prev) step through the matches, Esc closes the box.
With multiple request tabs, Ctrl+Tab moves to the next tab and Ctrl+Shift+Tab moves to the previous one. Cycling wraps at either end.
rustup toolchain install stable-x86_64-pc-windows-gnu
rustup default stable-x86_64-pc-windows-gnu
# plus mingw-w64 (gcc, windres, dlltool) on PATH, e.g. from WinLibs or MSYS2
cargo build --release # target/release/plunger.exe
cargo testSet PLUNGER_DATA_DIR to run against a throwaway data folder instead of your real history.
Issues and pull requests are welcome. Before adding a feature, ask: does this help someone quickly see what an API is doing? Would someone open Plunger specifically for it? If yes, it probably belongs. Accounts, sync, collaboration and platform features don't.
CONTRIBUTING.md: what fits, how to build, how to send a change.
design.md: how it's built and why.
SECURITY.md: how to report a vulnerability privately.
CODE_OF_CONDUCT.md and the CHANGELOG.
Run cargo test and cargo clippy --all-targets before sending a PR. Maintainers: releases are GitHub releases with plunger-windows.zip attached (push a v* tag).
Remove a saved request by name (its history entries stay). Returns what was removed.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The name of a variable an agent set, or of a saved request. |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| body | No | |
| group | No | The group a saved request is filed under (`Jira`, `Jira/Issues`). |
| method | Yes | |
| headers | Yes | |
| options | No | What a saved request carries besides its form: `timeout_secs`, `follow_redirects`, `insecure_tls` and `select`. They apply when it is sent by name, unless the call gives its own. |
| saved_id | No | Set when saved under `save_as`; it now shows in Plunger's Saved list. |
| body_type | Yes | none, json, form-data or raw. |
| not_saved | No | Fields of the call that a saved request does not keep (only said when there are some). |
| form_fields | No | multipart -F fields: "name=value" or "name=@file". |
| variables_used | Yes | {{variables}} the request uses. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation already declares destructiveHint=true, so the description's real contribution is scoping the destruction: history entries survive, so this is a partial, non-cascading delete. It also notes the tool returns what was removed, but does not say whether the removal is reversible or requires confirmation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero filler, with the scope of deletion front-loaded before the return-value note. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the return-value sentence is bonus rather than necessity, and the destructive annotation carries the safety signal. The only real gap is irreversibility/permission requirements for a delete, which the description does not address.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the name parameter is fully documented in the schema. The description's 'by name' merely repeats that, adding no format or resolution semantics of its own — baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Remove), resource (saved request), and identifier (by name), which cleanly separates it from delete_variable and delete_workflow in the sibling set. An agent can route to it without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the resource name, but there is no explicit when-to-use guidance, no mention of alternatives (e.g., delete_variable for variables, or whether history must be cleared separately), and no preconditions. Adequate but leaves routing inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a variable an agent set (with set_variable). Variables the user defined in the window can only be removed there.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The name of a variable an agent set, or of a saved request. |
| Name | Required | Description |
|---|---|---|
| deleted | Yes | The variable that was removed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, so safety and repeat-safety are covered structurally. The description adds genuinely new context the annotations cannot express: the deletion scope is limited to agent-set variables, and user-defined window variables are out of reach. Return behavior and failure mode (nonexistent name) are left implicit, keeping this at 4.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero waste. The scoping rule that matters most (agent-set only) is front-loaded, and the exclusion follows immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation, and annotations carry the destructive/idempotent profile. The description supplies the one non-obvious constraint an agent needs before calling. Minor gap: it does not say what happens when the name does not exist or matches a saved request, which the sibling set makes a real risk.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single `name` parameter is documented in the schema itself. The description adds no format or disambiguation detail for `name`. Notably, the schema says the name may refer to 'a saved request,' which is confusing given the sibling delete_saved_request, and the description does not resolve that ambiguity — preventing a higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (remove a variable) and immediately scopes it: only variables an agent set via set_variable. This distinguishes it from delete_saved_request and from set_variable's inverse operation, so an agent can route correctly without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states a when-not: 'Variables the user defined in the window can only be removed there,' which prevents a mis-call. It also names set_variable as the counterpart operation. It stops short of a full when-to-use statement (e.g., confirming the agent should delete its own scratch variables when done), so 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a workflow by name. Returns what was removed.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The name of a variable an agent set, or of a saved request. |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| group | No | The group it is filed under (`Jira`, `Jira/Issues`), when it has one. |
| steps | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, so the safety profile is covered. The description adds only 'Returns what was removed,' which is redundant given the tool has an output schema, and it says nothing about permanence, permissions, or side effects on dependent workflows.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the action and lookup key front-loaded. The second sentence is largely wasted since the output schema already describes the return value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter destructive mutation with an output schema and destructiveHint, the essentials are present, so an agent can invoke it. However, nothing warns that the deletion is permanent or describes the effect on anything referencing the workflow, which is meaningful context for a delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single parameter and the baseline is 3. The phrase 'by name' mildly reinforces name-based lookup, but the schema's own description oddly references variables and saved requests rather than workflows, and the description does not resolve that mismatch.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Remove a workflow') plus the lookup key ('by name'), which separates it cleanly from delete_variable and delete_saved_request among the siblings. It does not explicitly name an alternative, but the resource is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says what the tool does but gives no guidance on when to prefer it over alternatives such as delete_saved_request or set_group, nor any prerequisites or warnings about irreversible deletion. Usage must be inferred entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn a saved request (by name) or a history entry (by id) into a curl command, for CI scripts or tools that only speak curl. {{variables}} stay as placeholders, so no secret is written out.
| Name | Required | Description | Default |
|---|---|---|---|
| history_id | No | Or an id from get_history. | |
| saved_request | No | Name of a saved request. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses a genuine behavioral trait: '{{variables}} stay as placeholders, so no secret is written out' — an important safety/redaction property an agent would not infer from the schema. It omits what happens when both or neither parameter is supplied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with zero filler; the purpose is front-loaded and the safety note is placed last as a supporting detail. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description sufficiently implies the return value (a curl command string). Annotations cover the safety profile and the redaction behavior is stated, but the 0-required-parameter ambiguity (which mode wins if both/neither supplied) is left unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real meaning by explaining the two distinct lookup modes (saved request by name vs history entry by id) and cross-referencing get_history for the id source. It does not resolve precedence when both optional params are given or omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (turn into) and resource (a saved request or history entry → curl command), and names the two input modes explicitly. It is clearly distinguishable from the sibling import_curl, which does the reverse transformation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear context of use: 'for CI scripts or tools that only speak curl', which tells the agent why and when to reach for it. It does not, however, explicitly state when NOT to use it or name the inverse tool (import_curl) as the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent requests from the shared history, newest first: who sent them (gui = the user, cli or mcp = an agent), method, URL, status and time. Credentials are already blanked. Use it to see what the user tried, or to check what was sent earlier.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many recent requests to return, newest first (default 20, at most 200). | |
| min_ms | No | Only requests that took at least this many milliseconds, e.g. 1000 for the slow ones. | |
| search | No | Only requests whose URL, method, name or status contains this text (case-insensitive), e.g. "orders" or "500". | |
| source | No | Only requests sent by `gui` (the user), `cli` or `mcp` (an agent). | |
| status | No | Only this status: `401`, a class like `4xx` or `5xx`, `ok` (2xx), `fail` (4xx, 5xx or no response), or `error` (no response). | |
| saved_request | No | Only sends of this saved request (same method and URL), to see how it has been doing. |
| Name | Required | Description |
|---|---|---|
| history | Yes | Matching requests, newest first. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes safety, but the description adds a useful behavioral detail: 'Credentials are already blanked.' It also specifies ordering and returned fields, though the output schema covers those. It does not mention pagination limits or retention beyond what the schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences. The first front-loads what the tool returns and its ordering; the second states the use case. No redundant or vague filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich input schema, output schema, and readOnlyHint annotation, the description covers purpose, usage, ordering, and credential handling. A minor gap is the lack of differentiation from get_history_entry, but the core information needed to call the tool is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all six optional parameters. The description adds no parameter syntax or usage beyond what the schema already provides, fitting the baseline of 3 when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool returns recent requests from shared history, with ordering (newest first) and the fields returned (who, method, URL, status, time). This is a clear verb+resource, but it does not explicitly distinguish itself from the sibling get_history_entry, which likely returns a single history entry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit usage context: 'Use it to see what the user tried, or to check what was sent earlier.' However, it does not name alternatives or state when not to use this tool, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One history entry in full: when it was sent, the status and time, and the request as sent (credentials blanked, {{placeholders}} kept, so it can be re-sent or saved). The response body is not stored.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | A history id, from get_history. |
| Name | Required | Description |
|---|---|---|
| item | Yes | |
| request | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnlyHint annotation by disclosing exactly what the entry contains: credentials are blanked, {{placeholders}} are preserved (enabling re-send/save), and the response body is NOT stored. The credential-blanking and non-persistence notes are precisely the behavioral traits an agent must know before re-using the output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with what the tool returns, with the parenthetical earning its place by explaining the redaction/placeholder behavior. No filler or restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only single-entry getter with an output schema, the description covers everything the agent needs: what is returned, what is redacted, and what is deliberately absent. Errors and pagination are irrelevant here, so nothing material is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single id parameter is documented in the schema as 'from get_history'. The description adds no format, range, or sourcing detail for id, so the baseline 3 for schema-carried parameters applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource and scope: 'One history entry in full', then enumerates the payload (sent time, status, request as sent). The singular 'One ... in full' contrasts cleanly with the sibling list tool get_history, so an agent can route between them without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: it hints at follow-on actions ('so it can be re-sent or saved') which maps to send_request/save_request, but it never says when to prefer this over get_history or what prerequisite (a valid history id) it needs. Adequate but no explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One saved request in full: method, URL, headers, body, and the {{variables}} it needs.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The name of a variable an agent set, or of a saved request. |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| body | No | |
| group | No | The group a saved request is filed under (`Jira`, `Jira/Issues`). |
| method | Yes | |
| headers | Yes | |
| options | No | What a saved request carries besides its form: `timeout_secs`, `follow_redirects`, `insecure_tls` and `select`. They apply when it is sent by name, unless the call gives its own. |
| saved_id | No | Set when saved under `save_as`; it now shows in Plunger's Saved list. |
| body_type | Yes | none, json, form-data or raw. |
| not_saved | No | Fields of the call that a saved request does not keep (only said when there are some). |
| form_fields | No | multipart -F fields: "name=value" or "name=@file". |
| variables_used | Yes | {{variables}} the request uses. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds real value beyond that by disclosing the payload shape (method, URL, headers, body) and flagging the {{variables}} dependency, telling the agent the request may require variables to be resolved first.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that leads with the scope ('One saved request') and then enumerates the returned fields. No filler, no restatement of the tool name or title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read with annotations covering safety and an output schema covering return format, the description is nearly sufficient: it states scope, contents, and the variable dependency. Only the routing guidance versus sibling read tools is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter, and schema description coverage is 100%, so the schema already documents 'name' (including the notable dual meaning of variable name or saved request name). The description adds no syntax or format detail for the parameter, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb (get) plus resource (a saved request) and it enumerates exactly what is returned: method, URL, headers, body, and needed variables. The singular 'One saved request in full' implicitly contrasts with the sibling list_saved_requests, but no sibling is named explicitly, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent can infer this is the fetch-a-single-request tool because it returns one request 'in full'. There is no statement of when to prefer it over list_saved_requests, get_history_entry, or export_curl, and no prerequisites given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse a curl command into a Plunger request without sending it: method, URL, headers, body and the
{{variables}} it uses. Use it to check what a curl command would do, or with save_as to keep it in the
user's Saved list so it can be sent later with send_request by name.
| Name | Required | Description | Default |
|---|---|---|---|
| curl | Yes | The full curl command, e.g. "curl -X POST https://api.example.com/items -H 'Content-Type: application/json' -d '{...}'". | |
| save_as | No | Also save it in Plunger's Saved list under this name. |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| body | No | |
| group | No | The group a saved request is filed under (`Jira`, `Jira/Issues`). |
| method | Yes | |
| headers | Yes | |
| options | No | What a saved request carries besides its form: `timeout_secs`, `follow_redirects`, `insecure_tls` and `select`. They apply when it is sent by name, unless the call gives its own. |
| saved_id | No | Set when saved under `save_as`; it now shows in Plunger's Saved list. |
| body_type | Yes | none, json, form-data or raw. |
| not_saved | No | Fields of the call that a saved request does not keep (only said when there are some). |
| form_fields | No | multipart -F fields: "name=value" or "name=@file". |
| variables_used | Yes | {{variables}} the request uses. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only supply a title, so the description carries the behavioral burden, and it does key work: 'without sending it' tells the agent this is a non-transmitting parse, and save_as is disclosed as a persistent side effect on the user's Saved list. It stops short of covering failure behavior for malformed curl input or how variables are substituted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action and the critical 'without sending it' constraint, followed by the optional save flow. No filler and no repetition of the tool name or title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation, and the description fully covers the parse-and-optionally-save workflow plus the downstream send_request path. Remaining minor gaps, such as validation errors on bad input or variable handling, are not critical for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: it names the fields extracted from the curl string and explains that save_as makes the parsed request retrievable later via send_request by name, which the schema's one-line description does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (parse) and resource (curl command) and enumerates the output it produces: method, URL, headers, body, and the {{variables}} used. It also implicitly distinguishes itself from the export_curl sibling by being the import direction, so an agent can route correctly without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives two concrete use cases ('check what a curl command would do' and 'keep it in the Saved list' via save_as) and names the follow-on tool, send_request by name, that consumes the saved result. It does not spell out a when-not or contrast with export_curl, so it falls just short of fully explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the requests the user saved in Plunger, by name, with method, URL, headers and the {{variables}} each needs. Call this before building a request from scratch: the user may already have the exact call set up.
| Name | Required | Description | Default |
|---|---|---|---|
| group | No | Only the ones in this group, or under it ("Jira" includes "Jira/Issues"). |
| Name | Required | Description |
|---|---|---|
| requests | Yes | The saved requests, by name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds that results are returned by name along with method/URL/headers/variables, which is useful framing, but it discloses no behavioral traits beyond that (no pagination, no ordering, no depth behavior for nested groups) — though the output schema carries much of that burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: the first declares what is returned, the second front-loads the actionable trigger. No filler, nothing repeated from structured fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only single-optional-param list tool with an output schema, the description covers purpose, trigger, and the shape of results. It omits only the group-filtering capability, which the schema already handles, so an agent has essentially everything it needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single 'group' parameter is fully documented in the schema, including its hierarchical matching semantics. The description adds nothing about the group filter or its default, making this the baseline 3 where the schema does the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List the requests the user saved in Plunger') and even enumerates the returned fields (name, method, URL, headers, variables). It is distinguishable from get_saved_request and list_variables/list_workflows by the resource it targets, though it never names a sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete when-to-use guidance: 'Call this before building a request from scratch: the user may already have the exact call set up.' That is a clear situational trigger, but there is no when-not guidance or explicit alternative named among the many lookup siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the {{variables}} defined in Plunger. Secret variables are listed by name only (their values are never returned); use them in a request as {{name}} and Plunger fills them in.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| built_in | Yes | Always available: {{$uuid}}, {{$timestamp}}, {{$randomInt}}, and {{$env:NAME}} (an environment variable, read when the request is sent). |
| problems | No | Problems reading remembered secrets, if any. |
| variables | Yes | |
| saved_bearer_available | Yes | True when a Bearer token is saved in Plunger (send with use_saved_bearer). Its value is never shown. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true; the description adds genuinely useful behavior beyond that: secret variables are returned by name only and their values are never exposed. It does not describe permissions/auth needs or the return shape, but the key security caveat an agent needs is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, followed immediately by the one caveat that matters (secret values hidden). Every clause earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be explained, and a zero-parameter read-only listing tool needs little else. The description covers the non-obvious secret-handling behavior, leaving nothing an agent must know before calling it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4. The description adds the {{name}} interpolation convention, which is context rather than parameter documentation, and nothing is missing because there are no inputs to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('List') and resource ('{{variables}} defined in Plunger'), and the note about secret variables sharpens the scope. No sibling tool (list_saved_requests, list_workflows, get_history) operates on variables, so the resource alone disambiguates it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how variables are consumed in requests ('use them in a request as {{name}}'), but that is about the variables, not about when to invoke this tool. There is no guidance on when to list vs. set_variable/delete_variable, and no prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the saved workflows with their steps.
| Name | Required | Description | Default |
|---|---|---|---|
| group | No | Only the ones in this group, or under it ("Jira" includes "Jira/Issues"). |
| Name | Required | Description |
|---|---|---|
| workflows | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds one useful behavioral detail beyond that — results include each workflow's steps — but says nothing about pagination, ordering, or filtering behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single ten-word sentence with no filler, and the core purpose is front-loaded. Nothing to trim.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described, and the tool is a simple read-only list with one optional filter. The main omission is usage context and any hint that 'group' scopes the results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the single optional 'group' parameter, including its hierarchical include semantics. The description contributes no additional parameter context, which is the expected baseline here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List the saved workflows') and even describes the payload scope ('with their steps'). It reads clearly against siblings like list_saved_requests and list_variables, though it never explicitly distinguishes itself from them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool, when not to, or which alternative (e.g. get_saved_request, run_workflow) to reach for. The agent must infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a saved workflow: its requests are sent in order, values are carried from one response to the next (never shown if secret), and it stops at the first step that fails. Returns each step's status and the variables it set, plus the last response in full.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The workflow's name (see list_workflows). | |
| cleanup | No | Remove the variables this run stored once it is done (the later steps have used them by then), so runs do not leave values behind. Values extracted with `scope: "run"` are never stored at all. | |
| variables | No | {{variable}} values for every step of this run. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | True when every step passed. |
| steps | Yes | |
| workflow | Yes | |
| cancelled | No | True when the run was cancelled before it finished. |
| steps_run | Yes | How many steps ran (a failed step stops the rest). |
| cleaned_up | No | With `cleanup`: the variables the run stored and then removed. |
| last_response | No | The last response that came back, in full. |
| stopped_early | No | True when a `stop_if` ended the run before the last step. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only supply openWorldHint and a title, so the description carries the real behavioral load and does so well: in-order execution, value propagation between steps, secrets never surfaced, fail-fast on first error, and what is returned. These are exactly the traits an agent needs to predict outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but front-loaded: the execution model is stated first, then the return contract. It packs semantics into relatively few words with no filler, though the single long sentence with parenthetical asides is slightly heavy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be explained, yet the description still summarizes them concisely. Execution behavior is well covered; only prerequisites (auth/environment context) go unmentioned, a minor gap for a tool with this much disclosure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so name, cleanup, and variables are already fully documented in the schema, including the cleanup trade-off and the scope:'run' exception. The description adds nothing parameter-specific beyond a passing mention of returned variables, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource: 'Run a saved workflow'. It immediately distinguishes itself from send_request (single request) and list_workflows by describing the ordered multi-step execution model. An agent can tell what this does without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: 'a saved workflow' signals you need a name from list_workflows, and the fail-fast semantics help an agent judge fit. However, it never explicitly contrasts with send_request or explains when running a workflow is preferable to sending individual requests.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a request in the user's Saved list without sending it, so it can be re-run by name with send_request
(saved_request). Describe it like send_request. {{placeholders}} are kept as written, including in
Authorization headers. An existing name is refused unless overwrite is true, which replaces it, so a
mistake can be fixed.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Full URL. May use {{variables}}, e.g. "{{base}}/users/{{id}}". Required unless saved_request is given. | |
| body | No | A raw text body, sent as-is. Use instead of `json` for non-JSON payloads. | |
| form | No | Form fields, sent as application/x-www-form-urlencoded. | |
| json | No | A JSON body (any JSON value). Sent with Content-Type: application/json. | |
| name | Yes | The name to save it under, shown in Plunger's Saved list. | |
| group | No | File it under a group, such as "Jira" or "Jira/Issues". Left out, a new request has no group and a replaced one keeps its group; an empty string takes it out of its group. | |
| method | No | GET, POST, PUT, PATCH, DELETE, HEAD or OPTIONS. Defaults to GET. | |
| select | No | Return only these values instead of the whole body, e.g. ["$.data[0].id", "header:Location", "status"]. Saves context on a big response; `json`, `body` and the headers are then left out. `[?(@.name=='Done')]` keeps the array items whose field equals the value. If every path fails the whole response is returned with the reasons; if only some fail, the values that could be read come back and `problems` names the rest. | |
| extract | No | Keep values from the response as variables for later requests, e.g. [{"name": "token", "from": "json:$.access_token"}]. `from` is `json:$.path`, `header:Name` or `status`. A name like token or password is kept as a hidden secret. | |
| headers | No | Request headers, e.g. {"Accept": "application/json", "Authorization": "Bearer {{token}}"}. A list of {"name", "value"} objects or "Name: value" strings is accepted too. | |
| overwrite | No | Replace a saved request that already has this name (otherwise an existing name is refused). | |
| variables | No | Extra or overriding {{variable}} values for this request only. The user's own variables (including secrets) are already available by name; you don't need their values. | |
| insecure_tls | No | Skip TLS certificate checks, e.g. for a local server with a self-signed certificate. | |
| timeout_secs | No | Seconds to wait for a response (1-600). Defaults to the user's setting (20). | |
| saved_request | No | Send a saved request by name (see list_saved_requests). Any other field given here overrides that part of it. | |
| max_body_chars | No | Longest body to return, in characters (default 50000). A longer JSON body comes back as an outline of its shape (keys, types, array lengths) with a hint to use `select`; a longer text body is cut and marked with `body_cut_from_chars`. | |
| include_headers | No | Which response headers to return: `all`, `none`, or `relevant` (location, link, retry-after, content-type, content-disposition, etag, rate-limit headers and set-cookie names). Left out: `all`, or `none` when `select` is used. | |
| follow_redirects | No | Follow redirects (default true). Set false to receive the redirect response itself and read its `Location` header. | |
| use_saved_bearer | No | Attach the Bearer token the user saved in Plunger. Off by default: only turn it on for a host the user asked you to call with their credentials. |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| body | No | |
| group | No | The group a saved request is filed under (`Jira`, `Jira/Issues`). |
| method | Yes | |
| headers | Yes | |
| options | No | What a saved request carries besides its form: `timeout_secs`, `follow_redirects`, `insecure_tls` and `select`. They apply when it is sent by name, unless the call gives its own. |
| saved_id | No | Set when saved under `save_as`; it now shows in Plunger's Saved list. |
| body_type | Yes | none, json, form-data or raw. |
| not_saved | No | Fields of the call that a saved request does not keep (only said when there are some). |
| form_fields | No | multipart -F fields: "name=value" or "name=@file". |
| variables_used | Yes | {{variables}} the request uses. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare idempotentHint and destructiveHint; the description adds real behavior beyond them – nothing is sent, `{{placeholders}}` are preserved verbatim even inside Authorization headers, and name collisions are refused unless overwrite replaces the entry. It does not discuss where the saved item lives or whether saving has side effects on existing variables.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tight sentences with no filler; the core action and the no-send constraint are front-loaded, followed by the naming and overwrite rules. Dense but each sentence carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 19-parameter save tool with an output schema and full schema coverage, the description covers the distinguishing behaviors (no send, placeholder handling, name collision). It stops short of describing interaction with groups or variables, but nothing essential to calling it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% across 19 parameters, so the schema already carries the per-parameter burden and the baseline is 3. The description adds the placeholder-preservation rule (which the schema only hints at via the {{token}} header example) and reiterates the overwrite rule, but supplies no syntax guidance for the many request-building fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Save a request in the user's Saved list') plus the crucial negative scope ('without sending it'), which separates it from the sibling send_request. An agent can identify this tool without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent: save here so it can later be re-run by name via send_request's `saved_request` parameter, and notes that an existing name is refused unless `overwrite` is true. Clear context and a named alternative, though it does not state when a request should not be saved at all (e.g. one-off calls).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a workflow: an ordered list of requests where a later one can use values from an earlier response.
Each step is described like send_request, plus extract (for example {name: "token", from: "json:$.access_token"},
which keeps the value as {{token}} for the steps after it, hidden if it looks like a credential) and
expect_status. Use it for logins, create-then-fetch flows and any sequence you will repeat.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The workflow's name. | |
| group | No | File it under a group, such as "Jira". Left out, a replaced workflow keeps its group; an empty string takes it out of its group. | |
| steps | Yes | The requests, in order. Each is like send_request, plus `extract` (values to keep for later steps) and `expect_status` (default: any 2xx). | |
| overwrite | No | Replace a workflow that already has this name. |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| group | No | The group it is filed under (`Jira`, `Jira/Issues`), when it has one. |
| steps | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, and the description adds genuinely extra behavior: extracted values are kept as {{token}}-style variables and are hidden when they look like credentials. That credential-masking disclosure is not derivable from the annotations and is important for safe handling, though auth/token-attachment behavior is left to the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences: the definition comes first, then the step composition rule, then the use cases. Front-loaded and largely waste-free, with only mild overlap against the schema's Step description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value explanation is unnecessary, and annotations cover the safety profile. The description supplies the conceptual model an agent needs (ordered steps, extraction, credential hiding) but never mentions the run_workflow/list_workflows counterpart, leaving a small gap in the lifecycle picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the Step/Extract sub-schemas are highly detailed, so the schema already carries the parameter burden. The description restates `extract` and `expect_status` with an example, but adds little beyond what the schema's own property descriptions say, making the baseline 3 correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Save a workflow') and immediately defines the artifact as an ordered list of requests where later steps can consume earlier values. It also anchors the step shape to the sibling send_request, so an agent can distinguish the composition tool from the single-request tool without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The closing sentence gives concrete triggering scenarios ('logins, create-then-fetch flows and any sequence you will repeat'), which is real when-to-use guidance. It stops short of naming alternatives or exclusions (e.g., when to use run_workflow vs. save_workflow, or send_request for one-offs), so it is clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send an HTTP request through Plunger and get back status, timing, size, headers and the parsed JSON body.
Use this instead of curl for API calls: {{variables}} (including the user's secrets, by name) are filled in
for you, an undefined {{variable}} makes the request fail safely instead of sending the placeholder, secret
values are masked in the result, and the request is recorded in the history the user sees in Plunger.
Send a saved request by name with saved_request, or describe one with method, url, headers and a body.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Full URL. May use {{variables}}, e.g. "{{base}}/users/{{id}}". Required unless saved_request is given. | |
| body | No | A raw text body, sent as-is. Use instead of `json` for non-JSON payloads. | |
| form | No | Form fields, sent as application/x-www-form-urlencoded. | |
| json | No | A JSON body (any JSON value). Sent with Content-Type: application/json. | |
| method | No | GET, POST, PUT, PATCH, DELETE, HEAD or OPTIONS. Defaults to GET. | |
| select | No | Return only these values instead of the whole body, e.g. ["$.data[0].id", "header:Location", "status"]. Saves context on a big response; `json`, `body` and the headers are then left out. `[?(@.name=='Done')]` keeps the array items whose field equals the value. If every path fails the whole response is returned with the reasons; if only some fail, the values that could be read come back and `problems` names the rest. | |
| extract | No | Keep values from the response as variables for later requests, e.g. [{"name": "token", "from": "json:$.access_token"}]. `from` is `json:$.path`, `header:Name` or `status`. A name like token or password is kept as a hidden secret. | |
| headers | No | Request headers, e.g. {"Accept": "application/json", "Authorization": "Bearer {{token}}"}. A list of {"name", "value"} objects or "Name: value" strings is accepted too. | |
| variables | No | Extra or overriding {{variable}} values for this request only. The user's own variables (including secrets) are already available by name; you don't need their values. | |
| insecure_tls | No | Skip TLS certificate checks, e.g. for a local server with a self-signed certificate. | |
| timeout_secs | No | Seconds to wait for a response (1-600). Defaults to the user's setting (20). | |
| saved_request | No | Send a saved request by name (see list_saved_requests). Any other field given here overrides that part of it. | |
| max_body_chars | No | Longest body to return, in characters (default 50000). A longer JSON body comes back as an outline of its shape (keys, types, array lengths) with a hint to use `select`; a longer text body is cut and marked with `body_cut_from_chars`. | |
| include_headers | No | Which response headers to return: `all`, `none`, or `relevant` (location, link, retry-after, content-type, content-disposition, etag, rate-limit headers and set-cookie names). Left out: `all`, or `none` when `select` is used. | |
| follow_redirects | No | Follow redirects (default true). Set false to receive the redirect response itself and read its `Location` header. | |
| use_saved_bearer | No | Attach the Bearer token the user saved in Plunger. Off by default: only turn it on for a host the user asked you to call with their credentials. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | True for a 2xx status. |
| body | No | The body as text, when it is not JSON or is too long to return whole. |
| hint | No | What to do next, when the response was too big to return whole. |
| json | No | The body is valid JSON, parsed. Absent for non-JSON bodies, or when the JSON is longer than the size limit (then it is in `body`, cut short). |
| binary | No | The body isn't text, so it is not included; see `size_bytes` and the Content-Type header. |
| sha256 | No | For a binary body: its SHA-256, so the agent can check it without receiving the bytes. |
| status | Yes | |
| headers | Yes | |
| outline | No | A JSON body too long to return whole: its shape (keys, types, array lengths, one example each) instead of cut-off text. Ask for the values you need with `select`. |
| request | Yes | |
| ttfb_ms | No | Milliseconds until the response headers arrived. |
| problems | No | Things that did not work in `select` or `extract`, such as a path that is not in the response. |
| redacted | No | Secrets whose values appeared in the response and were replaced with `[redacted:<name>]`. Names only, never values. |
| selected | No | With `select`: just the values asked for, by the path given. `json` and `body` are then left out. |
| body_file | No | With `--out` on the command line: the file the whole body was written to. |
| final_url | No | Where the request ended up, when it was redirected. |
| redirects | No | The redirects that were followed, in order (absent when there were none). |
| elapsed_ms | Yes | |
| size_bytes | Yes | Bytes of body received. |
| status_text | Yes | |
| detected_type | No | For a binary body: what its first bytes say it is (`png`, `pdf`, `zip`, ...), when known. |
| variables_set | No | With `extract`: the variables that were set from this response (secrets by name only). |
| truncated_at_10mb | Yes | The response exceeded Plunger's 10 MB read limit; only the first 10 MB were read. |
| body_cut_from_chars | No | The body was longer than the limit and has been cut; this is its full length in characters. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only carry openWorldHint=true, so the description does the heavy lifting and delivers real behavioral context: variables are substituted, undefined variables fail safely rather than sending placeholders, secret values are masked in the result, and every request is recorded in user-visible history. These are side effects and safety properties an agent could not infer from the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the outcome, then the curl-replacement rationale, then the saved-request alternative. Dense but every sentence carries distinct information; minor redundancy with the schema's own variable description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 16-parameter tool with an output schema, the description supplies the missing behavioral layer (variable substitution, secret masking, history logging, saved-request routing) while leaving return shape and per-parameter detail to structured fields. Nothing essential for correct invocation is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each of the 16 parameters is documented in the schema, so the baseline is 3. The description still adds cross-cutting meaning beyond the schema — that `{{variables}}` resolve against the user's stored values and secrets by name, and that an undefined variable fails safely — which is not captured per-parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Send an HTTP request through Plunger') plus the exact return payload (status, timing, size, headers, parsed JSON body). This clearly separates it from siblings like export_curl, import_curl, and save_request.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this instead of curl for API calls' and explains how to route between an inline request and a named one via `saved_request`. It lacks an explicit when-not-to-use (e.g. that export_curl/import_curl handle curl conversion), but the primary alternative is named and conditioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
File a saved request or a workflow under a group, such as "Jira" or "Jira/Issues", without touching the
request or workflow itself. An empty group takes it out of its group. Use it to tidy the Saved list.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | `request` (a saved request) or `workflow`. | |
| name | Yes | The name of the saved request or workflow. | |
| group | Yes | The group to file it under, such as "Jira" or "Jira/Issues". An empty string takes it out of its group. |
| Name | Required | Description |
|---|---|---|
| kind | Yes | `request` or `workflow`. |
| name | Yes | |
| group | No | The group it is in now; absent when it was taken out of its group. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, so the bar is lower, but the description adds real value: it states the operation does not touch the request/workflow content and that an empty group un-assigns it, which is the key reversibility behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the action and target, with no filler. The reassignment and removal semantics are captured without repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need no explanation, and the description covers the non-destructive nature and the un-grouping case. It omits only edge behavior such as what happens to a group with no remaining members.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters are already documented. The description reinforces the empty-string behavior of `group` and gives example values, but adds little the schema does not already say — baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('file ... under a group') and names the exact resources affected — a saved request or a workflow — and clarifies it does not modify the resource itself. It is unambiguous, but it never differentiates itself from siblings like save_request or set_variable by name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use it to tidy the Saved list' implies the organizing context but gives no explicit when/when-not or alternative tools. The inclusion of the empty-group removal case is helpful, yet the agent must infer usage conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a variable that later requests use as {{name}}, for example a token you read from a login response. It persists between calls and runs and is shared with the Plunger window, the CLI and other agents. A secret (or a credential-looking name such as token or api_key) is kept in the system credential store and masked in results. A variable the user defined in the window cannot be changed.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The name, used in requests as {{name}}. Letters, digits, _ - and . only, at most 64 characters. | |
| value | Yes | The value. For a secret it is stored in the system credential store and never returned. | |
| secret | No | Keep it as a secret: masked in results, and never written to a file. A name that looks like a credential (token, password, api_key, secret...) is always secret. |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| value | No | Only for non-secret variables. |
| secret | Yes | Secret values are masked in the window and never returned here. |
| source | Yes | `window` for a variable the user defined, `agent` for one set from the CLI or MCP. |
| has_value | Yes | |
| remembered | Yes | Kept in the operating system's credential store between runs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations' idempotentHint/destructiveHint, the description discloses scope of persistence (across calls and runs), cross-surface sharing (Plunger window, CLI, other agents), secret handling (system credential store, masked in results, never written to a file), and the immutable user-defined-variable case. That is exactly the operational context annotations cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with the action and the {{name}} reference, then escalating to persistence, sharing and secret semantics. Dense but every sentence carries distinct information; slightly more detail than a minimally lean version.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and 100% parameter coverage, the description need not explain return values and instead covers the behaviors that matter: persistence, sharing, masking, and the one failure mode. Nothing an agent needs before calling is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains name, value and the secret flag in detail. The description restates the secret/credential-name behavior for parameters but adds no syntax or format detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence gives a specific verb and resource ('Set a variable') plus the exact consumption syntax {{name}}, which immediately distinguishes it from list_variables and delete_variable. The example (a token read from a login response) anchors the purpose concretely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It supplies a motivating use case ('a token you read from a login response') and a genuine when-not constraint ('A variable the user defined in the window cannot be changed'), so an agent knows a case where the call will fail. It does not, however, point at siblings such as list_variables for checking existing definitions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0delete_saved_requestdelete_variabledelete_workflowexport_curlget_historyget_history_entryget_saved_requestimport_curllist_saved_requestslist_variableslist_workflowsrun_workflowsave_requestsave_workflowsend_requestset_groupset_variableScored across 17 tools
Each tool targets a distinct resource+action: send_request vs run_workflow vs export_curl vs import_curl are clearly separated, and list_* vs get_* vs delete_* are unambiguous. The set_group tool is the only mildly unusual one, but its description is explicit and it doesn't collide with any other tool.
Every tool follows a consistent snake_case verb_noun pattern (list_saved_requests, get_history_entry, save_workflow, delete_variable, etc.). No mixing of conventions or vague verbs; the pattern is fully predictable.
17 tools is on the heavy side but each maps to a real operation across four sub-domains (requests, workflows, variables, history) plus curl interop. It is slightly more than ideal but nothing feels redundant.
Requests, workflows, variables and history all have create/read/list/delete coverage, plus import/export and execution. Minor gaps exist: no explicit update/rename for saved requests or workflows (save_request only offers overwrite), and no way to edit an existing workflow's steps.
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
Local Commander connects ChatGPT, Claude, Cursor and other MCP clients to Windows 11 computers you own. Your AI can read approved project files and Git state, run the checks and commands you authorize, and check local services. Your workspace at localcmd.app shows which computer ran each request and how it ended. Once you approve a computer and connect your AI, it can do what your Windows account can do; you can limit it to folders, block commands or switch it off at any time. Free on up to 5 computers; the Team pack adds 10 more for $15 a month.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
