Skip to main content
Glama
stormhop

Kurlo

by stormhop
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Local

Create or change a saved request

save_request

Create or update saved HTTP and GraphQL requests in a Kurlo workspace, with variable-based environment values and no stored secrets.

Instructions

Create a saved HTTP or GraphQL request, or change one. Without request it creates a new one; with request (id or path) it changes that one, and only the fields you pass are changed. params, headers and form replace the whole list. Use {{variables}} for anything that differs per environment, such as {{baseUrl}}. Secrets are never written: auth tokens and passwords must be {{variable}} references. Test scripts are JavaScript with the Postman pm.* API, for example pm.test("status is 200", () => pm.response.to.have.status(200)).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoURL; may use {{variables}}. Required for a new request.
authNoAuthentication. Secret parts (token, password, value) must be {{variable}} references. Defaults to inherit, which uses the collection's auth.
bodyNoRequest body. JSON is stored as a JSON body, anything else as text, unless bodyType says otherwise.
formNoForm fields for a urlencoded or form (multipart) body. Replaces the existing list.
nameNoRequest name. Defaults to the method and path.
typeNoDefaults to http.
notesNoNotes shown with the request.
queryNoGraphQL query or mutation.
folderNoFolder path inside the collection, slash-separated, for example Users/Admin. An empty string moves the request to the top.
methodNoHTTP method (default GET). Ignored for GraphQL, which is always POST.
paramsNoQuery parameters. Replaces the existing list.
headersNoRequest headers. Replaces the existing list.
requestNoId or path (Collection/Folder/Name) of the request to change. Omit to create one.
bodyTypeNo
variablesNoGraphQL variables.
collectionNoCollection to create the request in, or to move it to. Optional when there is only one.
testScriptNoJavaScript run on the response; pm.test assertions become the request's tests.
preRequestScriptNoJavaScript run before the request is sent.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.4.1

TDQS

A4.1/5.0
Behavior5/5

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

Beyond the annotations, it discloses the surprising behaviors an agent must know: params/headers/form wholesale replacement, partial-update semantics for everything else, and the hard rule that secrets must be {{variable}} references rather than literals. It also states what testScript/preRequestScript actually are (JavaScript with the pm.* API), which 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.

Conciseness4/5

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

Front-loaded with create-vs-update, then replacement semantics, then constraints and script guidance — a sensible order with little waste. The inline pm.test example is illustrative but runs long for what it conveys.

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 an 18-parameter mutation with no output schema, the description covers mode selection, replacement behavior, variable/secret conventions, and script semantics. It stops short of saying what is returned (e.g. the saved request's id), which the agent would need to chain into run_request or send_request.

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

Parameters3/5

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

Schema coverage is 94%, so nearly every parameter is already self-documenting, and most description content (list replacement, url required for new requests, default GET) restates the schema. The genuine addition is the cross-cutting {{variables}} and secret-as-variable convention, which is useful but marginal against an already strong schema.

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 opening sentence gives a specific verb pair and resource: create or change a saved HTTP/GraphQL request. The word "saved" implicitly separates it from send_request and run_request, but no sibling is named, so the agent must infer the persistence distinction.

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?

It explicitly resolves the main ambiguity: omit `request` to create, pass an id or path to update, and only passed fields change. What's absent is routing advice against alternatives such as send_request or save_example when the agent is unsure whether to persist at all.

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