Skip to main content
Glama
metamug

plunger

Official

send_request

Send HTTP requests for API calls with {{variables}} filled in, secrets masked, and undefined variables failing safely; get status, timing, size, headers, and parsed JSON back.

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoFull URL. May use {{variables}}, e.g. "{{base}}/users/{{id}}". Required unless saved_request is given.
bodyNoA raw text body, sent as-is. Use instead of `json` for non-JSON payloads.
formNoForm fields, sent as application/x-www-form-urlencoded.
jsonNoA JSON body (any JSON value). Sent with Content-Type: application/json.
methodNoGET, POST, PUT, PATCH, DELETE, HEAD or OPTIONS. Defaults to GET.
selectNoReturn 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.
extractNoKeep 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.
headersNoRequest headers, e.g. {"Accept": "application/json", "Authorization": "Bearer {{token}}"}. A list of {"name", "value"} objects or "Name: value" strings is accepted too.
variablesNoExtra 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_tlsNoSkip TLS certificate checks, e.g. for a local server with a self-signed certificate.
timeout_secsNoSeconds to wait for a response (1-600). Defaults to the user's setting (20).
saved_requestNoSend a saved request by name (see list_saved_requests). Any other field given here overrides that part of it.
max_body_charsNoLongest 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_headersNoWhich 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_redirectsNoFollow redirects (default true). Set false to receive the redirect response itself and read its `Location` header.
use_saved_bearerNoAttach 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

TableJSON Schema
NameRequiredDescriptionDefault
okYesTrue for a 2xx status.
bodyNoThe body as text, when it is not JSON or is too long to return whole.
hintNoWhat to do next, when the response was too big to return whole.
jsonNoThe 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).
binaryNoThe body isn't text, so it is not included; see `size_bytes` and the Content-Type header.
sha256NoFor a binary body: its SHA-256, so the agent can check it without receiving the bytes.
statusYes
headersYes
outlineNoA 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`.
requestYes
ttfb_msNoMilliseconds until the response headers arrived.
problemsNoThings that did not work in `select` or `extract`, such as a path that is not in the response.
redactedNoSecrets whose values appeared in the response and were replaced with `[redacted:<name>]`. Names only, never values.
selectedNoWith `select`: just the values asked for, by the path given. `json` and `body` are then left out.
body_fileNoWith `--out` on the command line: the file the whole body was written to.
final_urlNoWhere the request ended up, when it was redirected.
redirectsNoThe redirects that were followed, in order (absent when there were none).
elapsed_msYes
size_bytesYesBytes of body received.
status_textYes
detected_typeNoFor a binary body: what its first bytes say it is (`png`, `pdf`, `zip`, ...), when known.
variables_setNoWith `extract`: the variables that were set from this response (secrets by name only).
truncated_at_10mbYesThe response exceeded Plunger's 10 MB read limit; only the first 10 MB were read.
body_cut_from_charsNoThe 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.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.