fiddler-traffic-debugging

name

fiddler-traffic-debugging

description

Verify that a developer-run feature behaved correctly by analyzing HTTP traffic captured by Fiddler Everywhere. Always use this skill when a developer asks whether their feature's HTTP calls completed correctly, wants to see what requests a feature made, needs to debug a failed API call, is checking traffic after running a feature, wants to confirm what each endpoint returned, or asks whether anything in the traffic looks wrong — even if they don't use the word "verify" or "Fiddler". Summarizes the capture by endpoint and flags likely issues such as failed calls, missing follow-up requests, retries, auth failures, timeouts, and suspicious status-code patterns. Requires Fiddler Everywhere to be running with its MCP server enabled.

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. 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.

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

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(id)

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

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
• Reduce a very large capture to the recent feature run you actually need to inspect
• Isolate retries, auth failures, or one request method such as POST

It is often useful when GetSessions returns too much unrelated traffic.

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, or expected endpoint.
   • If the request is vague, analyze the most recent traffic and say that the result is based on the recent capture.

2. 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 too noisy to reason about comfortably, use ApplyFilters to narrow the visible traffic before continuing.

3. Group traffic by endpoint.

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

4. 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.

5. Inspect representative details.

   • Fetch details for failures, slow calls, mixed-status endpoints, and one or two key successful endpoints.
   • Use response bodies and headers as evidence when explaining whether the feature appears healthy.

6. 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]

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. If there are no obvious issues, say so explicitly: No obvious issues detected in the analyzed traffic.
4. If there are issues, prefix each issue with ⚠️, name it clearly, and explain what it appears to be.
5. If the capture is ambiguous or incomplete, say that the conclusion is tentative.