Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

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

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
statusA

Check connectivity to mitmweb and report how many flows are captured.

Start here when something is not working.

flow_statsA

Overview of captured traffic: hosts, status codes, asset ratio, hottest endpoints.

This is the first thing to run against an unfamiliar site: it tells you which host the interesting API lives on and whether anything is failing. Numeric path segments are normalised to {n}, so /user/1001 and /user/1002 are counted as one endpoint.

list_flowsA

List recent flows, newest first.

Static assets (js/css/images/fonts) are excluded by default — the equivalent of mitmproxy's !~a filter, and the single biggest signal-to-noise win. Pass include_assets=True when you actually want them.

Two parameters make the human's UI actions usable as input:

  • since_seconds: only flows from the last N seconds. If the user just clicked a button, since_seconds=15 isolates exactly what that click triggered.

  • marked_only: only flows the user has marked in the mitmweb UI.

url_contains matches the full URL including host and query string; content_type is a substring match against the response type, e.g. "json".

inspect_flowA

Full detail for one flow: URL, query params, both header sets, both bodies, latency, and a ready-to-run equivalent curl command.

get_contentA

Fetch one full body (gzip/brotli already decoded). which = request | response.

Use this instead of inspect_flow when the body is large and you need more than inspect_flow's 4000-character preview.

search_flowsA

Full-text search across flows: "which request carried or returned this value?"

This is the usual entry point for reverse-engineering an API. Take a distinctive value visible in the page (an order number, a username, a token) and search for it to find the endpoint that produced it.

scope = all | url | headers | body. With regex=True the keyword is a regular expression, e.g. "sign=[a-f0-9]{32}". Scans backwards from the newest flow, at most max_scan flows.

diff_flowsA

Compare two requests field by field — the tool for reverse-engineering signatures.

Typical use: call the same endpoint twice (or capture it before and after paging), then diff. Parameters that stay the same are omitted from the output, so what remains is exactly the set that varies per request: nonce, timestamp, signature. That tells you which fields any signing algorithm must reproduce.

JSON bodies are flattened to a.b.c keys and compared per key. Non-JSON bodies are returned verbatim for both sides so you can judge them yourself.

detect_authA

Scan all traffic and report which authentication schemes the site uses.

Run this when picking up an unfamiliar target: it answers "what exactly do I have to forge in order to call this API without a browser?" — a bearer token, a session cookie, a custom API-key header, or a signed request. Each finding includes sample flow ids you can pass straight to inspect_flow.

generate_codeA

Turn captured flows into a runnable scraper script — the final deliverable.

flow_ids may be a list or a comma-separated string. The order is preserved in the generated script and all requests share one Session, so a "log in, then call the API" sequence replays correctly with cookies carried across.

framework = curl_cffi (default; TLS fingerprint impersonation, best for scraping) | httpx | requests | curl (emits a shell script instead).

Original request headers are kept, minus the ones the client manages itself.

replay_flowA

Replay a request, optionally rewriting method, headers or body (like Burp Repeater).

The request is sent with curl_cffi using browser TLS fingerprint impersonation, and it goes through your own mitmproxy, so the result appears as a new flow in your mitmweb UI where you can see it. Existing flows are never modified.

headers overrides or adds headers, e.g. {"Authorization": "Bearer NEW"}; omit to reuse the original. body replaces the request body (dicts/lists are serialised to JSON). impersonate accepts chrome / chrome131 / chrome142 / safari / firefox / edge.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources