Fiddler Traffic Debugging

Fiddler Feature Verification

Analyze the traffic generated by a feature run, decide whether the observed HTTP behavior looks correct, and produce a grouped-by-endpoint summary with likely issues.

Operating rules

1. This skill is MCP-first. Use Fiddler Everywhere MCP tools for traffic analysis whenever they are available in the current session.
2. Do not use shell tools, rg, grep, workspace file scans, or exported session dumps to inspect traffic if the Fiddler MCP tools are available.
3. Prefer CaptureApplication as a pre-capture step when you know which process to focus on — it scopes the capture at the OS level and keeps the session list clean from the start. Use ApplyFilters whenever it helps narrow a large or noisy capture to the traffic that matters for the feature verification.
4. Keep the analysis practical. The goal is to verify whether the feature appears to work, not to produce an exhaustive packet-level audit.
5. If the Fiddler MCP tools are not available in the current session, stop and tell the user to run fiddler-mcp-setup first, then retry.
6. Never manually probe /mcp or send raw MCP protocol requests with curl when the runtime already exposes Fiddler MCP tools.
7. Use only tool names that the host advertises in tools/list. Never invent or assume tool names beyond the ones available in the session.
8. All session tools (GetSessionsCount, GetSessions, GetSessionDetails, ClearSessions, ApplyFilters) require a sessionsSource parameter — always pass LiveTraffic for captured HTTP/HTTPS traffic or AgentCalls for LLM/AI agent API calls. Never omit this parameter.

Session sources

Fiddler exposes two session sources; always pass the correct one to every session tool:

Agent API calls are also HTTP traffic and appear in both sources; AgentCalls gives the enriched metadata view.

Prerequisites check

1. Verify that Fiddler Everywhere is installed.
2. Verify that the Fiddler Everywhere MCP tools are available.

Useful tools and how to use them

GetStatus

Use this first to confirm that Fiddler is reachable and in a usable state.

What it helps verify:

• Whether the user is logged in
• Whether Fiddler appears to be capturing traffic
• Whether there are browser or terminal instances attached
• Whether HTTPS inspection prerequisites look healthy

CaptureApplication

Use this as the first step whenever you know which process generates the traffic you want to verify.

This is the most powerful noise-reduction tool available. It scopes the OS-level capture to one or more specific processes, so only their traffic appears in the Live Traffic inspector — eliminating background noise from browsers, IDEs, system services, and other apps running at the same time.

How to use it:

• Supply the process name or PID inferred from the current IDE or CLI context (e.g. the process running the feature under test).
• Multiple targets are space-separated; multi-word names must be quoted (e.g. "Google Chrome").
• The supplied list replaces the current capture filter. When elicitation is supported, Fiddler may offer to merge with the existing filter instead.
• After calling CaptureApplication, clear any stale sessions with ClearSessions (passing sessionsSource: LiveTraffic) before the user runs the feature, so the resulting capture contains only the relevant run.

When CaptureApplication is not appropriate:

• The process name or PID is unknown and cannot be inferred.
• The feature spans multiple processes whose names are not determinable.
• The user explicitly wants to analyze unfiltered traffic.

In those cases, fall back to ApplyFilters after GetSessions.

GetSessionsCount

Use this as a fast sanity check before deeper analysis.

What it helps verify:

• Whether anything has been captured at all
• Whether the user likely ran the feature recently enough to analyze it

GetSessions

This is the main tool for verification. Use it to pull the captured session list, then narrow the traffic locally in memory.

Use it to:

• Find the requests most likely related to the feature run
• Identify the order of requests
• Spot failures, retries, redirects, preflights, and slow calls
• Build endpoint groups for the final summary

When narrowing the list, prefer clues from the user's request such as:

• Hostname
• URL path or path fragment
• HTTP method
• Feature name or keyword
• A rough time window such as "just now" or "after clicking Save"

If the session list is already manageable, narrowing locally in memory is usually enough. If the capture is large or noisy, use ApplyFilters to focus Fiddler on the host, endpoint family, method, or failure pattern that matters.

GetSessionDetails

Use this after GetSessions identifies the interesting sessions.

Good candidates for detail inspection:

• Any session with statusCode >= 400
• Any session with an empty or missing statusCode
• The slowest session for an endpoint
• A representative successful request for an important endpoint
• OPTIONS preflight requests and the request immediately after them when CORS might be involved

Use the details to inspect:

• Request headers and response headers
• Request and response bodies
• Redirect targets
• Content length and content type
• Auth headers, cookies, validation messages, and error payloads

For AgentCalls sessions, also inspect the LLM model, isCached flag, and the last user prompt preview — these often reveal misconfigured model routing or unexpected cache hits.

