Free local MCP OAuth diagnostic

Find the resource mismatch behind invalid_target.

Compare the MCP endpoint, OAuth resource parameter, and protected-resource metadata. The check runs entirely in this browser and never requests the URLs.

No uploadNo network callsNo token needed

Resource identity

Compare what the client requests with what the server advertises.

Paste URLs only. Never include tokens, credentials, authorization codes, signed query values, or private customer identifiers.

Field guide · n8n MCP OAuth

Do not rotate the credential until the resource identity is proven.

OAuth defines invalid_target for a requested resource that is invalid, missing, unknown, or malformed. In MCP, the client and protected resource must agree on the canonical resource identifier.

1. Preserve the exact failure

Record the n8n version, Cloud or self-hosted deployment, client, timestamp, authorization-server hostname, exact error code, and redacted error description. Preserve the final URL after redirects. Do not include tokens, authorization codes, cookies, or query values.

2. Identify the n8n MCP surface

Distinguish instance-level n8n MCP from a workflow-level MCP Server Trigger and from the MCP Client Tool connecting to an external server. Those surfaces have different URLs, authentication contracts, and exposure controls.

3. Trace the discovery chain without a token

  1. Send an unauthenticated request to the final MCP endpoint.
  2. Record the WWW-Authenticate challenge and metadata URL.
  3. Fetch the protected-resource metadata and record its resource and authorization_servers fields.
  4. Fetch the authorization-server metadata and record the issuer and endpoints.
  5. Compare the client’s exact resource parameter with the advertised resource.

The downloadable credential-free endpoint checker captures the early transport and discovery boundary without an authorization header.

4. Compare one controlled client pair

Keep the server, account, endpoint, and network path constant. Test one affected client and one known-good direct MCP client. If both fail at the same OAuth step, investigate server metadata and authorization-server policy. If only one fails, compare the requested resource and discovery behavior before changing the server.

5. Treat a version correlation as evidence, not proof

A recent public n8n report described instance-level MCP re-authentication returning invalid_target after an upgrade. That pattern justifies a version-controlled reproduction; it does not prove that every identical error has the same root cause.

Reproduce in a safe test environment, compare the exact metadata and resource parameter before and after the change, and preserve a rollback boundary. Do not disable authentication to make the symptom disappear.

6. Build a support-quality packet

  • n8n version and deployment type
  • instance-level, workflow-level, or external MCP role
  • client name and version
  • final endpoint origin and path
  • redacted requested and advertised resource identities
  • exact OAuth error code and redacted description
  • first failing protocol step and controlled-client result
  • upgrade or configuration change immediately before the failure

Primary references

Still blocked in production?

Turn the evidence into a bounded repair.

One accepted n8n, MCP, or agent-production path. A verified fix or an actionable root-cause package within the guarded 12-hour service window—or a refund under the published terms.

Submit for fit review