Skip to main content
Glama

Send request

send_request
Destructive

Send a saved or ad hoc HTTP request with variables, auth and cookies resolved automatically, so secrets stay out of commands and logins persist between calls. Returns status, test results and body.

Instructions

Send a saved request (give request) or an ad hoc one (give url). Prefer this over curl in a shell: Gostman fills in {{variables}}, auth, cookies and OAuth tokens itself, so no secret has to appear in the command or in the result, and a login made by one call is still in effect for the next. Saved requests also run their scripts, extraction rules and assertions. Returns two parts: a JSON summary (status, duration, size, content type, the address as sent in resolvedUrl with variable values shown as {{name}}, test results, script console output, names of cookies and variables that were set, and body.bytes, body.returnedBytes, body.truncated) followed by the response body as text. When body.truncated is true, narrow the answer with select or raise max_body_bytes. failed is true when the request could not be sent or a test did not pass. unresolved lists placeholders that have no value; withheld lists secrets that were not filled in because none of the developer's requests sends them to this address.

Input Schema

NameRequiredDescriptionDefault
urlNoAd hoc only: the address to call. May contain {{variables}}, for example {{baseUrl}}/users/1.
bodyNoAd hoc only: the request body as text. For body_type form, a JSON object of field names and values.
methodNoAd hoc only. Defaults to GET.
selectNoA JSONPath applied to a JSON response body, such as $.items[0].id or $.data[*].name. Only the match is returned, which keeps large responses small.
headersNoAd hoc only: header names and values. Reference credentials as variables, for example {"Authorization": "Bearer {{token}}"}.
requestNoThe request's id, or its name. A name that is used twice needs its folder path in front, as list_requests shows it, such as auth/Login.
body_typeNoAd hoc only. Defaults to json when the body parses as JSON, otherwise text.
variablesNoVariables to set before sending, such as {"id": "42"}. They win over the environment and the request's own variables, and stay set until set_environment.
max_body_bytesNoHow much of the body to return. Defaults to 8192.
include_headersNoAlso return the response headers. Credential headers stay hidden.

Output Schema

NameRequiredDescriptionDefault
urlNo
bodyNo
hintNo
logsNo
errorNo
testsNo
failedNo
methodNo
statusNo
headersNo
requestNo
skippedNo
withheldNo
sizeBytesNo
cookiesSetNo
durationMsNo
statusCodeNo
unresolvedNo
contentTypeNo
resolvedUrlNo
variablesSetNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.7.19

TDQS

A4.5/5.0
Behavior5/5

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

Goes well beyond the annotations (openWorld, destructive, non-idempotent) by explaining that secrets never appear in the command or result, that logins persist across calls, and that saved requests run scripts, extraction rules and assertions. It also details the returned JSON summary fields, truncation semantics, and the meaning of failed/unresolved/withheld.

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?

Front-loaded with purpose and the curl alternative before the return-value details. It is dense but nearly every sentence carries actionable information; the long list of summary fields is the main reason it isn't tighter.

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?

Given 10 parameters and a destructive/openWorld profile, it covers side-effect-relevant behavior (persisted auth, withheld secrets, failed/unresolved/withheld signals) and even explains output despite an output schema existing. It doesn't explicitly warn that sent requests can mutate remote server state, which would fully round out a destructive tool.

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 schema already documents each parameter, but the description adds cross-parameter guidance: use select or raise max_body_bytes only when body.truncated is true. That connection between truncation and the narrowing parameters is meaning the schema alone doesn't give.

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 a saved request ... or an ad hoc one") and immediately disambiguates the two modes by naming which parameter selects each. It also distinguishes itself from the obvious external alternative, curl, so an agent knows exactly what this tool is for.

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 to prefer this over curl because variables/auth/cookies/OAuth are filled in and the login persists across calls, and gives the saved-vs-ad-hoc selection rule. It stops short of naming sibling alternatives like run_folder or last_response, so the boundary against those tools is not stated.

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