Kurlo
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
| prompts | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_requestsA | List the saved requests in the workspace with their collection, folder, protocol, method and URL. The path or id of a request is what run_request and get_request take. |
| get_requestA | Show how a saved request is defined: method, URL, query parameters, headers, body, auth type, scripts, browser settings, and the saved example responses to compare a live response against. Credentials are not included. |
| list_environmentsA | List the workspace's environments and their variables. Secret values are hidden. |
| run_requestA | Send one saved HTTP or GraphQL request with its collection defaults, auth and scripts, and return the status, headers, body, timings and test results. |
| run_collectionA | Run the HTTP and GraphQL requests of a collection or folder in order, with their test scripts, and return a pass/fail summary per request. Realtime requests are skipped. Reports progress after each request when the call carries a progressToken. |
| send_requestA | 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. |
| list_historyA | List the requests the user recently sent from the Kurlo app on this machine, newest first, with status, timing and the saved request each came from. Use it when the user refers to something they just sent or saw in Kurlo, then get_history_entry to read one. |
| get_history_entryA | Show one request the user sent from the Kurlo app and the response they got: status, headers, body, errors, test results and script logs. Without entry it shows the last one sent, so "why did my last request fail?" needs no other input. Secrets are masked. |
| diagnose_last_failureA | Explain why a request sent from the Kurlo app failed. Without entry it takes the most recent request that got no response, a 4xx or 5xx status, or failing tests. Returns the status, error, failed tests, the {{variables}} nothing sets, how the response differs from the saved example, and hints for the likely cause. Secrets are masked. |
| create_collectionA | Create an empty collection in the workspace for save_request to put requests in. |
| save_requestA | 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)). |
| delete_requestA | Delete a saved request and its examples from the workspace. In a Git workspace the deletion shows up in the next commit and can be restored from history. |
| save_exampleA | Save an example response on a saved request. Kurlo's mock server serves examples, and live responses can be compared against them. Without status and body it saves the response of the last run_request of that request in this session; secrets and cookies are removed from it. With status and body it saves the response you describe. |
| set_variableA | Set a non-secret variable in an environment, creating the environment if it does not exist. The value is written to the environment's file, so it is shared through Git; never use it for a secret. Secret variables and protected environments can only be changed in Kurlo. |
| generate_testsA | Write pm.test assertions into a saved request from a real or described response: its status, its Content-Type and a JSON schema of its body (types and required fields, never values), and save the response as an example the mock server serves. from: run (default) sends the request, so it creates what a POST creates. from: example takes the status and body, or schema, the code returns, for an API that is not running anywhere yet. Tests the request already has are kept; a test with the same name is not added twice. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| sync_collection | Find the HTTP routes in this project's code and add a saved request with tests for each one the Kurlo collection is missing. |
| cover_endpoint | Add a saved request, tests and an example response for one endpoint of this project's API. |
| debug_last_failure | Explain why the last failed request sent from Kurlo failed and propose a fix. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 15 tools
Most tools have clearly distinct purposes, and the saved-vs-one-off split between run_request and send_request is explicit. However, generate_tests overlaps with save_example (both save a response as an example), and diagnose_last_failure shares some surface with get_history_entry, creating minor ambiguity.
All tools use a consistent snake_case verb_noun pattern (save_request, list_history, run_collection, etc.). The verbs vary appropriately by action while the structure remains predictable throughout.
15 tools is at the upper end of the ideal range but appropriate for a Postman-like API client covering requests, collections, environments, history, and testing. Each tool earns its place without obvious redundancy.
Request lifecycle is well covered (save, delete, list, get, run, send), but collection management is incomplete: only create_collection exists, with no list, update, or delete. Environment and example lifecycles also lack delete operations, leaving notable gaps for an agent to manage the workspace fully.