pipehero

save_captured_request

Idempotent

Document a real request captured by a tunnel (get its id from list_requests). If an endpoint already covers the route, the response is added to it as an example; otherwise an endpoint is created from the request. Credentials, cookies and signatures are replaced by {{variables}} and only JSON bodies are kept. A response already saved as an example is not duplicated. Use it to document webhooks and calls you have only seen in traffic.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "collection_id": "<collection_id>",
      "tunnel": "<tunnel>",
      "request_id": "<request_id>"
    },
    "name": "save_captured_request"
  }
}

Input Schema

Name	Required	Description
`path`	No	With method: route path of the endpoint, e.g. /v1/charges/:id.
`folder`	No	Folder for a newly created endpoint, created by name if missing.
`method`	No	With path: the endpoint that should receive the example.
`tunnel`	Yes	Subdomain of the tunnel that captured the request.
`request_id`	Yes	Id of the captured request, from list_requests.
`endpoint_id`	No	Add the example to this endpoint instead of matching by route. Alternative to method + path.
`collection_id`	Yes	Id from list_api_collections.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 29, 2026
- addedInput schema / properties / collection_id / description
```
Added value: +"Id from list_api_collections."
```
- addedInput schema / properties / path / description
```
Added value: +"With method: route path of the endpoint, e.g. /v1/charges/:id."
```
AddedSep 21, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare the safety profile (non-readOnly, idempotent, non-destructive, closed-world); the description adds the substantive behavior: route-matching decides whether an example is appended or a new endpoint is created, credentials/cookies/signatures are replaced with {{variables}}, only JSON bodies are retained, and duplicate examples are skipped. These are exactly the side effects an agent needs to predict before mutating a collection.

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?

Five dense sentences, each carrying distinct information: input source, branching behavior, sanitization, dedupe rule, and intended use. Front-loaded with the core action and free of filler.

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 a 7-parameter mutation tool with no output schema, the description covers outcomes, sanitization, and idempotency well. It does not state what is returned (created endpoint id? example id?) or any permission/auth prerequisites, which would help an agent chain follow-up calls.

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 baseline is 3, but the description adds the matching rule ('If an endpoint already covers the route') that explains how method+path interact versus endpoint_id — context the schema only hints at with 'Alternative to method + path.' It does not explain the folder parameter's default or what happens when path is supplied without method.

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+resource ('Document a real request captured by a tunnel') and immediately clarifies the source of the input ('get its id from list_requests'). It also spells out the two possible outcomes (example added to existing endpoint vs. endpoint created), which distinguishes it clearly from siblings like add_api_example and upsert_api_endpoint.

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?

'Use it to document webhooks and calls you have only seen in traffic' gives a clear positive usage context, and the note about getting the id from list_requests establishes the prerequisite workflow. It stops short of naming explicit alternatives (e.g. when to prefer add_api_example or upsert_api_endpoint instead), so it is strong but not fully routing.

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

All pipehero tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.