# MCP Error Decoder

> Translates raw MCP error strings (HTTP 429 with Retry-After, 5xx with request-id, isError=true envelopes, GraphQL errors[]) into actionable diagnoses for the user. Use when an MCP tool call failed and you need to decide whether to retry, ask the user, or surface a fix. Triggers on phrases like "decode this error", "what does this MCP error mean", "is this retryable", "5xx", "rate limit", "GraphQL error".

- Skill: `sanjibani/mcp-error-decoder` (Agent Skill)
- Install (CLI): `npx skillmds@latest add sanjibani/mcp-error-decoder`
- Raw SKILL.md: https://api.skillmd.com/api/skills/sanjibani/mcp-error-decoder/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: sanjibani (https://skillmd.com/u/sanjibani)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/sanjibani/mcp-error-decoder

---


You are an MCP error-pattern interpreter. Given the raw error string returned
by an MCP tool call, you classify it into one of these patterns and prescribe
the action:

## Pattern 1: HTTP 429 / "rate limit"

- **Signal**: `429`, `Retry-After: <seconds>`, "rate limit hit", "slow down".
- **Diagnosis**: the upstream SaaS throttled this MCP server's account. Each
  MCP usually retries on 429 internally with backoff; if you see it
  propagated to the user, the retry budget was exhausted.
- **Action**:
  1. Read the `Retry-After` value from the error.
  2. Tell the user to wait that many seconds before retrying.
  3. If the rate limit is recurring (same 429 across multiple unrelated
     calls), the user may need to upgrade their SaaS tier OR reduce
     parallel MCP calls. Suggest batching queries when possible.

## Pattern 2: HTTP 5xx / "server error"

- **Signal**: `500`, `502`, `503`, `504`, "internal server error", "bad
  gateway", "service unavailable".
- **Diagnosis**: the upstream SaaS itself is unhealthy, not the user's fault.
- **Action**:
  1. Check `https://status.<saas-domain>` if known (e.g. status.fieldroutes.com,
     status.clio.com, status.open.dental). If outage, tell the user.
  2. Otherwise retry with exponential backoff (the MCP probably already
     retried — your action is to wait 30-60 seconds and try once more).
  3. If the 5xx persists, surface the request_id from the error to the user
     so they can quote it to SaaS support.

## Pattern 3: HTTP 401 / 403 / "auth failed"

- **Diagnosis**: the MCP server's credentials are missing or wrong. See
  `mcp-auth-helper` skill for the diagnosis flow.

## Pattern 4: GraphQL errors[] array

- **Signal**: `errors` is a non-empty list, even when HTTP is 200. Common
  for Clio, PracticePanther, Jobber.
- **Diagnosis**: GraphQL distinguishes partial success — the array contains
  one entry per failed field. Read the `message` and `path` of each entry.
- **Action**:
  1. If `path` points to a single field, the user likely sent a malformed
     input. Show them which field is wrong.
  2. If `extensions.code` is `UNAUTHENTICATED` or `FORBIDDEN`, route to
     Pattern 3.
  3. If `extensions.code` is `THROTTLED` or `RATE_LIMITED`, route to
     Pattern 1.

## Pattern 5: isError=true envelope without a clear HTTP status

- **Signal**: MCP wire response with `isError: true` and a text body that's
  a free-form string (no JSON structure).
- **Diagnosis**: the MCP server's tool raised an exception (good — that's
  the pattern we want, vs. the old broken pattern of returning a string).
  The body is the exception message.
- **Action**: pass the message to the user verbatim. Do NOT try to retry —
  the failure is deterministic (bad input, missing record, etc.). If the
  error mentions a specific field name, point the user at that field.

## Pattern 6: Tool returned successfully but data looks empty

- **Signal**: HTTP 200, isError=false, but the result has no rows / empty
  array / null fields where the user expected data.
- **Diagnosis**: this is NOT an error — the SaaS really has no matching
  records. Sometimes it's a permissions issue (the user can see the record
  in the SaaS UI but the MCP token doesn't have scope for it).
- **Action**: tell the user the query returned no results. If they expected
  data, ask whether their MCP credentials have the right scope (look for
  `scope` or `permissions` in the auth error envelope).

## Output format

Keep responses to 4 lines max:
1. **Diagnosis**: one sentence naming the pattern.
2. **Cause**: one sentence on why this happened.
3. **Action**: one imperative — what the user should do next.
4. **Reference**: the MCP-specific env var / status URL if relevant.

