Skip to main content
Glama
stormhop

Kurlo

by stormhop
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Local

Send an HTTP request

send_request

Send a one-off HTTP request without saving it to the Kurlo workspace, resolving {{variables}} from the environment with per-call overrides.

Instructions

Send a one-off HTTP request that is not saved in the workspace. {{variables}} in the URL, headers and body are resolved from the environment.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesAbsolute URL; may use {{variables}}.
bodyNoRequest body. JSON is sent as application/json, anything else as text/plain, unless a Content-Type header says otherwise.
methodNoHTTP method (default GET).
headersNoRequest headers, as name to value.
variablesNoVariable overrides for this call, as name to value. They win over the environment.
environmentNoEnvironment name. Defaults to the one the server was started with.
maxBodyBytesNoMost bytes of the response body to return (default 65536, max 1048576).
browserOriginNoSend the call the way a browser on this page origin would, for example https://app.example.com: browser headers, the CORS preflight when one is needed, and the CORS error a browser would raise. Omit it and a saved request uses its own browser settings, if any.
browserCredentialsNoWith browserOrigin, make it a credentialed request (fetch credentials: include), which a wildcard Access-Control-Allow-Origin does not satisfy.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.4.1

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false and openWorldHint=true, so the agent knows this can make external, non-read-only calls. The description adds useful context that the request is not persisted and that {{variables}} are resolved from the environment, but it does not discuss side effects, authentication, redirects, or response truncation.

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?

Two tightly written sentences with no filler. The key constraint, that the request is one-off and unsaved, is front-loaded before the variable-resolution note.

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

Completeness3/5

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

For a 9-parameter, open-world HTTP tool with no output schema, the description is adequate but thin. The rich input schema covers parameters well, yet the description does not explain response behavior, error handling, or the safety implications of sending real external requests.

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 description coverage is 100%, so the schema carries most parameter detail, and the baseline would be 3. The description adds cross-cutting semantic value by explaining that {{variables}} in the URL, headers, and body are resolved from the environment, which the schema only partially states for the url field.

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

Purpose4/5

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

The description gives a specific verb and resource: sending a one-off HTTP request that is not saved in the workspace. This scope distinguishes it from saved-request tools, but it does not explicitly name a sibling such as run_request as the alternative.

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?

The phrase 'one-off HTTP request that is not saved in the workspace' clearly indicates the transient use case. It stops short of explicit when-not guidance or naming alternative tools for saved requests.

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

Deploy Server

Other Tools