plunger

Official

Overview Schema Source Related Servers Discussions Admin

send_request

Send an HTTP request with variables and secrets filled in safely, returning status, timing, size, headers, and the parsed JSON body. Use it instead of curl for API calls.

Instructions

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.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "send_request"
  }
}

Input Schema

Name	Required	Description
`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. `jq:<program>` reshapes the whole body with a jq program (e.g. "jq:[.items[] \| {id, name}]"; pure, no files or network; several outputs come back as an array). On a 4xx or 5xx the start of the body is returned as `error_body`, so the reason is not hidden. 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.

Output Schema

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
`error_body`	No	The first few hundred characters of the body of a 4xx or 5xx answer, when `select` left the body out: the reason is usually in it ("body is not JSON" tells nothing, the 17 bytes it was do).
`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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.8.1Nov 5, 2026

changedInput schema / properties / select / description

Previous value: -"Return only these values instead of the whole body, e.g. [\"$.data[0].id\", \"header:Location\", \"status\"].\nSaves context on a big response; `json`, `body` and the headers are then left out. `[?(@.name=='Done')]`\nkeeps 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."New value: +"Return only these values instead of the whole body, e.g. [\"$.data[0].id\", \"header:Location\", \"status\"].\nSaves context on a big response; `json`, `body` and the headers are then left out. `[?(@.name=='Done')]`\nkeeps the array items whose field equals the value. `jq:<program>` reshapes the whole body with a jq program\n(e.g. \"jq:[.items[] | {id, name}]\"; pure, no files or network; several outputs come back as an array). On a 4xx or\n5xx the start of the body is returned as `error_body`, so the reason is not hidden. 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."

addedOutput schema / properties / error_body

Added value: +{
+  "description": "The first few hundred characters of the body of a 4xx or 5xx answer, when `select` left the body out:\nthe reason is usually in it (\"body is not JSON\" tells nothing, the 17 bytes it was do).",
+  "type": [
+    "string",
+    "null"
+  ]
+}

First observedv0.1.0Oct 20, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only supply openWorldHint=true, so the description carries the behavioral load and does so well: {{variables}} and user secrets are resolved by name, an undefined variable fails safely rather than sending the placeholder, secret values are masked in the result, and every call is written to the history the user sees. That is real pre-call context (data exposure, failure mode, side effect of history recording) that the annotations do not convey.

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

Conciseness5/5

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

Four sentences, front-loaded with the action and result, then the differentiator versus curl, then the saved-request routing. No filler or marketing language; each sentence adds a distinct decision-relevant fact.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 16-parameter open-world HTTP tool this is strong: the safety model (variable substitution, fail-safe, masking, history), and the saved-request alternative are all covered, and an output schema exists so return values need not be restated. The gap is that no description-level hint is given about response-size control or extraction, which are the parameters most likely to be misused on a large response.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline would be 3; the description still earns above baseline by explaining that variables are resolved automatically and that 'you don't need their values', and by clarifying that an unresolved placeholder aborts the request. It does not itself explain the more complex knobs (select, extract, max_body_chars, include_headers), leaving those entirely to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb+resource ('Send an HTTP request through Plunger') and immediately names the response payload (status, timing, size, headers, parsed JSON body). It also distinguishes itself from the obvious alternative by saying 'Use this instead of curl for API calls', and the closing sentence separates the describe-a-request mode from the 'saved_request' mode used by get_saved_request/list_saved_requests.

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

Usage Guidelines5/5

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

Explicit when-to-use ('instead of curl for API calls'), an explicit routing rule to a sibling ('Send a saved request by name with `saved_request`'), and an implied boundary against list_saved_requests (referenced in the schema). It also states a safety condition for credential use ('only turn it on for a host the user asked you to call') in the schema, so an agent has both selection and exclusion guidance.

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

Deploy Server