har-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| --dir | No | Folder the server may read HAR files from and write redacted copies to. Repeat the option for several folders. Relative paths in tool calls are resolved against the first --dir. If omitted, the current directory is used (not recommended for desktop apps). |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Analyze HAR files (browser DevTools 'Save all as HAR') to debug web performance and failures. Files can be 10-200 MB; they are streamed, never loaded whole. Start with har_overview, then slowest_requests (timing breakdown + what dominates), failed_requests, find_requests (filters; gives the #index numbers), request_detail(index) for headers/body/redirects, and waterfall for the timeline and critical path. Every tool takes the HAR path. Secrets (Authorization, cookies, tokens in URLs/headers/bodies) are masked as redacted:N by default; only pass include_secrets=true if the user explicitly asks for raw values. redact_har writes a sanitized copy you can share. Files must be inside the directories the server was started with (--dir).
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| har_overviewA | Summarize a HAR file: entry and page counts, time range, page load timings, totals by resource type / domain / status class, bytes transferred vs uncompressed, and cache hit statistics. Start here. The file is streamed (safe for 100+ MB). Entry numbers (#N) used by other tools are 0-based positions in the HAR. |
| slowest_requestsB | List the slowest requests by total time, each with its timing breakdown (blocked, dns, connect, tls, send, wait, receive) and which phase dominates, with a plain-English hint (e.g. long 'wait' = slow server, long 'blocked' = queueing). URLs are masked by default (include_secrets=false). |
| failed_requestsB | List failed requests: HTTP 4xx/5xx, status 0 (blocked, cancelled, offline) and any request the browser flagged with an error (e.g. net::ERR_BLOCKED_BY_CLIENT), with the reason and, when the HAR records it, the initiator (what triggered the request). |
| find_requestsA | Find requests and get their #index numbers (for request_detail). All filters are ANDed. url_contains / url_regex are case-insensitive and match the URL as displayed (masked unless include_secrets=true). status: 404, 4xx, 200-299, 0, or a comma list. mime and domain are substring matches. start_ms/end_ms keep requests that START within that window, in ms from the first request in the file. Results are capped by limit (max 500); the total match count is always reported. |
| request_detailA | Everything about one request (index from find_requests / slowest_requests): URL, status, timings and what dominates, sizes, cache state, initiator, redirect chain, query parameters, request and response headers, and a response body preview cut to body_chars (max 20000). Binary or base64 bodies are described, not dumped. Authorization, cookies, tokens and passwords are masked as redacted:N by default. |
| waterfallC | ASCII timeline of the page load: one row per request in start order, drawn with its phases (. blocked, d dns, c connect, s tls, > send, = wait, r receive), page DOMContentLoaded / load markers, then the critical path (the longest dependency chain, from initiators and redirects when the HAR has them, otherwise from timing alone). page: a page id from har_overview to restrict to one page load. |
| redact_harA | Write a sanitized copy of a HAR that is safe to share: masks Authorization,
Cookie/Set-Cookie, tokens/passwords/API keys in headers, query strings, JSON and form
bodies (and JWT/GitHub/AWS-shaped values anywhere). Streamed, so large files work.
NEVER overwrites: fails if |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
Each tool has a distinct role in the HAR workflow: overview, slowest requests, failed requests, discovery, single-request detail, timeline visualization, and sanitization. Although find_requests overlaps conceptually with slowest_requests and failed_requests, their outputs and intended use are clearly differentiated.
All names use snake_case and are readable, but they mix noun-phrase names (har_overview, slowest_requests, failed_requests, request_detail, waterfall) with verb-phrase names (find_requests, redact_har). The convention is not a single predictable pattern, though it remains understandable.
Seven tools is well-scoped for HAR analysis, covering discovery, drill-down, visualization, and sanitization without redundant endpoints. Each tool earns its place and supports a clear step in the analysis workflow.
The surface covers the full practical lifecycle for examining and sharing a HAR: high-level summary, bottleneck and failure inspection, request lookup and detail, page-load visualization, and safe redaction. No obvious operational gap remains for the stated purpose.