Rate limit: avoid firing more than 5 GetSessionDetails calls in rapid succession.

ApplyFilters

Use this when filtering will make the analysis faster or more reliable.

Possible use cases:

• Show only traffic for one host
• Show only failing requests
• Focus the UI on a particular endpoint family
• Isolate retries, auth failures, or one request method such as POST

To reset filters, call ApplyFilters with an empty filter collection.

ClearSessions

Use this to remove stale sessions before a focused capture run. Always pass sessionsSource. Typically called after CaptureApplication and before the user runs the feature, to ensure the resulting inspector contains only the relevant session set.

StartCaptureWithBrowser / StartCaptureWithTerminal

Use these when the feature under test needs a fresh, proxy-configured environment:

• StartCaptureWithBrowser — opens a Chrome instance with Fiddler proxy pre-applied.
• StartCaptureWithTerminal — opens a terminal with Fiddler proxy environment variables set.

These are useful when the target process cannot be instrumented via CaptureApplication, or when a clean browser session is needed to avoid cached auth state.

Suggested workflow

This workflow is intentionally flexible. Adapt it to the feature and the amount of captured traffic.

1. Understand the feature scope.

   • Extract any useful clue from the user's request: action performed, host, path fragment, method, target process, or expected endpoint.
   • Determine the appropriate sessionsSource: use LiveTraffic for standard HTTP features, AgentCalls when verifying LLM or AI agent behavior.
   • If the request is vague, analyze the most recent traffic and say that the result is based on the recent capture.

2. Scope the capture (strongly preferred).

   • If the target process is known or can be inferred from the IDE/CLI context, call CaptureApplication with the process name or PID.
   • Then call ClearSessions (with sessionsSource: LiveTraffic) to discard prior noise, so the next run produces a clean capture.
   • Ask the user to run the feature if they haven't yet, or proceed to analysis if they already have.

3. Pull the session list with GetSessions.

   • Shortlist sessions that match the feature scope.
   • If no clear clue is available, focus on the most recent burst of related sessions rather than the entire capture history.
   • If the capture is still too noisy, use ApplyFilters to narrow further.

4. Group traffic by endpoint.

   • Group by host + normalized path.
   • Strip query strings for grouping.
   • Treat numeric IDs and UUID-like segments as path variables, so /users/123 and /users/456 are understood as the same endpoint family.

5. Review the sequence.

   • Check whether the request flow looks plausible for the feature.
   • Look for expected follow-up calls such as create then fetch, preflight then actual request, upload then status poll, or save then refresh.
   • If a needed follow-up call is absent, call that out as a possible issue rather than a certainty unless the evidence is strong.

6. Inspect representative details.

   • Fetch details for failures, slow calls, mixed-status endpoints, and one or two key successful endpoints.
   • For AgentCalls, also check model name, cache hits, and prompt previews.
   • Use response bodies and headers as evidence when explaining whether the feature appears healthy.

7. Decide whether the feature appears to work properly.

   • A healthy feature run usually shows the expected endpoints, mostly successful status codes, reasonable latency, and no repeated failures.
   • If the traffic is incomplete or ambiguous, say so directly.

Output format

Do not dump raw JSON. Write a plain-language verification report with these sections.

Feature Verification

Overall verdict: [Feature appears healthy / Feature appears partially successful / Feature likely failed / Inconclusive]

Traffic window: [what part of the capture you analyzed]
Sessions source: [LiveTraffic / AgentCalls]
Capture scope: [CaptureApplication used: <process name/PID> / Unscoped — all traffic analyzed]

Endpoint summary:
- METHOD HOST /normalized/path
  Calls: [N]
  Statuses: [e.g. 200 x3, 401 x1]
  Timing: [avg X ms, max Y ms]
  What happened: [plain-language summary of what this endpoint appears to do]
  Evidence: [optional header/body/status detail when useful]

- METHOD HOST /another/path
  Calls: [N]
  Statuses: [...]
  Timing: [...]
  What happened: [...]

Possible issues:
- ⚠️ [Endpoint] [Issue name] — [what looks wrong and why it matters]
- ⚠️ [Endpoint] [Issue name] — [supporting evidence]

Conclusion:
- [Short answer on whether the feature appears to work properly]

Output requirements

1. Group the summary by endpoint, not by raw session ID.
2. Include status-code distribution and timing for each endpoint group.
3. Always state which sessionsSource was used and whether CaptureApplication scoped the capture.
4. If there are no obvious issues, say so explicitly: No obvious issues detected in the analyzed traffic.
5. If there are issues, prefix each issue with ⚠️, name it clearly, and explain what it appears to be.
6. If the capture is ambiguous or incomplete, say that the conclusion is tentative.